[
https://issues.apache.org/activemq/browse/CAMEL-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56232#action_56232
]
Marat Bedretdinov edited comment on CAMEL-2249 at 12/2/09 5:26 PM:
-------------------------------------------------------------------
Hi Christian,
I generally agree that JMS Message correlationID value should supersede the
messageID value. Realize though that both configuration assertions and the
statement I just made in the previous sentence are all out of band agreements.
So one can argue either way.
However, let me give you an example when this will break down. Certain brokers,
namely IBM MQ will modify your correlationID value using their proprietary
encoding. So what you're going to get back in the reply message will be very
different from what you set on the request message on the producer side.
So here the scenario:
produce -> 1 -> consume - > produce -> 2 -> consume
--------------- ActiveMQ ------------------------------ IBM MQ
consume <- 4 <- produce <- consume <- 3 <- produce
1. correlationID = C, messageID = M
2. correlationID = C!, messageID = M1
3. correlationID = M1, messageID = M2
4. correlationID = C
C! - is IBM mangled C value
I'd check with Suemas and ask him to review your changes and run against the
tests suites as I suspect if your changes were to be applied certain tests that
depend on Camel will fail.
Cheers,
Marat
was (Author: maratb):
Hi Christian,
I generally agree that JMS Message correlationID value should supersede the
messageID value. Realize though that both configuration assertions and the
statement I just made in the previous sentence are all out of band agreements.
So one can argue either way.
However, let me give you an example when this will break down. Certain brokers,
namely IBM MQ will modify your correlationID value using their proprietary
encoding. So what you're going to get back in the reply message will be very
different from what you set on the request message on the producer side.
So here the scenario:
produce -> 1 -> consume - > produce -> 2 -> consume
ActiveMQ IBM
MQ
consume <- 4 <- produce <- consume <- 3 <- produce
1. correlationID = C, messageID = M
2. correlationID = C!, messageID = M1
3. correlationID = M1, messageID = M2
4. correlationID = C
C! - is IBM mangled C value
I'd check with Suemas and ask him to review your changes and run against the
tests suites as I suspect if your changes were to be applied certain tests that
depend on Camel will fail.
Cheers,
Marat
> Wrong handling of useMessageIDAsCorrelationID
> ---------------------------------------------
>
> Key: CAMEL-2249
> URL: https://issues.apache.org/activemq/browse/CAMEL-2249
> Project: Apache Camel
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Christian Schneider
> Attachments: camel-jms-correlation.patch
>
>
> Camel jms seems to contain two bug in correlation id handling.
> The first shows when you have a sender that has
> UseMessageIDAsCorrelationID="false" and a server that has
> UseMessageIDAsCorrelationID="true". If you send a message with
> correlationId="a" then the response message will contain
> correlationId="<request message id>". Even if this could be a valid behaviour
> as you wanted UseMessageIDAsCorrelationID="true" I don´t think it makes sense
> as the sender will not be able to correlate the message. So for this case I
> propose to only set the correlation id to the request message id on the
> server if the correlation id of the request was not set.
> The second bug seems to hide the first bug. Perhaps someone found a quick
> (and wrong way to make the tests work). It shows when you set
> UseMessageIDAsCorrelationID="true" on both client and server. If you send a
> message with correlation id = "a" the client sends it out with this
> correlation id. The server then sets the correlation id to the request
> message id (first bug). Then on the client the reply is received. After that
> the correlation id is set back to "a" on the client. So the tests think all
> is well. This part of the code should be removed.
> I have marked both problems in the code with FIXME markers in my patch. I can
> also provide a patch with the solution but first I wanted to only show the
> problem and provide a failing test.
> Hope my explanations were not to confused ;-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
