Bug 1811066

Summary: [GSS](6.4.z) WELD-2612 - Possible deadlock in conversation map cleanup
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Brad Maxwell <bmaxwell>
Component: CDI/WeldAssignee: Romain Pelisse <rpelisse>
Status: VERIFIED --- QA Contact: Matej Novotny <manovotn>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4.22CC: jharting, maschmid, pmackay, rpelisse, sdouglas
Target Milestone: ---   
Target Release: EAP 6.4.23   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1811067 (view as bug list) Environment:
Last Closed: 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:
Bug Depends On:    
Bug Blocks: 1699388, 1811067, 1816629    

Description Brad Maxwell 2020-03-06 14:28:36 UTC 
There was an issue with Weld 1 possibly causing a deadlock on WFLY when one thread attempts to replicate a session a another thread does the conversation context cleanup since both need a lock on a session (via getAttribute() and on a session parameter (map of all conversations over which we synchronize).

I am not sure this issue exists on newer versions of Weld (2/3) - a lot has changed in regards to underlying structure; undertow wasn't used before, session replication options changed. Weld has very similar code in these bits throughout all its versions though.

This is known to affect Weld 1.1.34.Final on WFLY for sure.
We should apply a fix to Weld branches that doesn't require us to obtain two locks to clear up conversations. Draft of that is available on my branch - https://github.com/manovotn/core/tree/convRaceConditionFix_master
Comment 4 Peter Mackay 2020-06-30 12:43:17 UTC 
Verified with EAP 6.4.23.CP.CR2