[JMS_SPEC-66] Define how MessageConsumer.receive should handle a thread interrupt Created: 03/Jan/12 Updated: 08/Jan/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
The Java SE API allows an application to interrupt a running thread by calling the interrupt method on the Thread object.
I'm logging this issue to raise the question of whether JMS should define how a JMS provider should handle a thread interrupt during a call to MessageConsumer.receive() or MessageConsumer.receive(timeout), which will both block whilst waiting for a message to arrive.
There's a useful article by Brian Goetz here:
1. Leave this up to the JMS provider (which is the current situation in JMS 1.1)
Note that it would not be possible to change the signature of the existing receive methods (as in (3)) since this would break backwards compatibility.
In cases 1,2 and 4 (the ones that don't throw a InterruptedException) Brian Goetz's article recommends that the method should re-enable the interrupted status of the thread (even if the interrupt was swallowed or converted a JMSException) to allow the calling code to detect whether an interrupt had occurred.
In logging this issue I'm not proposing any change, but the topic is worth recording and I'd welcome comments.
|Comment by brecht_yperman [ 03/Jan/12 ]|
Having encountered this issue with JMS 1.1 and OpenMQ, I'd personally prefer option 2.
MessageConsumer.receive() is an operation very similar to a blocking read, described in the API
"If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException."
I also think, but this is of course guessing, that most JMS clients do a blocking socket read anyway, so they can easily handle the InterruptedException thrown by that read.
Just my two cents.
|Comment by Nigel Deakin [ 08/Mar/12 ]|
This issue will be considered by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging appropriately.
|Comment by axel_podehl [ 08/Jan/13 ]|
I would prefer 3 (throw InterruptedException)- if it wouldn't break the API.
Probably the JMS Provider should set JMSException.setLinkedException() to be the InterruptedException