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 Mon, 16 Jun 2014 15:38:18 GMT
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).

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

View raw message