Announcement Announcement Module
No announcement yet.
Thread un-safety in jms:outbound-gateway with reply listener? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Yes, I see the payload now; much easier to see what's going on.

    No, I am saying your inbound gateway has 10 concurrent consumers; that means the listener container will receive up to 10 messages concurrently; you don't need to hand off each message, just process it on the container's thread.

    Your test case shows some very bizarre behavior; first it looks like every log record is duplicated which was very confusing at first.

    Second; take a look at
    >2013-06-09 16:35:10,771 DEBUG | testTaskExecutor-5 | org.springframework.integration.jms.JmsOutboundGat eway#0 received message:
    >2013-06-09 16:35:10,822 DEBUG | testTaskExecutor-5 | (inner bean)#2 received message: [Payload=34043c69:13f2b4b1eaa:-7ffe]
    >2013-06-09 16:35:10,839 DEBUG | testTaskExecutor-5 | postSend (sent=true) on channel 'routedActionChannel', message:
    This is the thread processing a request on the "server" side.

    >2013-06-09 16:35:20,804 WARN | testTaskExecutor-5 | failure occurred in gateway sendAndReceive
    org.springframework.integration.MessageTimeoutExce ption: failed to receive JMS response within timeout of: 10000ms
    at org.springframework.integration.jms.JmsOutboundGat eway.handleRequestMessage( 570)
    I don't see how that thread #5 can be blocked waiting for a reply in the ob gateway and also process a request. There must be 2 threads with the same name.

    Anyway, that's a diversion; using an async handoff shouldn't cause an issue.

    I see reply -7ff6 to -7ff8 being sent back but it never arrived at the ob gateway.

    I don't have HornetQ and don't have time to set it up; so I doubt I can run your test case as is.

    I have a couple of things for you to try.

    1. Remove that unnecessary task executor.
    2. Try with 3.0.0.M2 - we added some extra diagnostics on inbound gateways to log late replies.

    I'll try to pick this up again tomorrow; but with all that being said, your test case does not use a reply-listener.

    That means a completely different correlation strategy is being used - we generate UUID for each message and use a message selector to wait for the reply.

    So, given you are seeing the same problem with 2 different strategies tells me it's not a correlation problem; that leaves us with HornetQ and the inbound gateway; I can't see how the inbound adapter would drop the reply in this case, but 3.0.0.M2 will prove that for sure.

    I am going to try and get some sleep now.


    • #17
      OK that makes sense.

      The test case is self-contained, assuming you have access to a Maven nexus. You just have to run 'mvn install'. It will bootstrap its own standalone HornetQ. I tried to upload it with dependencies included but it was too big.

      Attached is a new test case and log:
      -Removed duplicate logging
      -Got rid of prototype scope on threadpool causing thread name overlap (sorry that must have been confusing)
      -Removed all channel executors
      -Updated to SI 3.0.0.M2


      Attached Files


      • #18
        Got it!!!

        Your statement about not using a reply-listener got me thinking. I thought that specifying that element just gave me a chance to configure it, and that the element itself and the underlying strategy was implicit.

        So, I put the reply-listener element back in, but with no attributes, and voila! Works like a charm.

        This fixes my problem, but it sounds like there may be something still going on when trying to use the non reply-listener strategy. I hope my test case is of some use to you.

        Thank you again for your assistance - it was invaluable. I hope you have not lost anywhere near as much sleep over this as I have.