MessageConsumer.receive() throwing InterruptedException

[ingrid_ingrid.olson]

When I interrupt a thread that is calling receive() on a MessageConsumer, a JMSException is thrown.  The cause of this is an InterruptedException.  In the catch block of the thrown JMSException, I then try calling close() the MessageConsumer.  Attempting to close the MessageConsumer throws another JMSException due to an InterruptedIOException that gets thrown  inside of the "this.transport.oneway(command)" line of the doAsyncSendPacket(Command command) call inside of the doClose() method inside of the close() method of the ActiveMQMessageConsumer class.

The result of this is that the MessageConsumer does not close, so that when I try to resubscribe my MessageConsumer to a durable Topic, I get an error that the MessageConsumer is already in use for that subscription name and client ID.

#AMQ-3529 (https://issues.apache.org/jira/browse/AMQ-3529) looks like it  addresses a similar issue, which has supposedly been fixed.  When I use the most recent snapshot of 5.6, though, I still encounter the same problem.  I am currently using the most recent stable release (FMB 5.5.1).

Is this a bug or is just the expected behavior?   Based on #JMS_SPEC-66 (http://java.net/jira/browse/JMS_SPEC-66) it looks like the behavior of what ought to happen has not yet been defined.   If it is the expected behavior, are there any workarounds to closing a message consumer after interrupting a thread while in MessageConsumer.receive()?

[garytully]

Is there a good reason for not calling close() in place of a thread interrupt?

Even if it is undefined behavior in the spec, I think it is a reasonable expectation to be able to close the connection so we need to investigate if that InterruptedIOException is really valid or serving any useful purpose.

Please raise an issue to track this.

[ingrid_ingrid.olson]

Each of the MessageConsumers lives inside a separate trigger, each of which is on a separate thread.  A user must be able to disable a trigger  (i.e. suspend the thread) at any time, including when a MessageConsumer is waiting to receive a message.

I have created an issue: #AMQ-3814. 

Thank you so much for your prompt response.  Please let me know if there is any other information I can provide that might be helpful.

[garytully]

If you can find the time to build a junit test case that can reproduce the problem you are seeing it would help speed up the resolution and protect the fix into the future. Attach it as a patch to the issue.

[ingrid_ingrid.olson]

I have created a JUnit test that shows a JMSException being thrown on MessageConsumer.receive() after the thread is interrupted, but I have not yet been able to reproduce the subsequent exception I am getting upon calling MessageConsumer.close().  Should a JMSException be thrown on MessageConsumer.receive() when the thread is interrupted?  If not, I can post the test as it is now.

[tabish121]

Given that the receive call is cancelled via interrupt I think that throwing a JMSException here is a reasonable thing.  Its expected that receive will block until a message is available so the exception is an indicator that something "exceptional" has occured.