qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CLIVE <cl...@ckjltd.co.uk>
Subject Re: qpid::messaging API TTL problems
Date Mon, 16 Jun 2014 17:19:31 GMT
Already created QPID-5828 to cover these issues (plus some others). I 
have also attached several boost unit tests that help demonstrate the 
problems.

I have a few more issues to report with the messaging API, but I have 
run out of time to get them detailed with boost unit tests today, I will 
try and add them in the next few days. But in summary the outstanding 
issues are:

- valgrind with helgrind tool reports out of order locking problems 
between Session and Sender locks (may cause deadlock)

- valgrind with helgrind tool reports race condition with bool 
writePending variable in .qpid/sys/posix/AsynchIO.cpp. Variable defined 
as volatile, not sure this is actually enough to avoid data race 
conditions, as volatile keyword provides no guarantees on concurrent access.

- Session::checkError can throw exceptions that extend from 
qpid::Exception, not sure how to catch these as cannot find this 
exception in installation directory.

- Once a sender has transitioned in to a flush state (capacity/4 > 
outgoing queue size) and a connection does not exist to the broker, 
messages sent will not be placed in the outgoing queue.

Should I add these additional issues to QPID-5828, and attach new test 
cases as and when I can?


On 16/06/2014 16:38, 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).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
> .
>


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


Mime
View raw message