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 Wed, 25 Jun 2014 19:36:32 GMT

Attached a reproducer for the lock order issue I was getting with 
helgrind; turned out to be a simple testcase in the end.

Also attached the helgrind output I get.

If you determine that this is a real issue, then let me know and I will 
create a JIRA.


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)
>> 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.
>> - 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.
> Andrew
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

View raw message