Bug 860851

Summary:	Deadlock while attempting to reconnect to the broker
Product:	Red Hat Enterprise MRG	Reporter:	Jason Dillaman <jdillama>
Component:	qpid-cpp	Assignee:	messaging-bugs <messaging-bugs>
Status:	CLOSED NOTABUG	QA Contact:	MRG Quality Engineering <mrgqe-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	Development	CC:	jross
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-26 21:32:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jason Dillaman 2012-09-26 21:07:23 UTC

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 21:32:38 UTC

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.