[OASIS Issue Tracker] (AMQPBINDMAP-15) update handling of correlation ID for interop

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/AMQPBINDMAP-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62892#comment-62892 ] 

Robert Gemmell commented on AMQPBINDMAP-15:
-------------------------------------------

In thinking things through again([1]), I do think the only approach to take is to just send the full JMSMessageID String value on the wire, including the "ID:" prefix, but also that we would then actually just get rid of the "x-opt-app-correlation-id" annotation entirely, which I hadn't spotted before when adding my thoughts above.

JMSMessageID values will then always carry the required "ID:" prefix when sent by the client as AMQP strings, as recommended by the mapping. If a client implementation allows for sending the other AMQP id types as the JMSMessageID then obviously those wont have the "ID:" on the wire as they aren't strings, but the receiving client would simply synthesize the "ID:" as it would presently, along with the included encoding prefix used to allow round tripping the AMQP value through the application layer as a String and back into the JMS Message if later used as a JMSCorrelationID value. We would additionally need a way to handle strings that arrive without the "ID:" prefix (e.g. existing JMS clients, non-JMS clients), which we didn't need before.

If a JMSMessageID value was then retrieved and used as a correlation id, the "ID:" value would then also be preserved on the wire when sent as a string value, removing the need for the receiving client to do anything special because the value inherently allows distinction between the JMSCorrelationID being a JMSMessageID or application-specific value. By supporting round-tripping the non-string AMQP message-id types on received messages into the application as a JMSMessageID String value and back into the JMS message as a JMSCorrelationID, we would already provide a means for applications to send the non-string AMQP correlation-id values if so desired. I think there is no need to also support supplying those same values without the "ID:" prefix as well as with it, or for those values to be distinguishable as either a JMSMessageID or application-specific value, we would simply require they are always treated as ID: prefixed values. This is actually what the existing mapping already specifies for behaviour when setting correlation id, which I had obviously forgotten. As a result, we then dont need the annotation here anymore either, and could get rid of it.

[1] This came up again recently in part due to a bug in a particular client impl, meaning it has unwittingly begun sending the "ID:" prefix on the wire in its JMSMessageID values, leading to a related issue with correlation-id interop behaviour with non-JMS clients since other code areas don't expect it to have done that.

> update handling of correlation ID for interop
> ---------------------------------------------
>
>                 Key: AMQPBINDMAP-15
>                 URL: https://issues.oasis-open.org/browse/AMQPBINDMAP-15
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC
>          Issue Type: Bug
>          Components: JMS Mapping
>    Affects Versions: wd06
>            Reporter: Steve Huston
>            Assignee: Robert Gemmell
>            Priority: Blocker
>
> An issue with interop between JMS and non-JMS clients when using correlation ID values on messages.
> If 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 from a non-JMS client would round-trip correctly as a correlation-id value. For this reason, and also to accomodate the 4 different types of message-id that the core spec defines (string, ulong, uuid, and binary) and ensure preservation of the AMQP wire type when round-tripping these values into the JMS application layer and back to the AMQP layer, the client manages/translates the message-id and correlation-id values, and utilises the x-opt-app-correlation-id message annotation to record when an application-specific JMSCorrelationID value is in use.
> An issue arises if an application-specific string is sent as the JMSCorrelationID value on a request message (from JMS app A), and received by a a non-JMS app B which then sends a new reply message containing the same correlation-id value. If the non-JMS client/app B does not set the x-opt-app-correlation-id on its reply message, then the JMS app A receiving the reply message will then treat the correlation-id value as being representative of a JMSMessageID value and return incorrectly return an "ID:" prefixed value for the message JMSCorrelationID. This would then no longer match the JMSCorrelationID sent on the original request message.
> Related sections:
> 3.2.1.1 JMSMessageID And JMSCorrelationID Handling
> 3.2.1 JMS Headers (specifically the JMSMessageID and JMSCorrelationID entries)
> 3.3.2 Properties Section ( specifically the message-id and correlation-id entries)
> Section references from WD6: https://www.oasis-open.org/committees/document.php?document_id=56418&wg_abbrev=amqp-bindmap



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)