Bug 860851 - Deadlock while attempting to reconnect to the broker
Deadlock while attempting to reconnect to the broker
Status: CLOSED NOTABUG
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Development
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: messaging-bugs
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-26 17:07 EDT by Jason Dillaman
Modified: 2012-09-26 17:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-26 17:32:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Dillaman 2012-09-26 17:07:23 EDT
Description of problem:
If reconnections are enabled within the Qpid C++ messaging API, it is possible to encounter a deadlock scenario when multiple threads attempt to recover the same disconnected connection.

Version-Release number of selected component (if applicable):
Qpid 0.18

How reproducible:
Frequently

Steps to Reproduce:
1. On the same connection create N sessions each with 1 receiver
2. Each receiver should execute nextReceiver on their session
3. Each receiver should reject any received messages
4. Send messages to the receivers and kill the broker connection
  
Actual results:
Thread A will own the lock to ConnectionImpl and will start the reconnection process -- when the connection succeeds, it will block attempting to lock each Session's lock.  Thread B (if within the reject or other session-level action) will own the lock to the Session and will be blocked waiting on the lock to the ConnectionImpl.

Expected results:
Thread A and B reconnect to the broker without deadlock
Comment 1 Jason Dillaman 2012-09-26 17:32:38 EDT
After further analysis, issue appears to be different than the original write-up.  I will open a new BZ with new details since the issue appears to be caused by a deadlock during client shutdown and not during runtime.

Note You need to log in before you can comment on or make changes to this bug.