JMS Message Correlation

Discussions

General J2EE: JMS Message Correlation

  1. JMS Message Correlation (4 messages)

    Hi, We have a system which in SIT testing will talk to another system using MQ queues. In our dev environments we don't have any MQ queues set up, but we have a simulation of the back end system we need to communicate with. We're using weblogic queues so that we can code to the JMS API and switch across to MQ in our SIT environment. This has worked well apart from one minor thing. When we do a sync. recieve() the system we talk to will copy the JMSMessageID into the JMSCorrelationID for the reply so to get the reply for the request we just sent we do : m.setText(request); m.setJMSReplyTo(replyQueue); sender.send(m); String messageId = m.getJMSMessageID(); sender.close(); QueueReceiver receiver = qsession.createReceiver(replyQueue, "JMSCorrelationID = '"+messageId+"'"); Sorry for formatting. This works fine, the message will get processed by an async listener which does : ... reply.setJMSCorrelationID(request.getJMSMessageID()); sender.send(reply); The problem we have is specifically with weblogic which modifies the correlation ID before delivering it. On the outbound message the ID is P when it arrives after the receive() call (when removing the selector) then correlation ID is N The same, but with an "N" on the front. Any idea what's going on here ? Can you not use the JMSMessageID > JMSCorrelationID mapping in Weblogic ? Thanks, Steve.

    Threaded Messages (4)

  2. Re: JMS Message Correlation[ Go to top ]

    I never rely on the JMS Message ID for anything. That's an internal ID used by the JMS provider and I don't like relying on it to have any meaning or any consistency at all. It's entirely possible that WebLogic uses P to indicate an unsent message and changes this to N once the message has been queued, or maybe it's even more complex and indicates whether the message is unqueued, queued, or dequeued. You just don't know because it's an internal implementation detail of WebLogic's JMS handling. The point is that a JMS Message Id can change during the message's lifecycle. As it says in the JMS Message documentation regarding the message id: "The exact scope of uniqueness is provider-defined". That translates as: "don't rely on how this works when you move from one JMS provider to another". My suggestion would be to supply the correlation ID with the request message if you can: m.setText(request); m.setJMSReplyTo(replyQueue); myId = /* generate a unique id */ m.setJMSCorrelationID(myId) /* send the JMS message */ QueueReceiver receiver = qsession.createReceiver(replyQueue, "JMSCorrelationID = '"+myId+"'"); Then at the other end you do this: reply.setJMSCorrelationID(request.getJMSCorrelationID()); /* send the JMS reply message */ To generate the correlation ID, you have a number of options: use a UUID, have a singleton factory incrementing a counter, have a more complex hi-lo factory generating the id, use the user id or thread name if you know the message will be unique at that scope, etc. It depends on the exact requirements and how your application works. If you don't have control over the system you're talking to then you're screwed because the people who built it either didn't understand enough about JMS or didn't care about making it portable across JMS providers. The best you can do is to build your test harness to simulate things somehow, without relying on the message id.
  3. Re: JMS Message Correlation[ Go to top ]

    I never rely on the JMS Message ID for anything. That's an internal ID used by the JMS provider and I don't like relying on it to have any meaning or any consistency at all. It's entirely possible that WebLogic uses P to indicate an unsent message and changes this to N once the message has been queued, or maybe it's even more complex and indicates whether the message is unqueued, queued, or dequeued. You just don't know because it's an internal implementation detail of WebLogic's JMS handling. The point is that a JMS Message Id can change during the message's lifecycle. As it says in the JMS Message documentation regarding the message id: "The exact scope of uniqueness is provider-defined". That translates as: "don't rely on how this works when you move from one JMS provider to another". My suggestion would be to supply the correlation ID with the request message if you can: m.setText(request); m.setJMSReplyTo(replyQueue); myId = /* generate a unique id */ m.setJMSCorrelationID(myId) /* send the JMS message */ QueueReceiver receiver = qsession.createReceiver(replyQueue, "JMSCorrelationID = '"+myId+"'"); Then at the other end you do this: reply.setJMSCorrelationID(request.getJMSCorrelationID()); /* send the JMS reply message */ To generate the correlation ID, you have a number of options: use a UUID, have a singleton factory incrementing a counter, have a more complex hi-lo factory generating the id, use the user id or thread name if you know the message will be unique at that scope, etc. It depends on the exact requirements and how your application works. If you don't have control over the system you're talking to then you're screwed because the people who built it either didn't understand enough about JMS or didn't care about making it portable across JMS providers. The best you can do is to build your test harness to simulate things somehow, without relying on the message id.
  4. Re: JMS Message Correlation[ Go to top ]

    Hey, look. If you double click the Post Message button, it posts twice.
  5. Re: JMS Message Correlation[ Go to top ]

    Hi, Thanks for your reply. In MQ it is standard practice to copy the message ID into the correlation ID of the reply message. There is nothing wrong with this and it seems a perfectly reasonable way to correlate messages. This is the way I believe most MQ systems correlate messages, and it is the way that the system we're talking to do it, we will receive a reply that has the correlation ID set the requests message ID, that's how we know it's the reply. From what I can gather, Weblogic seem to suggest that you should use your own correlation ID if you want correlate the requests and responses. Unfortunately this would involve giving our code some knowledge about the queueing system it was talking to which defeats the purpose. The message ID only seems to change when the receiver is running in a different VM, fortuantely for us our simulation of the backend system that will be using the queues runs in the same VM and so the message ID / correlation ID will work. It's a shame that Weblogic don't let you do this especially since that's the way many legacy queueing systems seem to work.