Red Hat Bugzilla – Bug 557896
The ttl of messages is not adjusted when forwarding on to other brokers in a federation.
Last modified: 2010-10-14 12:00:51 EDT
It should be adjusted on each link to be the number of milliseconds left until expiration. That allows each broker in the change to honour the ttl even when clocks aren't fully synchronised.
Fixed in r.910289 QA: Should be easy to check by using the test with/without the fix. Without the fix, message BBB would have a ttl of 10 sec.
QA: Perhaps I should say that the above test is the new ClientSessionTest.testTtl that was added as part of the above checkin.
VERIFIED on RHEL 5.5 i386 / x86_64 # rpm -qa | grep qpid | sort -u python-qpid-0.7.946106-14.el5 qpid-cpp-client-0.7.946106-15.el5 qpid-cpp-client-devel-0.7.946106-15.el5 qpid-cpp-client-devel-docs-0.7.946106-15.el5 qpid-cpp-client-ssl-0.7.946106-15.el5 qpid-cpp-mrg-debuginfo-0.7.946106-15.el5 qpid-cpp-server-0.7.946106-15.el5 qpid-cpp-server-cluster-0.7.946106-15.el5 qpid-cpp-server-devel-0.7.946106-15.el5 qpid-cpp-server-ssl-0.7.946106-15.el5 qpid-cpp-server-store-0.7.946106-15.el5 qpid-cpp-server-xml-0.7.946106-15.el5 qpid-java-client-0.7.946106-9.el5 qpid-java-common-0.7.946106-9.el5 qpid-tools-0.7.946106-10.el5 --> VERIFIED
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: A message with a TTL set is delivered using this same value irrespective of how long the message waited at the broker. Consequence: The message may live longer than the TTL intended. Fix: On delivery, the TTL is set downwards by the amount of time the message spent on the broker. Result: The time spent on the broker is now accounted for when a message is delivered, and the TTL of the delivered message is adjusted down accordingly. This allows the receiver to handle the TTL correctly even if its own clock is not synchronised with that of the sender.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,7 +1 @@ -Cause: A message with a TTL set is delivered using this same value irrespective of how long the message waited at the broker. +When a message was delivered, the original time to live (TTL) value was preserved regardless of how long it was actually held by a broker. Because of this, it may have lived longer than originally intended. With this update, the TTL value is decreased by the amount of time the message spends on a broker, which allows a receiver to handle it correctly.- -Consequence: The message may live longer than the TTL intended. - -Fix: On delivery, the TTL is set downwards by the amount of time the message spent on the broker. - -Result: The time spent on the broker is now accounted for when a message is delivered, and the TTL of the delivered message is adjusted down accordingly. This allows the receiver to handle the TTL correctly even if its own clock is not synchronised with that of the sender.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0773.html