Announcement Announcement Module
Collapse
No announcement yet.
How to thread pool a JMS listener Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to thread pool a JMS listener

    I am now setting up a JMS subscriber listener as follows with the goal of achieving a pool of 5 threads listening to topATopic, however, what I see at runtime is multiple consumer processing the same record*#of consumers. I am assuming I am doing something wrong.

    Code:
    <bean id="messageListener" class="com.abc.app.mdp.Receiver">
    <property name="bean" ref="bean" />
    </bean>

    <jms:listener-container container-type="default"
    connection-factory="connectionFactory" acknowledge="auto" concurrency="5" destination-type="topic" prefetch="1" cache="none" >
    <jms:listener destination="topCli_Service" ref="messageListener"
    method="onMessage" subscription="AProjectSubscriber" />
    </jms:listener-container>

    <bean id="connectionFactory" class="org.springframework.jndi.JndiObjectFactoryB ean">
    <property name="jndiName" value="jms/jms-top-notx" />
    </bean>

    Thoughts?

  • #2
    What you are seeing is correct behavior for a JMS topic. With a JMS topic, every subscription to the topic receives a copy of the same message. Because of the semantics with topics, there is no point to using concurrent consumers. If you want concurrent consumers, then you will need to use a JMS queue where consumers compete for messages.

    Bruce

    Comment


    • #3
      Originally posted by bsnyder View Post
      What you are seeing is correct behavior for a JMS topic. With a JMS topic, every subscription to the topic receives a copy of the same message. Because of the semantics with topics, there is no point to using concurrent consumers. If you want concurrent consumers, then you will need to use a JMS queue where consumers compete for messages.
      Bruce, do I get this right: concurrent processing of messages from a topic is not possible with Spring DMLC? Is this a limitation provided by the JMS 1.x spec (seems as this has been removed in JMS2)? What would be the problem when using concurrent consumers? Is this only related to the danger of receiving the same message twice (for one consumer)? There should not be a problem for different consumers accessing the topic at the same time as every of them expexcts to receive the message copy, correct?

      Thanks,
      Marek

      Comment


      • #4
        Originally posted by mneumann View Post
        Bruce, do I get this right: concurrent processing of messages from a topic is not possible with Spring DMLC? Is this a limitation provided by the JMS 1.x spec (seems as this has been removed in JMS2)? What would be the problem when using concurrent consumers? Is this only related to the danger of receiving the same message twice (for one consumer)? There should not be a problem for different consumers accessing the topic at the same time as every of them expexcts to receive the message copy, correct?

        Thanks,
        Marek
        It's not about the DMLC not being able to do this, it's just simply the definition of JMS topics from the JMS spec. The JMS spec defines JMS topics as any messages sent to the topic are automatically delivered to all subscribers. So putting more than one consumer on the topic is not going to work down the messages in the topic any faster (because all subscribers receive all messages so more consumers does not mean faster consumption). This has nothing to do with receiving the same message twice. The alternative to JMS topics is JMS queues where a each message sent to the queue is delivered once and only once to a single consumer. So putting multiple consumers on a queue will actually work down the messages in the queue quicker (because each message is delivered to a single consumer so more consumers equals faster consumption). There is no problem putting multiple consumers on a topic per se, it's just that doing so will not help you consume messages any faster.

        Bruce

        Comment

        Working...
        X