qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CLIVE <cl...@ckjltd.co.uk>
Subject qpid::messaging API TTL problems
Date Mon, 16 Jun 2014 12:20:22 GMT

A client has been having problems with TTL on their messages, 
specifically messages being delivered when they believe the TTL should 
have expired.  (They are using QPID 0.28 on CentOS 6.4).

I have tracked the problem(s) down and reproduced the potential issues 
in the attached BOOST unit testcases.

The first issue is to do with the qpid::messaging::Sender. If an 
application sends messages while the sender is not connected, they are 
stored in the senders outgoing queue (assuming flush mechanism hasn't 
been activated). When the sender finally gets reconnected (using the 
reconnect functionality on the qpid::messaging::Connection), the 
messages in the senders outgoing queue get flushed as part of the 
Session reset mechanism. But if the TTL on these messages is say 1 
second and the Sender has been disconnected for more than this period, 
the messages still get sent and delivered to the associated set of 
receivers. No adjustment in TTL gets made by the Sender Implementation. 
Therefore messages that should have expired still get delivered.

The second issue is to do with the qpid::messaging::Receiver. If a 
sender and receiver are both created with an address string of 
"amq.topic/fred" and the receiver is configured with a capacity of 10. 
Then if the sender sends 100 messages with a TTL of 1 second, but the 
associated receiver is not serviced by the application for 2 seconds, 
when the receiver is serviced (using get/fetch) then 10 messages are 
still delivered to the application. In fact the number of messages 
delivered to the application, under this kind of scenerio, matches the 
capacity setting of the receiver. It would appear that even though the 
Broker is expiring messages from the queue (using qpid-tool I can see 90 
messages have been expired from the queue), it does not manage to do 
this for messages that have already been cached by the receiver due to 
its capacity setting.

What are peoples thoughts on this behavior?

Any help/comments would be gratefully received.

View raw message