qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPIDJMS-189) update JMSMessageID and JMSCorrelationID handling to address interop issues with non-JMS peers
Date Thu, 01 Sep 2016 15:03:21 GMT

    [ https://issues.apache.org/jira/browse/QPIDJMS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455694#comment-15455694

ASF subversion and git services commented on QPIDJMS-189:

Commit 443a54d6c9fa919253316f01bbeed83bb27e7aef in qpid-jms's branch refs/heads/master from
Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=443a54d ]

QPIDJMS-189: some test cleanup

> update JMSMessageID and JMSCorrelationID handling to address interop issues with non-JMS
> ----------------------------------------------------------------------------------------------
>                 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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message