CXF
  1. CXF
  2. CXF-2760

implement useMessageIDAsCorrelationID for JMS Client

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.4, 2.1.9, 2.2.7
    • Fix Version/s: 2.2.8, 2.1.10
    • Component/s: Transports
    • Labels:
      None

      Description

      MQSeries servers often use the message ID of and incoming message as the correlation ID for an outgoing message. In order for a CXF client to communicate with an MQSeries server it needs to correlate the outgoing message with the incoming message using the message ID of the sent message.

      1. cxf-2760.patch
        42 kB
        Seumas Soltysik

        Issue Links

          Activity

          Hide
          Seumas Soltysik added a comment - - edited

          Patch for this issue has been attached.

          Show
          Seumas Soltysik added a comment - - edited Patch for this issue has been attached.
          Hide
          Seumas Soltysik added a comment -

          Any ideas as to when this patch might get reviewed?

          Show
          Seumas Soltysik added a comment - Any ideas as to when this patch might get reviewed?
          Hide
          Christian Schneider added a comment -

          I just tried to check your patch with the current trunk version but subversion says the patch is outdated. Did you build the patch for the trunk or the 2.1.x?
          It would also be great if you could write something on how the patch works and if you expect any side effects.

          Show
          Christian Schneider added a comment - I just tried to check your patch with the current trunk version but subversion says the patch is outdated. Did you build the patch for the trunk or the 2.1.x? It would also be great if you could write something on how the patch works and if you expect any side effects.
          Hide
          Seumas Soltysik added a comment -

          I created the patch from the 2.1.x branch with the expectation that is would be merged to the 2.2.x branch as well. If the trunk does not have this feature then it could be merged there as well.

          Show
          Seumas Soltysik added a comment - I created the patch from the 2.1.x branch with the expectation that is would be merged to the 2.2.x branch as well. If the trunk does not have this feature then it could be merged there as well.
          Hide
          Seumas Soltysik added a comment -

          As stated in the MQSeries world clients acting as request/reply servers often use the paradigm of using the messageID of the incoming message as the correlationID of the outgoing message. This means that a CXF client interacting with an MQSeries "server" needs to be able to correlate the request and the reply using the MessageID as opposed to a generated CorrelationID. The problem is that the MessageID for a JMS message being sent from a CXF client is not available until after the send() occurs. Therefore the JMSConduit needs to access the MessageID after the send(). To get access to the Message/MessageID, I had to create a non-anonymous MessageCreater to get access to the Message through a data member in the static class. At this point, the MessageID can be inserted into the correlation Map along with the Exchange. In the case where the reply message is sent from the server to a static Queue, the JMSConduit needs to ensure that it is only getting messages that it sent and not other messages. The idea behind the patch is to create a JMSListener on a per thread basis and then update the message selector to use the MessageID for each request/reply. Since the cache level on the listener is set to not cache consumers, a new consumer will be created using a new message selector after a send() from the JMSConduit. One downside of this is that a new consumer is created before every receive() which occurs every second by default. In the onMessage() call there is no need to wait on the send() being completed as the reply message cannot be received until the message selector is set after calling send().

          Show
          Seumas Soltysik added a comment - As stated in the MQSeries world clients acting as request/reply servers often use the paradigm of using the messageID of the incoming message as the correlationID of the outgoing message. This means that a CXF client interacting with an MQSeries "server" needs to be able to correlate the request and the reply using the MessageID as opposed to a generated CorrelationID. The problem is that the MessageID for a JMS message being sent from a CXF client is not available until after the send() occurs. Therefore the JMSConduit needs to access the MessageID after the send(). To get access to the Message/MessageID, I had to create a non-anonymous MessageCreater to get access to the Message through a data member in the static class. At this point, the MessageID can be inserted into the correlation Map along with the Exchange. In the case where the reply message is sent from the server to a static Queue, the JMSConduit needs to ensure that it is only getting messages that it sent and not other messages. The idea behind the patch is to create a JMSListener on a per thread basis and then update the message selector to use the MessageID for each request/reply. Since the cache level on the listener is set to not cache consumers, a new consumer will be created using a new message selector after a send() from the JMSConduit. One downside of this is that a new consumer is created before every receive() which occurs every second by default. In the onMessage() call there is no need to wait on the send() being completed as the reply message cannot be received until the message selector is set after calling send().
          Hide
          Christian Schneider added a comment -

          Normally I only do improvements on the trunk and some people from progress merge the fixes back to the branches. As I currently also have the problem that I need to talk to a service that returns the message id as the correlation id I have looked into the trunk if this is already possible.

          There you find a boolean messageIdPattern in JmsConduit that is set to true under certain conditions. I don´t completely understand it but this could also be a solution for our problem. Sadly this feature is not even in 2.2.7 and I have no information if or when it is backported.

          I think we should discuss this feature on the list if you did not already do this. It would be interesting what others say about this.

          Show
          Christian Schneider added a comment - Normally I only do improvements on the trunk and some people from progress merge the fixes back to the branches. As I currently also have the problem that I need to talk to a service that returns the message id as the correlation id I have looked into the trunk if this is already possible. There you find a boolean messageIdPattern in JmsConduit that is set to true under certain conditions. I don´t completely understand it but this could also be a solution for our problem. Sadly this feature is not even in 2.2.7 and I have no information if or when it is backported. I think we should discuss this feature on the list if you did not already do this. It would be interesting what others say about this.
          Hide
          Seumas Soltysik added a comment -

          I have made the fix to an internal branch off the 2.1.x line that I maintain and am looking to get it onto the 2.1.x and 2.2.x lines. Not sure it makes sense to port any changes from the trunk back to 2.1.x and 2.2.x as IIRC the JMS implementation/configuration is significantly different for trunk.

          Show
          Seumas Soltysik added a comment - I have made the fix to an internal branch off the 2.1.x line that I maintain and am looking to get it onto the 2.1.x and 2.2.x lines. Not sure it makes sense to port any changes from the trunk back to 2.1.x and 2.2.x as IIRC the JMS implementation/configuration is significantly different for trunk.
          Hide
          Christian Schneider added a comment -

          What I see as a problem is that the patch introduces a new configuration property that is not available on trunk. I think it would be a good idea to also introduce the property on trunk.
          The other thing is compatibility with messgeId pattern. Do you understand how the messageId pattern on trunk works? Does it solve the same problem?

          Show
          Christian Schneider added a comment - What I see as a problem is that the patch introduces a new configuration property that is not available on trunk. I think it would be a good idea to also introduce the property on trunk. The other thing is compatibility with messgeId pattern. Do you understand how the messageId pattern on trunk works? Does it solve the same problem?
          Hide
          Seumas Soltysik added a comment -

          It looks like what is on the trunk is trying to do the same thing as the patch I submitted. I need to dig into it a bit more but a couple of quick points:
          -I am not sure that the feature on the trunk is designed to work with static response queues
          -Given the differences between the JMSConduit on the trunk and 2.1.x, I am not sure how easy it will be to back-port.

          Show
          Seumas Soltysik added a comment - It looks like what is on the trunk is trying to do the same thing as the patch I submitted. I need to dig into it a bit more but a couple of quick points: -I am not sure that the feature on the trunk is designed to work with static response queues -Given the differences between the JMSConduit on the trunk and 2.1.x, I am not sure how easy it will be to back-port.
          Hide
          Willem Jiang added a comment -

          Just a quick note for the jms transport difference of trunk and 2.2.x branch.
          Last summer we did some change on the jms transport by leverage the GSoC project to implement soap of jms, and the change were not merged back to 2.2.x branch.

          If I remember right, the JmsConduit of 2.1.x and 2.2.x should share the same code.

          Seumas, if your patch introduce a new configure property, we should also support it in the trunk.

          Show
          Willem Jiang added a comment - Just a quick note for the jms transport difference of trunk and 2.2.x branch. Last summer we did some change on the jms transport by leverage the GSoC project to implement soap of jms, and the change were not merged back to 2.2.x branch. If I remember right, the JmsConduit of 2.1.x and 2.2.x should share the same code. Seumas, if your patch introduce a new configure property, we should also support it in the trunk.
          Hide
          Seumas Soltysik added a comment -

          Ok. I think I have a better idea of how this feature is implemented on the trunk. I am going to use this as a model for refactoring the 2.1.x line.

          Show
          Seumas Soltysik added a comment - Ok. I think I have a better idea of how this feature is implemented on the trunk. I am going to use this as a model for refactoring the 2.1.x line.
          Hide
          Seumas Soltysik added a comment -

          Started a thread to discuss this on the dev list.

          Show
          Seumas Soltysik added a comment - Started a thread to discuss this on the dev list.
          Hide
          Seumas Soltysik added a comment -

          Christian,
          Any thoughts on the issues raised on the dev list?
          Seumas

          Show
          Seumas Soltysik added a comment - Christian, Any thoughts on the issues raised on the dev list? Seumas
          Hide
          Seumas Soltysik added a comment -

          Attaching patch file based upon feed-back from Willem and Christian.

          Show
          Seumas Soltysik added a comment - Attaching patch file based upon feed-back from Willem and Christian.
          Hide
          Willem Jiang added a comment -

          Hi Seumas,
          I applied the patch into CXF 2.2.x-fix branch and 2.1.x-fix branch.
          I also remove the last two System.gc() of the JMSClientServerTest.java before committed the patch.

          Just one more thing, can you remove the code of "System.out.println" of the jms system test in your next patch?

          Show
          Willem Jiang added a comment - Hi Seumas, I applied the patch into CXF 2.2.x-fix branch and 2.1.x-fix branch. I also remove the last two System.gc() of the JMSClientServerTest.java before committed the patch. Just one more thing, can you remove the code of "System.out.println" of the jms system test in your next patch?
          Hide
          Christian Schneider added a comment -

          I have looked into the current releases. The issue went into 2.2.8 and 2.1.10. So I updated the Fix Versions.

          @Willem: is there some work open for this issue or can we close it?

          Show
          Christian Schneider added a comment - I have looked into the current releases. The issue went into 2.2.8 and 2.1.10. So I updated the Fix Versions. @Willem: is there some work open for this issue or can we close it?
          Hide
          Willem Jiang added a comment -

          It's should be closed, as we have some different implementation in CXF 2.3.0.

          Show
          Willem Jiang added a comment - It's should be closed, as we have some different implementation in CXF 2.3.0.

            People

            • Assignee:
              Willem Jiang
              Reporter:
              Seumas Soltysik
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development