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.
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?
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.
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?