[ 
https://issues.apache.org/jira/browse/QPIDJMS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPIDJMS-189:
-----------------------------------
             Assignee: Robbie Gemmell
    Affects Version/s: 0.10.0
          Description: 
When a JMS application sets JMSCorrelationID on a Message, it can do so either 
using a JMSMessageID value (a String beginning with "ID:") or an 
application-specific string value. Previously we decided that the "ID:" prefix 
of a JMSMessageID should not be sent on the wire so other non-JMS client need 
not deal with it, and a message-id recieved from a non-JMS client would 
round-trip correctly as a correlation-id value. An annotation was used on 
messages to record whether an application-specific JMSCorrelationID value was 
in use so that recieving JMS clients would restore the 'ID:' prefix for 
JMSCorrelationID if needed. 

This approach has an issue in that if a correlation-id value is rountripped 
into a response message by a client/service that doesnt understand the 
annotations use and include it in the response, then the JMSCorrelationID value 
retrieved from the response message may not match the value sent on the 
original message. 

Additionally, as originally noticed on this JIRA (details below), a bug and 
loose test has meant that the client HAS begun sending the 'ID:' prefix for 
JMSMessageID values inadvertantly, which when roundtripped to a response 
message by a non-JMS peer, results in the JMSCorrelationID getting a second 
erroneous 'ID:' prefix added when the response is examined by the original JMS 
application.

This JIRA will serve to introduce changes to the JMSMessageID and 
JMSCorrelationID handling to help resolve these interop issues, changing things 
such that the 'ID:' prefix is deliberately sent on the wire and for a 
correlation ids is used in place of the annotation to discriminate between one 
which is a message id string and one which is an application specific string.

================
Original description

I am trying to use Qpid JMS client to send a message to a non-JMS application 
which returns a message to the client based on the request's reply-to property.
In order to correlate the response received from the non-JMS app with the 
request, I want to use the incoming message's JMSCorrelationID property.
The non-JMS application simply takes the incoming message's message-id property 
and puts it into the outgoing response's correlation-id property.

However, when I send a message using Qpid JMS with default configuration, e.g. 
using a connection URI like {{amqp://myhost:myport}}, then the message ID of 
the sent message retrieved via {{Message.getJMSMessageId()}} looks something 
like {{ID:aef45f-...}} and the message-id of the incoming request in the 
non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
correlation ID retrieved from the response via 
{{Message.getJMSCorrelationId()}} at the JMS client starts with 
{{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot be 
matched to the original message ID.

I have tracked down the problem to the inconsistent implementation of 
{{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
methods. The former only adds an _ID:_ prefix to the underlying message ID if 
it doesn't already contain that prefix whereas the latter always adds the 
prefix (unless the {{x-opt-app-correlation-id}} header is set).

The problem can be worked around by explicitly setting another connection ID 
prefix using the {{jms.connectionIDPrefix}} connection URI parameter ni order 
to define a different prefix than the default one (_ID_).

  was:
I am trying to use Qpid JMS client to send a message to a non-JMS application 
which returns a message to the client based on the request's reply-to property.
In order to correlate the response received from the non-JMS app with the 
request, I want to use the incoming message's JMSCorrelationID property.
The non-JMS application simply takes the incoming message's message-id property 
and puts it into the outgoing response's correlation-id property.

However, when I send a message using Qpid JMS with default configuration, e.g. 
using a connection URI like {{amqp://myhost:myport}}, then the message ID of 
the sent message retrieved via {{Message.getJMSMessageId()}} looks something 
like {{ID:aef45f-...}} and the message-id of the incoming request in the 
non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
correlation ID retrieved from the response via 
{{Message.getJMSCorrelationId()}} at the JMS client starts with 
{{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot be 
matched to the original message ID.

I have tracked down the problem to the inconsistent implementation of 
{{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
methods. The former only adds an _ID:_ prefix to the underlying message ID if 
it doesn't already contain that prefix whereas the latter always adds the 
prefix (unless the {{x-opt-app-correlation-id}} header is set).

The problem can be worked around by explicitly setting another connection ID 
prefix using the {{jms.connectionIDPrefix}} connection URI parameter ni order 
to define a different prefix than the default one (_ID_).

              Summary: update JMSMessageID and JMSCorrelationID handling to 
address interop issues with non-JMS peers  (was: Message correlation based on 
message ID does not work out of the box)

> update JMSMessageID and JMSCorrelationID handling to address interop issues 
> with non-JMS peers
> ----------------------------------------------------------------------------------------------
>
>                 Key: QPIDJMS-189
>                 URL: https://issues.apache.org/jira/browse/QPIDJMS-189
>             Project: Qpid JMS
>          Issue Type: Bug
>          Components: qpid-jms-client
>    Affects Versions: 0.9.0, 0.10.0
>            Reporter: Kai Hudalla
>            Assignee: Robbie Gemmell
>             Fix For: 0.11.0
>
>         Attachments: 
> 0001-WIP-QPIDJMS-189-candidate-for-changes-to-JMSMessageI.patch
>
>
> When a JMS application sets JMSCorrelationID on a Message, it can do so 
> either using a JMSMessageID value (a String beginning with "ID:") or an 
> application-specific string value. Previously we decided that the "ID:" 
> prefix of a JMSMessageID should not be sent on the wire so other non-JMS 
> client need not deal with it, and a message-id recieved from a non-JMS client 
> would round-trip correctly as a correlation-id value. An annotation was used 
> on messages to record whether an application-specific JMSCorrelationID value 
> was in use so that recieving JMS clients would restore the 'ID:' prefix for 
> JMSCorrelationID if needed. 
> This approach has an issue in that if a correlation-id value is rountripped 
> into a response message by a client/service that doesnt understand the 
> annotations use and include it in the response, then the JMSCorrelationID 
> value retrieved from the response message may not match the value sent on the 
> original message. 
> Additionally, as originally noticed on this JIRA (details below), a bug and 
> loose test has meant that the client HAS begun sending the 'ID:' prefix for 
> JMSMessageID values inadvertantly, which when roundtripped to a response 
> message by a non-JMS peer, results in the JMSCorrelationID getting a second 
> erroneous 'ID:' prefix added when the response is examined by the original 
> JMS application.
> This JIRA will serve to introduce changes to the JMSMessageID and 
> JMSCorrelationID handling to help resolve these interop issues, changing 
> things such that the 'ID:' prefix is deliberately sent on the wire and for a 
> correlation ids is used in place of the annotation to discriminate between 
> one which is a message id string and one which is an application specific 
> string.
> ================
> Original description
> I am trying to use Qpid JMS client to send a message to a non-JMS application 
> which returns a message to the client based on the request's reply-to 
> property.
> In order to correlate the response received from the non-JMS app with the 
> request, I want to use the incoming message's JMSCorrelationID property.
> The non-JMS application simply takes the incoming message's message-id 
> property and puts it into the outgoing response's correlation-id property.
> However, when I send a message using Qpid JMS with default configuration, 
> e.g. using a connection URI like {{amqp://myhost:myport}}, then the message 
> ID of the sent message retrieved via {{Message.getJMSMessageId()}} looks 
> something like {{ID:aef45f-...}} and the message-id of the incoming request 
> in the non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
> correlation ID retrieved from the response via 
> {{Message.getJMSCorrelationId()}} at the JMS client starts with 
> {{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot 
> be matched to the original message ID.
> I have tracked down the problem to the inconsistent implementation of 
> {{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
> methods. The former only adds an _ID:_ prefix to the underlying message ID if 
> it doesn't already contain that prefix whereas the latter always adds the 
> prefix (unless the {{x-opt-app-correlation-id}} header is set).
> The problem can be worked around by explicitly setting another connection ID 
> prefix using the {{jms.connectionIDPrefix}} connection URI parameter ni order 
> to define a different prefix than the default one (_ID_).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to