Context not shutting down when awaiting for a message on a JMS destination

[plecesne]

Hi,

I'm facing an issue regarding the lifecycle of my flows (configured with Spring Integration).
Having several flows running on the same application server in different application contexts, I would like to be able to call stop() and close() on only one application context without having to shut down my entire application server.

However, with flows reading from a JMS Queue (message-driven), I have issues when stopping and closing the application contexts. And I have different behaviour depending on the JMS implementation / the way I build the Queue.

Below is the configuration of my flow :

<bean id="myListener" parent="abstractListener">
	<property name="destinationName" value="myQueueName" />
</bean>

<int-jms:message-driven-channel-adapter container="myListener" channel="inputChannel" />

<int:channel id="inputChannel" />

<int-stream:stdout-channel-adapter channel="inputChannel" />

And here is the behaviour I noticed :

• On Websphere MQ -- Building Queue with "new com.ibm.mq.jms.MQQueue()"
  
  1) Calling "applicationContext.stop()" never returns.
  
  2) Calling "applicationContext.close()" never returns.
  
  
• On Joram -- Getting Queue from a JNDI lookup
  
  3) Calling "applicationContext.stop()" returns, but consumes the next message coming on the Queue without committing it. Thus, this message cannot be seen on the Queue, but will not be lost in case the application is killed.
  
  4) Calling "applicationContext.close()" never returns.
  

Any idea why this is happening, if this is normal, and how to solve/workaround it? (A poller is not an option, I really want it to be message-driven :-)).

Thank you in advance for your help.

Pierre

[plecesne]

After some further investigation, I have noticed that calling applicationContext.stop() is equivalent as calling javax.jms.Connection.stop() : it stops from reading from the queue but blocks the call until the receive() method returns.
The call to applicationContext.stop() thus blocks indefinitely if no more message arrives.
Not very practical but I guess that the Spring API wanted to follow the principles of JMS API ???

On the other hand, calling javax.jms.Connection.close() interrupts the blocking receive(), but this doesn't seem accesible from Spring API.
Calling applicationContext.close() also waits for the receive() method to return. I don't understand why in this case... If no more message arrives, then the call to applicationContext.close() will also block indefinitely. Why doesn't Spring API simply call close() on the connection when shutting down the jms listener?
And if there is a good reason, how can I stop my listener from reading from the queue (through a method which doesn't block!) ?

Help please

[Mark Fisher]

Regarding the "indefinite" blocking, are you talking about the receive() call that is invoked via the MessageConsumer managed by the DefaultMessageListenerContainer? That should be only a 1 second receive-timeout by default.

[plecesne]

Yes, I'm talking about that call.
To avoid useless CPU consumption, I have overriden the timeout value for all my consumers and set it to -1.

[plecesne]

Anyone?
Is the 1-second timeout the only way to stop properly a message-driven JMS listener in Spring?