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