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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
