Bug 1268878 - [Selectors] JMSMessageID interoperability issue between AMQP 1.0 and 0.10 protocol [NEEDINFO]
[Selectors] JMSMessageID interoperability issue between AMQP 1.0 and 0.10 pro...
Status: NEW
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
3.2
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: messaging-bugs
Messaging QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-05 09:55 EDT by Michal Toth
Modified: 2018-03-06 15:41 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Customers should be aware that when sending a message using `qpid-jms-client` to MRGM broker and receiving this message with any client using AMQP 0-10, the `JMSMessageID` is null upon receipt. This is because in AMQP 0-10 the `message-id` must be a __UUID__ (as is the `correlation-id`). In AMQP 1.0 it can be a __string__, a __long__ or a __UUID__. When converting from a 1.0 message to a 0-10 message, the broker can not map the ID unless it is specified as a __UUID__. Therefore, if the message is being received using AMQP 0-10, this is expected and cannot be fixed. There is no workaround for this issue.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
gsim: needinfo? (rrajasek)


Attachments (Terms of Use)

  None (edit)
Description Michal Toth 2015-10-05 09:55:25 EDT
When sending a message using qpid-jms-client to MRGM broker and receiving this message with any but qpid-jms-client,
the message id is not propagated.
On the other hand, when receiving the very same message using qpid-jms-client the correct message id is there.

Steps to reproduce:
"
1) Send a message with qpid-jms-client to the broker and note the message id
/var/dtests/node_data/clients/java/aac/aac1_sender.java.sh --log-msgs dict -a "myqueue1"
{'redelivered': False, 'reply_to': None, 'id': 'dhcp-75-171.lab.eng.brq.redhat.com-49424-1443102234716-0:1:1:1-1', 'user_id':None, 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 0, 'type': None, 'expiration': 0, 'timestamp': 1443102235653, 'destination': 'myqueue1', 'properties': {'JMSXDeliveryCount': 1}, 'content': None}


2) Receive the message (use browsing mode) with qpid-jms-client
/var/dtests/node_data/clients/java/aac/aac1_receiver.java.sh --log-msgs dict --recv-browse true -a "myqueue1"
{'redelivered': False, 'reply_to': None, 'id': 'dhcp-75-171.lab.eng.brq.redhat.com-49424-1443102234716-0:1:1:1-1', 'correlation_id': None, 'priority': 4, 'durable': True, 'type': None, 'expiration': 0, 'timestamp': 1443102235653, 'properties': {'JMSXDeliveryCount': 1}, 'content': }

3) Receive the message (using browse mode) with non qpid-jms-client. Message id is not there.
/var/dtests/node_data/clients/java/qpid/qc2_drain.java.sh -b localhost:5672 --log-msgs dict --connection-options "{sasl_mechanisms:ANONYMOUS }" "myqueue1;{mode:browse}" 
{'redelivered': False, 'reply_to': None, 'subject': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'type': None, 'expiration': 0, 'timestamp': 0, 'properties': {}, 'content': }

/var/dtests/node_data/clients/qc2_drain --log-msgs dict "myqueue1;{mode:browse}" 
{'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': None, 'id': None, 'user_id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 0.000000e+00, 'size': None, 'properties': {}, 'content': None}
"
Replies from Gordon (and Robbie):
"Can you attach a broker protocol trace? The property is clearly not 'lost' as the JMS client is able to see it. The broker doesn't actually alter the bare message at all, so my initial suspicion is that it is a client side or interop issue.

I'd also suggest this may be worth creating a separate BZ for, as it seems quite distinct from the question of selectors."
----
Robbie suggests that the other clients may be using AMQP 0-10? If that was the case then it is expected that the message id would be null, as this is constrained to be a UUID in 0-10 and a random string can't be converted into a uuid, so the conversion to an 0-10 message would just drop that property.
"

Version-Release number of selected component (if applicable):
qpid-cpp-server-0.34-5
qpid-jms-client-0.5.0-2

Component:
qpid-cpp-server or qpid-jms-client

How reproducible:
Always

Actual results:
JMSMessageID is null

Expected results:
JMSMessageID should not be null. ID should be same (similar?) to sent.

Additional info:
If we decide not to test this, could we at least change component to MPR or MICG documentation bz?
Comment 1 Gordon Sim 2015-10-05 10:50:33 EDT
In AMQP 0-10 the message-id must be a UUID (as is the correlation-id). In AMQP 1.0 it can be a string, a long or a UUID. When converting from a 1.0 message to a 0-10 message, the broker can't map the id unless it is specified as a UUID. So if (3) above *is* using 0-10, this is expected and cannot be fixed.

Note You need to log in before you can comment on or make changes to this bug.