multiple DefaultMessageListenerContainer instances?

[lloftin]

I was wondering if it is OK to use multiple instances of a DefaultMessageListenerContainer in the same JMS process? Of if they will end up competing inefficiently for worker threads?

I have an application that processes many messages on queue.a and then forwards messages to queue.b which the other DMLC is then picking up.

Is this a bad idea?

[chudak]

I've created over a dozen DMLC in various applications, all listening to different queues/topics. Works fine.

[lloftin]

Q1) For runnning multiple DMLC in a single application, do you use a shared connection factory for all DMLC, or does each DMCL have it's own connection factory?
Q2) Do you use a JmsTransactionManager? And if so, is it a different bean per DMLC?

Right now I am using the Spring CachingConnectionFactory and I had an instance where after running for a while, something got new Connections (which I could see doing a netstat) and the listeners stopped listening.

[chudak]

Q1) For runnning multiple DMLC in a single application, do you use a shared connection factory for all DMLC, or does each DMCL have it's own connection factory?
Q2) Do you use a JmsTransactionManager? And if so, is it a different bean per DMLC?

Right now I am using the Spring CachingConnectionFactory and I had an instance where after running for a while, something got new Connections (which I could see doing a netstat) and the listeners stopped listening.

A1) I use the same connection factory. I typically use the Spring single connection factory wrapped around my actual connection factory (note that I'm using Atomikos here), e.g.:

<bean id="queueConnectionFactoryBean" class="org.springframework.jms.connection.SingleConnectionFactory" destroy-method="destroy">
    <constructor-arg>
      <bean class="com.atomikos.jms.QueueConnectionFactoryBean" init-method="init">
        <property name="xaQueueConnectionFactory" ref="queueConnectionFactoryXa"/>
      </bean>
    </constructor-arg>
    <property name="reconnectOnException" value="true"/>
  </bean>
  
  <bean id="queueConnectionFactoryXa" class="org.apache.activemq.ActiveMQXAConnectionFactory">
    <property name="brokerURL" value="${activemq.url}"/>
    <property name="prefetchPolicy">
      <bean class="org.apache.activemq.ActiveMQPrefetchPolicy">
        <property name="queuePrefetch" value="1"/>
      </bean>
    </property>
    <property name="redeliveryPolicy">
      <bean class="org.apache.activemq.RedeliveryPolicy">
        <property name="initialRedeliveryDelay" value="1000"/>
        <property name="maximumRedeliveries" value="10"/>
        <property name="useExponentialBackOff" value="false"/>
      </bean>
    </property>
  </bean>

A2) No,I use a JTA transaction manager because my jms handlers are usually updating the database during message processing. I use the same TM for everything (there is only one instance of the TM), e.g.:

<bean id="atomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager" 
          init-method="init" destroy-method="close">
         <property name="forceShutdown" value="false"/>
    </bean>
    
    <bean id="atomikosUserTransaction" class="com.atomikos.icatch.jta.J2eeUserTransaction">
        <property name="transactionTimeout" value="300"/>
    </bean>
    
    <bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"
        depends-on="atomikosTransactionManager,atomikosUserTransaction">
        <property name="transactionManager" ref="atomikosTransactionManager"/>
        <property name="userTransaction" ref="atomikosUserTransaction"/>
    </bean>

And all the DMLC's are wired up like this:

<bean id="gatewayMessageListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"
        depends-on="transactionManager">
      <property name="connectionFactory" ref="queueConnectionFactoryBean"/>
      <property name="transactionManager" ref="transactionManager"/>
      <property name="destination" ref="gatewayMessageDestination"/>
      <property name="sessionTransacted" value="true"/>
      <property name="maxConcurrentConsumers" value="5"/>
      <property name="concurrentConsumers" value="1"/>
      <property name="receiveTimeout" value="5000"/>
      <property name="recoveryInterval" value="60000"/>
      <property name="autoStartup" value="true"/>
   </bean>

Note that in this DMLC example there is no handler wired up because this is being used to feed messages to a spring integration channel.

[EdwinDhondt]

Is it advisable to have multiple DMLCs all referencing the same connectionfactory bean ?

[Gary Russell]

Yes; that's a completely normal situation.

[EdwinDhondt]

Thanks, for the quick reply.
If it is ok to have multiple DMLC listener-containers (each referencing the same queueconnectionfactory) then is it also ok if each of those DMLCs contains listeners listening on the same queue ?
Eg. DMLC-1 contains listener01 with destination jms/queue01 and DMLC-02 contains another listener pointing to the same destination jms/queue01.
Is that a configuration that will work reliably ? Is it advisable, will a particular message only be consumed once-and-only-once ?

[Gary Russell]

You are asking the same questions in both this and the AMQP forum; but it appears you are only really interested in JMS.

As I said over in the AMQP forum, delivery to a single consumer is the responsibility of the broker; he doesn't care if two consumers happen to be using the same connection; one and only one consumer will receive a message from a queue.

If the session is transactional, and the message consumer rolls back the message, there is no guarantee the same consumer will get the redelivered message.