On 16/08/2011 15:58, Nigel Deakin wrote:
> I have created this JIRA issue
> http://java.net/jira/browse/JMS_SPEC-49
>
> This issue was raised by Graham. As always, please do give your comments.
I've received no comments either way on this. On the basis that there are no objections, I've now composed the following
draft text: (this may get fine-tuned when I write it into the early draft)
Changes to section 4.3.8 ExceptionListener:
-------------------------------------------
After:
"A Connection serializes execution of its ExceptionListener."
Insert:
"This means that if a connection encounters multiple problems and therefore needs to call its ExceptionListener multiple
times, then it will only invoke onMessage() from one thread at a time. Note however that if the same ExceptionListener
is registered with multiple connections then it is undefined whether these connections could call onMessage() from
different threads simultaneously."
At the end, insert:
"There is no restriction on the use of the JMS API by the listener's onException method. However since that method will
only be called when there is a serious problem with the connection, any attempt to use that connection may fail and
cause exceptions."
New text in the javadoc for ExceptionListener:
---------------------------------------------
There is no restriction on the use of the JMS API by the listener's onException method. However since that method will
only be called when there is a serious problem with the connection, any attempt to use that connection may fail and
cause exceptions.
A Connection serializes execution of its ExceptionListener. This means that if a connection encounters multiple problems
and therefore needs to call its ExceptionListener multiple times, then it will only invoke onMessage() from one thread
at a time. Note however that if the same ExceptionListener is registered with multiple connections then it is undefined
whether these connections could call onMessage() from different threads simultaneously.
New text in the javadoc for Connection.stop() and Connection.close():
--------------------------------------------------------------------
For the avoidance of doubt, if an exception listener for this connection is running when stop is invoked, there is no
requirement for the exception listener to return before the stop method returns.
As usual, if you have any comments please make them in the usual way.
Nigel
>
> Improve specification of ExceptionListener
> ==========================================
>
> The use of a ExceptionListener is described in the JMS 1.1 specification in section 4.3.8 "ExceptionListener":
>
> "If a JMS provider detects a problem with a connection, it will inform the connection's ExceptionListener, if one has
> been registered. To retrieve an ExceptionListener, the JMS provider calls the connection's getExceptionListerer()
> method. This method returns the ExceptionListener for the connection. If no ExceptionListener is registered, the value
> null is returned. The connection can then use the listener by calling the listener 's onException() method, passing it a
> JMSException describing the problem.
>
> "This allows a client to be asynchronously notified of a problem. Some connections only consume messages, so they would
> have no other way to learn their connection has failed.
>
> "A Connection serializes execution of its ExceptionListener.
>
> "A JMS provider should attempt to resolve connection problems itself prior to notifying the client of them.
>
> "The exceptions delivered to ExceptionListener are those that have no other place to be reported. If an exception is
> thrown on a JMS call it, by definition, must not be delivered to an ExceptionListener (in other words, ExceptionListener
> is not for the purpose of monitoring all exceptions thrown by a connection)."
>
> Despite this, there have been a number of questions about the use of an ExceptionListener. These questions are listed
> below, together with proposed answers. It is proposed that the answers to these questions be incorporated into the
> specification.
>
> ***Question 1:* When Connection.stop() or Connection.close() is called, must these methods wait until any active calls
> to ExceptionListeners for that connection have returned, in the same way that they must wait until any active call to
> MessageListeners have returned?
>
> ***Proposed answer:* No.
>
> ***Question 2:* Is there any restriction on the use of Connection.stop() or Connection.close() from an ExceptionListener?
>
> ***Proposed answer:* No.
>
> ***Question 3:* What does "a Connection serializes execution of its ExceptionListener" mean?
>
> ***Proposed answer:* This means that if a connection encounters multiple problems and therefore needs to call its
> ExceptionListener multiple times, then it will only invoke onMessage() from one thread at a time. Note however that if
> the same ExceptionListener is registered with different connections then it is undefined whether these connections could
> call onMessage() from different threads simultaneously.
>
> ***Question 4:* What is the effect of ExceptionListener.onException() being slow or blocking?
>
> ***Proposed answer:* This is undefined. There is no requirement that any other operation need block until
> ExceptionListener.onException() has return, apart from other calls to ExceptionListener.onException() for the same
> connection.
>