jms:outbound-gateway and growing consumers on the reply channel

[greenwayb]

I have configuration, which uses an explicit reply-destination

<jms:outbound-gateway request-destination="reconcileQueue"
reply-destination="reconcileQueueReplies"
request-channel="reconcileInputChannel"
connection-factory="cachedConnectionFactory"
receive-timeout="30000"
/>


The use case is Service A makes a reconcillation request to service B, with the queues defined explicity to make monitoring easier.

When the system is initliased I observe that there is one consumer on the reconcileQ, and none on the replyQueue. All good, this is what I would expect.

As requests are made, I notice that the consumer count of the reply queue continues to grow (the requests do not).

Is there any reason why this is the case? I am a little concerned that I am going to run out of consumers.

For reference, this is using spring integration M5 and Hornetq 2.1.0 Final.

[Mark Fisher]

What ConnectionFactory implementation are you using?

[greenwayb]

<bean id="cachedConnectionFactoryHornetQ" class="org.springframework.jms.connection.CachingC onnectionFactory">
<property name="targetConnectionFactory" ref="connectionFactoryHornetQ"/>
<property name="sessionCacheSize" value="10"/>
<property name="reconnectOnException" value="true" />
<property name="exceptionListener" ref="jmsExceptionListener" />
</bean>


<bean id="connectionFactoryHornetQ" class="org.springframework.jndi.JndiObjectFactoryB ean">
<property name="jndiName" value="ConnectionFactory"/>
<property name="jndiEnvironment" ref="jndiProps"/>
<property name="cache" value="false"/>
</bean>


<bean id="jndiProps" class="java.util.Properties">
<constructor-arg index="0">
<props>
<prop key="java.naming.factory.initial">org.jnp.interfac es.NamingContextFactory</prop>
<prop key="java.naming.provider.url">jnp://hornetq-live:6666,jnp://hornetq-backup:6676</prop>
<prop key="java.naming.factory.url.pkgs">org.jboss.namin g:org.jnp.interfaces</prop>
</props>
</constructor-arg>
</bean>



Which resolves to hornetq-jms.xml:

<connection-factory name="ConnectionFactoryUnlimitedConsumers">
<connectors>
<connector-ref connector-name="netty" backup-connector-name="backup-connector"/>
</connectors>
<entries>
<entry name="ConnectionFactory"/>
<entry name="XAConnectionFactory"/>
<entry name="java:/ConnectionFactory"/>
<entry name="java:/XAConnectionFactory"/>
</entries>
<retry-interval-multiplier>1.0</retry-interval-multiplier>
<failover-on-server-shutdown>true</failover-on-server-shutdown>
</connection-factory>

Hornetq is setup with a connection-ttl-override

<connection-ttl-override>-1</connection-ttl-override>

connection-ttl.html

[Mark Fisher]

Can you describe the behavior you see if you set the 'cacheConsumers' property to TRUE on that CachingConnectionFactory instance?

Thanks,
Mark

[greenwayb]

cacheConsumers is true by default. So this is what you should be seing here, or did I miss something?

[grantlittle]

The CachedConnectionFactory by default caches consumers in a HashMap. The entries are keyed off a ConsumerCacheKey object. The construction of this is as follows:-

ConsumerCacheKey cacheKey = new ConsumerCacheKey(dest, selector, noLocal, subscription);

where the selector is a message selector. For each synchronous request/response via the queues, the Spring Integration implementation generates a JMS Correlation ID and uses this as a message selector to correlate the response with the original response.

This has the effect of making each each consumer appear different from the CachedConnectionFactory's point of view. So the number of cached consumers grows and effectively leads to a memory/resource leak.

In this situation caching consumers doesn't work so its best to switch of consumer caching in the CachedConnectionFactory which should fix your issue. Although it probably isn't as performant as it could be.