Feb 25th, 2008, 11:05 AM
DefaultMessageListenerContainer creates hundreds of jms managed connection
i am using a DefaultMessageListenerContainer102 for asynchronous message processing in websphere application server 5.1 and websphere MQ 5.3. It is working stable. But while monitoring websphere by Tivoli Performance Viewer i can see approximately 200 jms managed connections. Only 3 of them are open (the configured number of concurrentConsumers). I can only assume that the DefaultMessageListenerContainer doesn't share the connections. How can i configure the DefaultMessageListenerContainer102 to use the websphere connection pool?
<property name="resourceRef" value="false" />
<property name="jndiName" value="jms/CISTrackQCF" />
<!-- this is the Message Driven POJO (MDP) -->
<!-- and this is the message listener container -->
<property name="concurrentConsumers" value="3" />
<property name="connectionFactory" ref="jmsConnectionFactory" />
<property name="destination" ref="requestDestination" />
<property name="messageListener" ref="messageListener" />
Last edited by Daktari; Feb 25th, 2008 at 11:12 AM.
Feb 25th, 2008, 11:56 AM
It isn't a DefaultMessageListenerContainer issue, its a Websphere issue. You need to configure a given connection factory to support pooling in Websphere.
Rather than reinvent pooling, Spring JMS code relies mostly on the connection pool.
Feb 28th, 2008, 05:57 AM
Given your configuration, DefaultMessageListenerContainer should actually cache the connection, sessions and even consumers - since the default is CACHE_CONSUMER if not specifying an external transaction manager (which you don't).
DMLC doesn't pool but it caches the resources that it actively uses, so I'm pretty sure it is not causing the effect that you're seeing.
So I'm wondering where all those connections come from - I suppose rather from your usage of JmsTemplate? Try defining a SingleConnectionFactory inbetween your JmsTemplate users and your target ConnectionFactory:
<property name="targetConnectionFactory" value="jmsConnectionFactory" />
DefaultMessageListenerContainers may still talk to the raw "jmsConnectionFactory" but all JmsTemplates should talk to the "singleConnectionFactory" here.
Note that this just uses a shared JMS Connection; it doesn't pool Sessions for JmsTemplate usage. You need to check your JNDI setup for exposing a true pooled ConnectionFactory there if you'd like general Session pooling.
Feb 28th, 2008, 12:55 PM
the singleConnectionFactory is the solution for my problem. Now only one jmsManagedConnection will be opened by WebSphere. And the cpu usage is reduced dramatically...
Thank you very much,