[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (AMQPBINDMAP-15) update handling of correlation ID for interop
[ https://issues.oasis-open.org/browse/AMQPBINDMAP-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Gemmell updated AMQPBINDMAP-15:
--------------------------------------
Summary: update handling of correlation ID for interop (was: Proper handling of correlation ID)
Description:
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
was:
Discussed during 22-Sep-2015 TC call. If a JMS application sets correlation ID, a non JMS receiving client reads it and sets as message ID then replies, original client won't understand the received message.
This JIRA should be used to discuss the options for handling the message id and correlation id.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]