Announcement Announcement Module
No announcement yet.
Very long delay before jms:message-driven-channel-adapter picks up message Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Very long delay before jms:message-driven-channel-adapter picks up message

    Hello all,

    I have a project that does a lot of work with JMS queues. Currently I am running this locally on a TC server developer instance. I have the JMS connection factory defined via JNDI and it is connecting to ActiveMQ just fine and a message is placed on the queue as it should. The problem is getting the message off of the queue. The ActiveMQ admin page shows the message is there and that there are several active consumers, yet that one message will sit on that queue sometimes for up to 5 min or even 10 minutes before it gets picked off by the message-driven-channel adapter. There is hardly any load at all, I get this even with one message and an idle system.

    So I am making use of the message-driven-channel adapter. I have tried it with ActiveMQ, ActiveMQ embedded, HornetQ and I see the same issue on each. I know that this uses the underlying JmsTemplate, but since I am seeing the problem across more than one MQ implementation I assume the problem is with my settings or with Springs JMS stuff. The code example below is just one of my adapters but most of them are similar. I have tried about every combination of the properties trying to fix the problem and have not had any success.

    Also to rule out some some sort of computer glitch I can confirm the behavior is the same on another developers machine.

    		channel="labelPostTransformerChannel" destination-name="${labelPostQueue}"
    		acknowledge="transacted" transaction-manager="transactionManager"
    		header-mapper="customJmsHeaderMapper" error-channel="labelPostErrorChannel"
    		concurrent-consumers="5" max-concurrent-consumers="10"
    		idle-consumer-limit="3" idle-task-execution-limit="3" />
    If anyone has any suggestions on how I can get to the bottom of this I would appreciate it.


  • #2
    Is there any delay in the sending system committing the transaction?

    If you turn on TRACE level logging, you should see the container looping waiting for a message.

    Have you tried the sample app?


    • #3

      Thanks for your reply. The container is definitely looping and waiting for a message. Transactions I had not tinkered with. Shutting off the transacted stuff fixed the issue, so now I know what the problem is. Let me drill in a little more to see if you can help me figure it out.

      Basically the application is pretty large and consists of several modules including multiple web-apps. Some of the web apps are deployed in one container while the others operate in another container(operating in a cluster). The communication flow between the web-apps within the same container and across containers are both done via JMS.

      So basically the general idea is some request comes in perhaps through a web interface or a rest post. Some stuff happens and it gets placed on a queue. Some other web-app reads the data off of that queue (using the message driven adapter) uses the transaction manager (same as is used for the database transactions) defined there to do some stuff with @Transactional annotated methods for DB operations, and then either finishes or plops it on yet another queue.

      The idea is that I don't want to use XA but if a database operation or other logic which happens in a @Transactional block fails I want the message to be re-queued. For the most part this seems to be working except for the issue I am trying to figure out. Apart from using AspectJ rather than the default proxy based interfaces I am mostly operating with the defaults for the transactional stuff. Where would you suggest upping my logging to figure out the cause?

      Thanks again,


      • #4

        Thanks again for your reply, you got me looking at the right thing. As it turns out in our dev profile (running locally) the TransactionAwareConnectionFactoryProxy was not configured. I have not had a chance to test this yet but it is most likely the problem.

        Thanks again,