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)
2. Define that a thread interrupt should cause the receive method to throw a JMSException
3. Define that a thread interrupt should cause the receive method to throw a InterruptedException
4. Define that a thread interrupt should be ignored
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.