Define how MessageConsumer.receive should handle a thread interrupt

[glassfishrobot]

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]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/66
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by @nigeldeakin

[glassfishrobot]

@glassfishrobot Commented brecht_yperman said: 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." [http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#interrupt(](http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#interrupt())

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.

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: This issue will be considered by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging appropriately.

[glassfishrobot]

@glassfishrobot Commented axel_podehl said: I would prefer 3 (throw InterruptedException)- if it wouldn't break the API. So choice 2 (throw JMSException) is the second best alternative

Probably the JMS Provider should set JMSException.setLinkedException() to be the InterruptedException

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-66

[glassfishrobot]

@jasonCodesAway Commented FWLIW I'd prefer a new method that incorporates #3, maybe call it "take" (similar to blocking queues) or "consume" (since this is a MessageConsumer) that throws an InterruptedException, and likely deprecate the current "receive". This could even be a default method that implements the current behavior (and never throws an InterruptedException), but still be overridden as implementors catch-up to the spec.