Announcement Announcement Module
Collapse
No announcement yet.
multiple DefaultMessageListenerContainer instances? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • multiple DefaultMessageListenerContainer instances?

    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?

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

    Comment


    • #3
      ConnectionFactory question?

      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.

      Comment


      • #4
        Originally posted by lloftin View Post
        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.:

        Code:
        <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.:

        Code:
        <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:

        Code:
        <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.

        Comment


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

          Comment


          • #6
            Yes; that's a completely normal situation.

            Comment


            • #7
              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 ?

              Comment


              • #8
                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.

                Comment

                Working...
                X