[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:comment-tabpanel&focusedCommentId=62955#comment-62955 ] John Fallows edited comment on AMQPBINDMAP-15 at 7/20/16 9:15 PM: ------------------------------------------------------------------ Thanks, Robbie - think I'm catching up bit by bit... :-) So, for maximum interoperability with JMS clients, should we recommend that ... #1. AMQP clients (non-JMS) do *not* send messages with self-generated correlation-id strings starting with "ID:AMQP_" ? #2. AMQP brokers do *not* generate messages with message-id strings starting with "ID:AMQP_" ? When #1 occurs, then the correlation-id may not round-trip unmodified through a JMS client, as it can trigger type conversion before being observed again by the AMQP client. However, this type conversion is actually correct if the correlation-id originated at a JMS client, but not when the AMQP client self-generates the correlation-id (or copies it from a message-id, see #2). When #2 occurs, then JMS clients using the JMSMessageID as a JMSCorrelationID may encode a different correlation-id value (due to type conversion) from other (non-JMS) AMQP clients that use the directly observed AMQP message-id as the correlation-id. This potentially causes correlation to fail at an AMQP client that is unaware of the JMS mapping of IDs for AMQP. Perhaps we might also consider a prefix of "ID:AMQP:" as the specialized ID format for the JMS mapping (instead of "ID:AMQP_" prefix). was (Author: john.fallows): Thanks, Robbie - think I'm catching up bit by bit... :-) So, for maximum interoperability with JMS clients, should we recommend that ... #1. AMQP clients (non-JMS) do *not* send messages with self-generated correlation-id strings starting with "ID:AMQP_" ? #2. AMQP brokers do *not* generate messages with message-id strings starting with "ID:AMQP_" ? When #1 occurs, then the correlation-id may not round-trip unmodified through a JMS client, as it can trigger type conversion before being observed again by the AMQP client. However, this type conversion is actually correct if the correlation-id originated at a JMS client, but not when the AMQP client self-generates the correlation-id (or copies it from a message-id, see #2). When #2 occurs, then JMS clients using the JMSMessageID as a correlation-id may encode a different value (due to type conversion) from AMQP clients using the directly observed AMQP message-id as the correlation-id, potentially causing correlation to fail at an AMQP client that is unaware of the JMS mapping of IDs for AMQP. Perhaps we might also consider a prefix of "ID:AMQP:" as the specialized ID format for the JMS mapping (instead of "ID:AMQP_" prefix). > 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]