Announcement Announcement Module
No announcement yet.
DefaultMessageListenerContainer sending messages to DLQ under load Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • DefaultMessageListenerContainer sending messages to DLQ under load


    We've run into an interesting problem with our MDP's under heavy load (sending a couple thousand messages to a queue).

    It seems that the container doesn't even process the vast majority of the messages (> 80%) but appears to send them directly to the DLQ (in Tibco, $sys.undelivered).

    We are seeing no errors in the application server log, our messages just aren't being delivered and when we check the dlq, all the messages are there with no indication of why this is the case.

    We are running Spring 2.5.4 on Jboss 4.2.3 under JDK 1.6. We've seen this problem using either the Jboss TM or a standalone Atomikos TM.

    This does not seem to occur under light load (a few dozen messages at a time).

    I've tried setting max concurrent consumers from 5 to 1 and it still occurs. Our config is:
            <!-- MDP config -->
    	<bean id="PPSInboundMessageContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"
    	    <property name="connectionFactory" ref="queueConnectionFactoryXa"/>
    	    <property name="transactionManager" ref="transactionManager"/>
    	    <property name="destinationName" value="${queue.pps.inbound}"/>
    	    <property name="destinationResolver" ref="tibcoDestinationResolver"/>
    	    <property name="messageListener" ref="PPSInboundMessageListener"/>
    	    <property name="sessionTransacted" value="true"/>
    	    <property name="maxConcurrentConsumers" value="1"/>
    	    <property name="receiveTimeout" value="5000"/>
    	    <property name="recoveryInterval" value="60000"/>
    	    <property name="autoStartup" value="true"/>
    This is a show stopper for us. I'd appreciate any insight.

  • #2
    I am also see the same behaviour with DMLC.


    • #3
      We resolved the problem...

      It turns out it was a Tibco issue with some of the queue properties we have set.

      We had the maxRedelivery set to 2 and the prefetch set to 5. Everytime the message container would receive a message, the underlying message consumer would actually fetch 5 messages but we only process one. The other 4 are considered 'delivered' but put back in the queue. Thus, after the second delivery, 3 of the original 5 messages were considered to have exceeded the redelivery threshold and put in the undelivered queue without ever having been processed.

      The solution was to set the prefetch to 'none'. Hope this helps someone else out.