DefaultMessageListenerContainer creates hundreds of jms managed connection

[Daktari]

Hello,

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?

Thanks,
Andre


<bean id="jmsConnectionFactory"
class="org.springframework.jndi.JndiObjectFactoryB ean">
<property name="resourceRef" value="false" />
<property name="jndiName" value="jms/CISTrackQCF" />
</bean>


<!-- this is the Message Driven POJO (MDP) -->
<bean id="messageListener"
class="de.schenker.cis.jms.listener.TrackRequestLi stener">
<property name="messageSender">
<ref bean="messageSender"/>
</property>
<property name="xmlToPojoAndReverseConverter">
<ref bean="xmlToPojoAndReverseConverter"/>
</property>
</bean>

<!-- and this is the message listener container -->
<bean id="listenerContainer"
class="org.springframework.jms.listener.DefaultMes sageListenerContainer102">
<property name="concurrentConsumers" value="3" />
<property name="connectionFactory" ref="jmsConnectionFactory" />
<property name="destination" ref="requestDestination" />
<property name="messageListener" ref="messageListener" />
</bean>

[wpoitras]

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.

[Juergen Hoeller]

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:

<bean id="singleConnectionFactory"
class="org.springframework.jms.connection.SingleCo nnectionFactory102">
<property name="targetConnectionFactory" value="jmsConnectionFactory" />
</bean>

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.

Juergen

[Daktari]

Hi,

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,

Andre