qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: qpid::messaging API TTL problems
Date Tue, 17 Jun 2014 17:38:18 GMT
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


Mime
View raw message