Results 1 to 10 of 10

Thread: JMS Outbound Gateway with IBM MQ

  1. #1
    Join Date
    Apr 2012
    Posts
    7

    Default JMS Outbound Gateway with IBM MQ

    Hello -
    I'm implementing an asynchronous request/response flow (using SI jms outbound-gateway) with IBM MQ where there separate request and response MQs. IBM MQ sets the Message ID of the JMS request so I'm trying to use the Correlation ID pattern to tie together request and response messages. From what I can tell, IBM MQ is setting the JMSCorrelationID on the response to be the hex encoded value of the request JMS correlation id. I believe this mismatch is causing the outbound gateway not to get the request message.

    My outbound gateway is defined as such:
    Code:
    	<int-jms:outbound-gateway id="mainframe"
    							  request-channel="mainframeRequest"
    							  request-destination="requestQueue"
    							  reply-channel="compareCollector"
    							  reply-destination="responseQueue"
    							  message-converter="mainframeMessageConverter"
    							  connection-factory="connectionFactory"
    							  receive-timeout="30000"  />
    Upon invocation, i receive a response message on the 'reply-destination' queue, but it is never picked up and the thread subsequently times out.

    I have a created a message converter that sets the correlation id on the request as such.. While i'm setting the JMSMessageID, it doesn't seem to matter because IBM MQ overwrites it with its own generated ID.

    Code:
    ...
    BytesMessage byteMsg = session.createBytesMessage();
    byteMsg.setJMSMessageID("123456");
    byteMsg.setJMSCorrelationID("123456");
    ..
    The response message has the following value for the JMSCorrelationID (hex and padded value of "123456").

    Code:
     JMSCorrelationID: ID:313233343536000000000000000000000000000000000000
    While I'm not certain, my guess is that the underlying Message Selector implemented by the outbound gateway is looking for
    Code:
    "123456"
    and not
    Code:
    "ID:313233343536000000000000000000000000000000000000".
    I'm not sure what options I have at this point as I can't seem to find a way to successfully correlate the request/response messages. Assuming the above is accurate, could I write a custom Message Selector that transforms the string correlation id to the hex equivalent? I just don't see anywhere to inject a custom message selector on the outbound gateway.

    Any advise/options would be much appreciated!!!

    Thanks,
    Shawn

  2. #2
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,840

    Default

    The Message ID is always generated upon sending (you should not set it yourself). We will take care of the CorrelationID in the outbound gateway so that it matches the generated ID as set by the provider.

  3. #3
    Join Date
    Apr 2012
    Posts
    7

    Default

    Thanks Mark for the quick reply.

    I tried not setting the Message ID, but same result.

    Code:
    ...
    //byteMsg.setJMSMessageID("123456");
    byteMsg.setJMSCorrelationID("123456");
    ...
    I also tried not setting the JMS Correlation ID.
    Code:
    ...
    //byteMsg.setJMSMessageID("123456");
    //byteMsg.setJMSCorrelationID("123456");
    ...
    Either way, the thread times-out waiting for the response even though the response is on the MQ.
    Code:
    org.springframework.integration.MessageTimeoutException: failed to receive JMS response within timeout of: 30000ms
    	at org.springframework.integration.jms.JmsOutboundGateway.handleRequestMessage(JmsOutboundGateway.java:389) ~[spring-integration-jms-2.1.0.RELEASE.jar:na]
    	at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:97) ~[spring-integration-core-2.1.0.RELEASE.jar:na]
    	at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73) ~[spring-integration-core-2.1.0.RELEASE.jar:na]
    	at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:114) ~[spring-integration-core-2.1.0.RELEASE.jar:na]
    	at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:101) ~[spring-integration-core-2.1.0.RELEASE.jar:na]
    Thanks,
    Shawn

  4. #4
    Join Date
    Apr 2012
    Posts
    7

    Default

    I found the following thread regarding how IBM (WebSphere) MQ sets the JMSCorrelationID. According to the post, IBM MQ prefixes an "ID:" string to the value of the JMSCorrelationID which adheres to the JMS Specification while ActiveMQ for instance does not follow this pattern.

    http://stackoverflow.com/questions/9...efixed-with-id

    Is it possible that the outbound gateway is not prefixing "ID:" for the JMSCorrelationID when attempting to select the response message?

  5. #5
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,840

    Default

    Whatever the ID value is - as generated by the provider upon send - it would go into our selector for the correlation ID. So, in a way it should not be relevant to Spring Integration whether the ID: prefix is present or not. That said, any chance you are affected by this WMQ bug on the *selector* side: http://www-01.ibm.com/support/docvie...id=swg1IZ37281

  6. #6
    Join Date
    Apr 2012
    Posts
    7

    Default

    Thanks Mark - I confirmed with our MQ team that the APAR described above is not the culprit as they are on a later version of MQ.

    I just wanted to clarify the pattern that I'm currently trying to use because I don't think I've done a good job describing it above.

    The following URL describes two async request/response messaging patterns - (1) JMS Message ID Pattern and (2) JMS Correlation ID Pattern.

    http://docs.oracle.com/cd/E13159_01/...html#wp1046209

    I'm currently trying to implement pattern (2) JMS Correlation Pattern.

    When you design a business service in Java, make sure that you set the value of JMS Correlation ID on the response to the value of JMS Correlation ID on the request before sending the JMS response to a queue.

    Does the JMS outbound-gateway support both patterns or one of the two? The mainframe application that I'm integrating with does echo the CorrelationID value that I set on the request (#2). It does not currently copy the Message ID to the Correlation ID field on the response (#1) - but I could request this if that is the preferred approach.

  7. #7
    Join Date
    Apr 2012
    Posts
    7

    Default

    Mark - thanks for your help.

    The issue described in this thread was resolved.

    Resolution required that the application processing the request message copy the "Message Id" from the request to the "Correlation ID" of the response. This is essentially following pattern (1) JMS Message ID Pattern as described above. After making this change, the JMS outbound-gateway successfully retrieved the response message.

    The application processing the request message was previously copying the "Correlation ID" from the request to the "Correlation ID" on the response. Pattern (2) above.

    Since these both seem to be valid async request/response patterns; an enhancement to the JMS outbound-gateway to support both may be a good idea.

  8. #8
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,840

    Default

    So, pattern #2 is for pipelines essentially, correct?... where the correlationID has been set upstream but there more steps before replying, so it needs to be copied at each step along the way?

  9. #9
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,840

    Default

    Actually, sorry... it's probably more common for the case where you share a common reply to queue and don't need to actually correlate individual requests with their replies.

    We do support the shared reply-to destination with JMS outbound-gateway. Simply, set the 'reply-destination' or 'reply-destination-name' attribute. Would that meet your needs for pattern #2?

  10. #10
    Join Date
    Apr 2012
    Posts
    7

    Default

    Yes. I agree....

    I didn't have that requirement in my case which is why a change on the processing side was able to resolve the issue; however a situation that would involves multiple hops that allowed the correlation ID to be passed-thru could benefit.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •