Camel
  1. Camel
  2. CAMEL-4202

camel-jms - Using request/reply over persistent queues should be faster

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.7.1
    • Fix Version/s: 2.8.2, 2.9.0
    • Component/s: camel-jms
    • Labels:
      None

      Description

      See nabble
      http://camel.465427.n5.nabble.com/slow-reply-for-jms-component-when-url-contains-replyTo-tp4563075p4563075.html

      When using persistent replyTo queues for request/reply over JMS, then the ReplyManager should be faster to pickup replies.
      The default spring-jms timeout is 1 sec and it impacts the performance.

      Likewise the receiveTimeout should not be set on the reply managers as that does not apply here.

        Activity

        Hide
        Claus Ibsen added a comment -

        Okay I think there is a tradeoff if we lower the spring receiveTimeout to lower than 1 sec. For example if we use 1 millis, then it will overload and send pull packets to the AMQ broker to receive messages.

        The reason why temporary queues is faster is because they dont have any JMSMessageListener as the persistent does. So with temporary queues it can pull every 1sec and pickup messages as fast as possible, as the received message is always for the reply manager.

        Show
        Claus Ibsen added a comment - Okay I think there is a tradeoff if we lower the spring receiveTimeout to lower than 1 sec. For example if we use 1 millis, then it will overload and send pull packets to the AMQ broker to receive messages. The reason why temporary queues is faster is because they dont have any JMSMessageListener as the persistent does. So with temporary queues it can pull every 1sec and pickup messages as fast as possible, as the received message is always for the reply manager.
        Hide
        Claus Ibsen added a comment -

        A workaround is for the end user to use ?receiveTimeout=250, to eg pull messages 4 times per sec and thus be 4x faster.

        Show
        Claus Ibsen added a comment - A workaround is for the end user to use ?receiveTimeout=250, to eg pull messages 4 times per sec and thus be 4x faster.
        Hide
        Claus Ibsen added a comment -

        If there is an use case for using persistent queues that are exclusive for the Camel consumer, then we can avoid using JMSMessageSelector and thus be as fast as temporary queues.

        Show
        Claus Ibsen added a comment - If there is an use case for using persistent queues that are exclusive for the Camel consumer, then we can avoid using JMSMessageSelector and thus be as fast as temporary queues.
        Hide
        Claus Ibsen added a comment -

        The reason why the persistent reply to example at the nabble discussion, is because Camel will have to use a Dummy value for JMSMessageSelector when there is no expected replies to receive. And it thus takes 1 sec. for it to timeout, before it can update the JMSMessageSelector with the CorrelationsIDs to receive.

        We may try to suspend/resume the message listener container, but we could potential end up with some synchronized issue where we would suspend the listener, where as in the mean time on another thread a new message is being send. And thus we may miss resume the listener. Therefore we end up not pulling the message from the AMQ broker.

        We should add some documentation / FAQ as the drawbacks of using persistent queues.

        Show
        Claus Ibsen added a comment - The reason why the persistent reply to example at the nabble discussion, is because Camel will have to use a Dummy value for JMSMessageSelector when there is no expected replies to receive. And it thus takes 1 sec. for it to timeout, before it can update the JMSMessageSelector with the CorrelationsIDs to receive. We may try to suspend/resume the message listener container, but we could potential end up with some synchronized issue where we would suspend the listener, where as in the mean time on another thread a new message is being send. And thus we may miss resume the listener. Therefore we end up not pulling the message from the AMQ broker. We should add some documentation / FAQ as the drawbacks of using persistent queues.
        Hide
        Claus Ibsen added a comment -

        A new option is to be introduced: replyToType and its an enum with the following options:
        Temporary, Shared, Exclusive

        So if you set the replyToType=Exclusive then Camel assumes the reply queue is exclusive for Camel and will not use any JMS message selectors, as it pickup all the messages arriving on that queue. This means its as fast as temporary queues.

        In fact this will also help highlight the fact the current fixed replyTo queues are consider Shared by default.

        I will add better documentation at the jms page to help highlight this.

        Show
        Claus Ibsen added a comment - A new option is to be introduced: replyToType and its an enum with the following options: Temporary, Shared, Exclusive So if you set the replyToType=Exclusive then Camel assumes the reply queue is exclusive for Camel and will not use any JMS message selectors, as it pickup all the messages arriving on that queue. This means its as fast as temporary queues. In fact this will also help highlight the fact the current fixed replyTo queues are consider Shared by default. I will add better documentation at the jms page to help highlight this.
        Hide
        Claus Ibsen added a comment -

        The replyToType=Exclusive is exclusive per CamelContext. So if you run in a clustered environment, then each node should use an unique replyTo destination name.

        See discussion on nabble on that link from the top.

        Show
        Claus Ibsen added a comment - The replyToType=Exclusive is exclusive per CamelContext. So if you run in a clustered environment, then each node should use an unique replyTo destination name. See discussion on nabble on that link from the top.
        Hide
        Claus Ibsen added a comment -

        Patch with code

        Show
        Claus Ibsen added a comment - Patch with code
        Hide
        Claus Ibsen added a comment -

        Updated wiki page with documentation

        Show
        Claus Ibsen added a comment - Updated wiki page with documentation

          People

          • Assignee:
            Claus Ibsen
            Reporter:
            Claus Ibsen
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development