Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-5907

CXF's JMSConfiguration replyToDestination does not have any effect

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • jboss-fuse-6.3
    • jboss-fuse-6.2.1
    • CXF
    • % %
    • Hide

      So, here's how the flow is the attached example,

      CXF Client ---- > ActiveMQ-Broker1 ---- > ActiveMQ-Broker2

      1. Created a JMS-To-JMS bridge between ActiveMQ-Broker1 and ActiveMQ-Broker2.
      2. ActiveMQ-Broker2 is being pre-created with a queue named, 'BLA_BLA'.
      3. CXF Client sends a message to 'CompositeQueue.q' on ActiveMQ-Broker1, which is then received by ActiveMQ-Broker2.
      4. Unless, we don't specify a 'replyDestination' on JMSConfiguration, ActiveMQ-Broker1 creates a 'temp' queue for acking the messages.
      5. Once the message from 'CompositeQueue.q' is received by ActiveMQ-Broker2, this broker still creates a 'temp' for acking the message, because it does have any idea about how to handle the acknowledgement message.

      6. Now, if we specify, 'replyToDestination=BLA_BLA", and then send the message, 'ActiveMQ-Broker1' or 'ActiveMQ-Broker2' still does not have any idea about where to send the 'Reply' message, because with JMSReplyTo is not set with this parameter.
      7. If we specify, 'replyDestination=BLA_BLA', and then send the message, 'ActiveMQ-Broker1' gets to read the JMSReplyTo destination and it creates a queue, 'BLA_BLA' for the 'acknowledgement' messages. However, since the message is also received by 'ActiveMQ-Broker2', it does not have any idea about where to provide the 'ack' messages and for this purpose, it still creates a temp:// queue.

      8. Therefore, the use case of 'replyToDestination' can only be valid and tested, if 'ActiveMQ-Broker2' knows where to put 'ack' messages, and these messages can then be replied to the queue in 'ActiveMQ-Broker1' and then from there the client can come to know.

      • Download any ActiveMQ version and created a queue named, 'BLA_BLA'.
      <destinations>
            <queue physicalName="BLA_BLA"/>
        </destinations>

      In the cxf spring client xml file, set 'replyToDestination="BLA_BLA".

      Show
      So, here's how the flow is the attached example, CXF Client ---- > ActiveMQ-Broker1 ---- > ActiveMQ-Broker2 1. Created a JMS-To-JMS bridge between ActiveMQ-Broker1 and ActiveMQ-Broker2. 2. ActiveMQ-Broker2 is being pre-created with a queue named, 'BLA_BLA'. 3. CXF Client sends a message to 'CompositeQueue.q' on ActiveMQ-Broker1, which is then received by ActiveMQ-Broker2. 4. Unless, we don't specify a 'replyDestination' on JMSConfiguration, ActiveMQ-Broker1 creates a 'temp' queue for acking the messages. 5. Once the message from 'CompositeQueue.q' is received by ActiveMQ-Broker2, this broker still creates a 'temp' for acking the message, because it does have any idea about how to handle the acknowledgement message. 6. Now, if we specify, 'replyToDestination=BLA_BLA", and then send the message, 'ActiveMQ-Broker1' or 'ActiveMQ-Broker2' still does not have any idea about where to send the 'Reply' message, because with JMSReplyTo is not set with this parameter. 7. If we specify, 'replyDestination=BLA_BLA', and then send the message, 'ActiveMQ-Broker1' gets to read the JMSReplyTo destination and it creates a queue, 'BLA_BLA' for the 'acknowledgement' messages. However, since the message is also received by 'ActiveMQ-Broker2', it does not have any idea about where to provide the 'ack' messages and for this purpose, it still creates a temp:// queue. 8. Therefore, the use case of 'replyToDestination' can only be valid and tested, if 'ActiveMQ-Broker2' knows where to put 'ack' messages, and these messages can then be replied to the queue in 'ActiveMQ-Broker1' and then from there the client can come to know. Download any ActiveMQ version and created a queue named, 'BLA_BLA'. <destinations> <queue physicalName= "BLA_BLA" /> </destinations> In the cxf spring client xml file, set 'replyToDestination="BLA_BLA".
    • Sprint 7 - towards CR2

    Description

      • A JMS producer creates a message. It has the option to ask the receiver to respond to a specific address. Therefore there is a field called JMSReplyTo, https://docs.oracle.com/javaee/6/api/javax/jms/Message.html#setJMSReplyTo%28javax.jms.Destination%29
      • There is a need of this field to be populated with TEST.REPORT.RRESP.
      • The receiver reads the JMSReplyTo field (received with the message). If he is well behaved he will replies at the destination provided and send a message to TEST.REPORT.RRESP.
      • The real scenario is with IBM MQ but with activemq you can imagine that you have composite queues defined, see: http://activemq.apache.org/virtual-destinations.html so that the name which is used by the receiver for replying: TEST.REPORT.RRESP is different from the name the producer is listening to the response TEST.REPORT.RESP.
      • The producer receives the response at TEST.REPORT.RESP

      Now the configuration with CXF is as follows:

      • If you have the same queue name on both sides you set
      <property name="replyDestination" value="TEST.REPORT.RESP" />

      and you get two things:

      • The header of the message is populated with JMSReplyTo = TEST.REPORT.RESP
      • The producer is listening to get an answer at TEST.REPORT.RESP
      • The thing is that the receiver does not know of TEST.REPORT.RESP. and needs to send the reply to TEST.REPORT.RRESP. This is not hard coded at the receiver level as for messages sent by other producers he may need to reply to TEST.REPORT.RRESP2. But, that's what the JMSReplyTo field is for, the producer is telling the receiver where he needs to send the response to. So now I want to keep my producer listening to TEST.REPORT.RESP, which is set by <property name="replyDestination" value="TEST.REPORT.RESP" /> but I want him to send a different value in the message header and that's what <property name="replyToDestination" value="TEST.REPORT.RRESP" /> is for. But it is not happening.

      There is the need to use the JMSReplyTo header (using replyToDestination) and specify the queue from where the reply is sent to. This is different from where the reply is read from (replyDestination). The reason behind that is that mq brokers are used in conjunction with mq local managers. The topology is similar in some extend to a network of brokers. The local queues have names that are different, meaning the reply sent by the server to queue local_B is forwarded to the queue local_A on a different machine where the client is listening to.

      Attachments

        Issue Links

          relates to

          CXF-5788 Loading...

          CXF-7008 Loading...

          Activity

            People

              rhn-support-tasato Tadayoshi Sato
              rhn-support-vgohel Viral Gohel
              Martin Basovnik Martin Basovnik (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: