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 Tue, 17 Jun 2014 21:14:18 GMT
On 17/06/2014 18:38, Andrew Stitcher wrote:
> On Mon, 2014-06-16 at 18:19 +0100, CLIVE wrote:
>> Already created QPID-5828 to cover these issues (plus some others). I
>> have also attached several boost unit tests that help demonstrate the
>> problems.
> Do you have some way to produce unit tests for the lock issues? (I'm
> assuming not, but if so I'd be very interested to hear how you do this)
Yes, I have a unit test at work that was causing a dead lock situation, 
the use of valgrind's helgrind tool. I will try and create a JIRA with 
an attached
unit test and valgrind report.
>> 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)
> This seems like a potential deadlock that we should look at carefully.
>> - 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.
> This is known, and I assess it as benign - in that it is racy, but it
> doesn't matter semantically.

O.K. If you have time could you expand on your reasoning for this. I 
have in the past
always put locks around boolean flags, so I would be interested to learn 
from your
experience as to what semantic conditions can occur that do not require 
a flag
to have a lock.
>> - 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?
> In general I would open new issues for each separate problem you find.
> Doing anything else makes it hard to work on the issues in isolation,
> and if the problems have the same underlying fix or are the same
> underlying problem we can link the issues together later.
> You certainly don't need to wait until you can produce a neat reproducer
> before creating an issue. Of course it is much easier to work on an
> issue with a neat reproducer though.
I will create some more JIRA's in the next couple of days, but will not 
do so until
I have reproducer test cases for each of the potential problems. The 
issues uncovered
so far have come from my boost unit tests at a client site, so I already 
have the test cases,
its just a case reproducing them back at my offices and posting accordingly.

> Andrew
> ---------------------------------------------------------------------
> 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

View raw message