qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: qpid::messaging API TTL problems
Date Tue, 24 Jun 2014 10:42:47 GMT
On 06/16/2014 04:38 PM, Gordon Sim wrote:
> On 06/16/2014 01:20 PM, CLIVE wrote:
>> Hi,
>> 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.
> That would be nice to fix.
>> 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.
> By default a receiver on amq.topic/fred will be using unacknowledged
> transfer. Therefore if the message has been sent to the client, the
> broker has already deleted its record.
> I.e. the issue is that the receiver does not itself do any expiration of
> messages from the prefetch buffer.
>> What are peoples thoughts on this behavior?
> I think both issues can clearly be considered bugs. If you raise a JIRA
> I can take a look at what a fix might involve (unless you have already
> done so).

Fyi: I have checked in fixes for both of these issues (currently only on 
the 0-10 codepath, but fixes on 1.0 to follow shortly).

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message