Hi Nigel,
Please find my comments in blue.
regards,
Vaquar khan
On Thu, Dec 18, 2014 at 11:27 PM, Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:
>
> I haven't received any comments on this so far.
>
> For a detailed description of what the problem is, please see my earlier
> email or my description in https://java.net/jira/browse/JMS_SPEC-158. But
> essentially we need to amend the specification to allow JMS providers which
> allowed Session#close, Connection#stop and Connection#close to be called
> from a message listener on its own session or connection to continue to do
> so.
>
> I circulated some draft javadoc changes on 27th November. For example, I
> suggested that the definition of Connection#close be changed as follows:
>
> Existing text:
>
> When this method is invoked, it should not return until message
> processing has been shut down in an orderly fashion. This means that
> all
> message listeners that may have been running have returned, and that
> all
> pending receives have returned.
>
> Replacement text:
>
> When this method is invoked, it should not return until message
> processing has been shut down in an orderly fashion. This means that
> all
> message listeners that may have been running have returned, and that
> all
> pending receives have returned.
>
> However if the close method is called from a message listener on
> its own
> connection, then it will either fail and throw an
> <tt>IllegalStateException</tt>,
> or it will succeed and close the connection, blocking until all
> other
> message listeners that may have been running have returned, and
> all
> pending receives have returned. If close succeeds and the
> acknowledge mode
> of the session is set to AUTO_ACKNOWLEDGE, the current message
> will still
> be acknowledged automatically when the onMessage() call completes.
>
> Since two alternative behaviors are permitted in this case,
> applications
> should avoid calling close from a message listener on its own
> connection because this is not portable.
>
> There are two issues which need to be decided before I can draft the final
> changes.
>
> 1. Given that the spec will allow the close to "succeed" as an alternative
> to throwing an exception, it needs to define what this means, given that
> the current definition of close would, if followed strictly, would lead to
> deadlock. Is the text proposed above OK?
>
Yes , It's good explanation
>
> 2. We also have to decide whether the same change should be made to the
> new JMS 2.0 methods JMSContext#stop and JMSContext#close. If we followed
> the same approach as for my other proposals we would leave these methods
> unchanged since there is no need to change them, and it is better to stick
> with the current, unambiguous, definition.
>
We would leave these methods unchanged since
there is no need to change them
>
> However there is one reason why we might want to keep the simplified API
> consistent with the classic API, and allow stop and close to be called in
> all cases. This is if we decided that it is actually better to allow stop
> and close to be called than throw an exception (i.e. requiring an exception
> was a mistake).
>
> If we decided that, the errata could allow either behavior (so existing
> implementations don't need to change), and then in JMS 2.1 we could remove
> the option to throw an exception (which we could reasonably argue wasn't an
> incompatible change to applications).
>
> I'm attracted by this, as I've received complaints that requiring an
> exception to be thrown has made it harder to write applications.
>
> What do people think of that? I'd welcome views.
>
> Nigel
>
--
Regards,
Vaquar Khan
+91 830-851-1500