-
1. Re: JMSMessageID in Messaging cluster
clebert.suconic Aug 31, 2007 8:56 AM (in response to beve)The messageId is being set on the ServerSide, not on clientSide any more.
When you do createTextMessage, the getJMSMessageId is aways going to be:
JMSMessageID = ID:JBM-0
And this will be set to a valid ID once the message is received on the Server endpoints. -
2. Re: JMSMessageID in Messaging cluster
clebert.suconic Aug 31, 2007 8:56 AM (in response to beve)Maybe you could use something else, like a GUID property to correlate the messages?
-
3. Re: JMSMessageID in Messaging cluster
beve Aug 31, 2007 9:20 AM (in response to beve)Hi,
we are calling the gettting the JMSMessageID after the send method returns. My understanding is that the jms provider will generate the JMSMessageID when it receives the message. The id looks like a valid id (it is not "ID:JBM-0").
The senario we have is that when a consumer retrieves the jms message from a clustered queue, the message id is not the same as the one the client has. Thus correlation using the message id does not work and one has to set a custom correlation id on the message prior to sending.
Yes, this we are currently using a custom genererated GUID to correlate the messages and this works fine.
The reason for posting is that we have been been correlating messages using the message id with JBoss ESB, and with version 1.3 this worked as expected. Could you just confirm that we can no longer do this and the only option for clients is to use a custom correlation id? We need to make changes to relect this.
Thanks,
Daniel -
4. Re: JMSMessageID in Messaging cluster
clebert.suconic Aug 31, 2007 10:23 AM (in response to beve)Just after I sent you the message, I realized about getting sending MessageID after the send.. .so my bad about that...
And I see that the ID is changed on the cluster:
http://jira.jboss.org/jira/browse/JBMESSAGING-1063
I have changed the testcase to replicate the bug -
5. Re: JMSMessageID in Messaging cluster
beve Aug 31, 2007 10:25 AM (in response to beve)Hi again,
I've just run some more test on this and this is what I'm seeing.
The message id is set after the send method returns.
Every second message that our consumer receives gets a different message id. So every other call will be correlated correctly and every other will not. Could this have anything to do with the routing policy, like every other message is moved to a different nodes queue and therefore getting a different id? I'm obviously just guessing here:)
Let me know if there is anything you would like me to test or any information that you would like me to provide.
Thanks,
Daniel -
6. Re: JMSMessageID in Messaging cluster
beve Aug 31, 2007 10:46 AM (in response to beve)Thanks for verifying this! Sorry about my last post...I was writing it and after I posted it I saw that you had already answered :)
Regards,
Daniel -
7. Re: JMSMessageID in Messaging cluster
clebert.suconic Sep 11, 2007 2:16 PM (in response to beve)Daniel,
Keeping the same ID doesn't work for us any more, after we have changed the schema.
Changing this now would require a lot of effort on testing and reimplementing things...
One thing we could do easily (it is implemented this way now on trunk) is set the CorrelationID when the message is transfered over the cluster. Would that be okay for you? -
8. Re: JMSMessageID in Messaging cluster
aslak Sep 11, 2007 6:04 PM (in response to beve)As far as the JMS 1.1 Specification goes on the topic:
----------------------------
3.4.3 JMSMessageID
The JMSMessageID header field contains a value that uniquely identifies each
message sent by a provider.
...
A JMSMessageID is a String value which should function as a unique key for
identifying messages in a historical repository. The exact scope of uniqueness is
provider defined. It should at least cover all messages for a specific installation
of a provider where an installation is some connected set of message routers.
...
3.4.5 JMSCorrelationID
A client can use the JMSCorrelationID header field to link one message with
another. A typical use is to link a response message with its request message.
...
Since each message sent by a JMS provider is assigned a message ID value, it is
convenient to link messages via message ID.
...
In some cases, an application (made up of several clients) needs to use an
application-specific value for linking messages.
...
----------------------------
I'm not 100% sure, but I think the text 'a specific installation of a provider where an installation is some connected set of message routers'
could be hinting at a cluster?
The specification is clear that a MessageID is suppose to uniquely identify a Message. By changing the MessageID
it no longer identifies the original Message. It now identifies a new Message, unknown to the sender.
Common Practice...
The two common correlation patterns are:
- Correlation ID Pattern
The receiver copies the request Correlation ID to the response Correlation ID.
- Message ID Pattern
The receiver copies the request Message ID to the response Correlation ID.
I think it would be wrong of the JMS provider to force the use of one over the other. -
9. Re: JMSMessageID in Messaging cluster
beve Sep 12, 2007 2:50 AM (in response to beve)Hi Clebert,
One thing we could do easily (it is implemented this way now on trunk) is set the CorrelationID when the message is transfered over the cluster. Would that be okay for you?
I think that the JMSCorrelationID should always travel with the Message over the cluster as it is set by applications, but I think that this what you mean. This currently works with JBM1.3 and JBM1.4 and we will change the default behaviour for the ESB to always set the outgoing correlation id. We were previously using the second pattern mentioned in aslak's post (setting the correlation id to the message id).
I do think that the message id should not be changed in the cluster but if this will be the case in a later release then that's fine.
Thanks for your help!
/Daniel -
10. Re: JMSMessageID in Messaging cluster
clebert.suconic Sep 12, 2007 11:50 PM (in response to beve)Thanks guys...
I won't change the MessageID along the cluster.. I'm fixing that