[JMS_SPEC-66] Define how MessageConsumer.receive should handle a thread interrupt Created: 03/Jan/12  Updated: 08/Jan/13

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview-minor


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:

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.

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.
So choice 2 (throw JMSException) is the second best alternative

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

Generated at Wed Sep 02 02:35:38 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.