Created attachment 1078351 [details] broker trace log, while sending and receiving messages There is an error in JMS header fields in JMSTimestamp and JMSExpiration while obtaining (or rather browsing) AMQP 1.0 message using AMQP 0.10 client(s). For more information look at "Issues" below reproducing part. Broker trace logs are attached as well. A) Sending an AMQP 1.0 message service qpidd restart qpid-config add queue testq 1) aac/aac1_sender.java.sh --log-msgs dict --msg-ttl 100000 -a testq echo -e "\n\nAMQP 1.0 message sent to the broker\n\n" >> ~qpidd/qpidd.log {'redelivered': False, 'reply_to': None, 'id': 'dhcp-75-219.lab.eng.brq.redhat.com-41955-1443534515273-0:1:1:1-1', 'user_id':None, 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 100000, 'type': None, 'expiration': 1443534616315, 'timestamp': 1443534516315, 'destination': 'testq', 'properties': {'JMSXDeliveryCount': 1}, 'content': None} 2) ../cpp/qc2_drain --log-msgs dict "testq;{mode:browse}" echo -e "\n\nAMQP 0.10 cpp message received\n\n" >> ~qpidd/qpidd.log {'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': None, 'id': None, 'user_id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 9.878200e+01, 'size': None, 'properties': {}, 'content': None} 3) qpid/qc2_drain.java.sh --log-msgs dict --connection-options "{sasl_mechanisms: ANONYMOUS}" "testq;{mode:browse}" echo -e "\n\nAMQP 0.10 java message received\n\n" >> ~qpidd/qpidd.log {'redelivered': False, 'reply_to': None, 'subject': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'type': None, 'expiration': 0, 'timestamp': 0, 'properties': {}, 'content': } 4) aac/aac1_receiver.java.sh --log-msgs dict -a testq --recv-browse true echo -e "\n\nAMQP 1.0 java message received\n\n" >> ~qpidd/qpidd.log {'redelivered': False, 'reply_to': None, 'id': 'dhcp-75-219.lab.eng.brq.redhat.com-41955-1443534515273-0:1:1:1-1', 'user_id':None, 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 100000, 'type': None, 'expiration': 1443534616315, 'timestamp': 1443534516315, 'destination': 'testq', 'properties': {'JMSXDeliveryCount': 1}, 'content': None} 5) ../cpp/qc2_drain --log-msgs dict --connection-options "{protocol : 'amqp1.0'}" "testq;{mode:browse}" echo -e "\n\nAMQP 1.0 cpp message received\n\n" >> ~qpidd/qpidd.log {'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': None, 'id': 'dhcp-75-219.lab.eng.brq.redhat.com-41955-1443534515273-0:1:1:1-1', 'user_id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 9.368200e+01, 'size': None, 'properties': {'x-amqp-absolute-expiry-time': 1443534616315, 'x-amqp-creation-time': 1443534516315, 'x-amqp-first-acquirer': True, 'x-amqp-to': 'testq', 'x-opt-jms-dest': 0, 'x-opt-jms-msg-type': 0}, 'content': None} service qpidd stop ------------ amqp 0.10: 2,3 amqp 1.0: 4,5 Compare mainly (1 with 3 and 4) Issues: a)JMSMessageID - please confirm it is like this, so it is not an error: 2,3) ok if amqp0.10 should accept UUID only 4,5) ok if amqp 1.0 accepts also non-UUID strings JMSTimestamp b) timestamp is 0, should be 1443534516315 JMSExpiration c) expiration is 0, instead of 1443534616315 How reproducible: Always Version-Release number of selected component (if applicable): qpid-cpp-server-0.34-5.el6.x86_64 qpid-cpp-client-0.34-5.el6.x86_64 qpid-jms-client-0.5.0-2.el6.noarch qpid-java-client-0.30-7.el6.noarch Actual results: JMSTimestamp and JMSExpiration are both 0 for amqp 0.10 receiver of amqp 1.0 message. Expected results: JMSTimestamp and JMSExpiration are not 0 for amqp 0.10 receiver of amqp 1.0 message. Additional info: See attached broker trace log file. This could be also broker issue, but marking component as qpid-java.
This is a question of if/how qpidd should map between the creation-time and absolute-expiry-time in the properties section of an AMQP 1.0 message and the timestamp and expiration in the delivery-properties of an AMQP 0-10 message. Though quite similar in intent, the details of how these fields are specified means that in my view they are not exactly equivalent. Both the 0-10 fields are defined as being set by the broker that receives the message. For the expiration, it would be updated on every hop based on the specified ttl. By contrast in 1.0, both fields are to be set only by the original sender and should never be modified by any intermediary and the absolute-expiry-time is independent of ttl. For my part, I question whether trying to translate between these fields is necessary or even desirable.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.