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?
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.
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 behaviour (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