Define how MessageConsumer.receive should handle a thread interrupt

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:
http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html

Possibilities are:

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.

Affected Versions

[1.1]

Start with the MessageConsumer.receive() and receive(timeout) API behavior described in the issue, then review the linked Brian Goetz article and the existing JMS 1.1 behavior. Resolve which interrupt-handling rule, if any, JMS should specify; completion requires a decided specification direction rather than an implementation, since no files or tests are named.