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.
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.
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.
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.
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.