Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 900699 (JBPAPP6-925)

Summary: CLONE - Weld - Deadlock between Weld AbstractContext session/application contexts creationLock
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Marek Schmidt <maschmid>
Component: unspecifiedAssignee: Shelly McGowan <smcgowan>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.0.0CC: ales.justin, maschmid, rajesh.rajasekaran, sgilda, smcgowan, twells
Target Milestone: ---   
Target Release: EAP 6.0.1   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/JBPAPP6-925
Whiteboard: eap601candidate
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
JBoss AS 7.1.2.Final
Last Closed: 2012-10-19 00:12:51 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:
Attachments:
Description Flags
jstack.txt
none
WELD-1159.tar.gz
none
WELD-1159.war none

Description Marek Schmidt 2012-07-10 14:11:34 UTC
Affects: Release Notes
Steps to Reproduce: 1. deploy the attached WELD-1159.war
2. go to http://127.0.0.1:8080/WELD-1159/Welcome
3. open the "SThing" link in the background
4. open the "AThing" link immediately after 3. (<2000ms)
5. notice neither request returns as the threads are deadlocked
project_key: JBPAPP6

The following beans will cause a deadlock between Weld AbstractContext session and application contexts creationLock if two requests in the same session are run, where the first one injects "SThing" and the other request injects "AThing". 

The problem is that the first request locks the session scoped lock first and application scoped next, while the other request locks in the opposite order.

{code}
public class ApplicationToSessionProducer
{
   @Inject
   Instance<AScoped> ascoped;
   
   @Produces
   @SessionScoped
   public SThing getThing() {
      
      try
      {
         Thread.sleep(2000);
      }
      catch (InterruptedException e)
      {
         e.printStackTrace();
      }
      
      ascoped.get().foo();
      
      return new SThing();
   }
}
{code}

{code}
public class SessionToApplicationProducer
{
   @Inject
   Instance<SScoped> sscoped;
   
   @Produces
   @ApplicationScoped
   public AThing getThing() {
      
      sscoped.get().foo();
      
      return new AThing();
   }
}
{code}

where

{code}
@ApplicationScoped
public class AScoped
{
   public void foo() {}
}

@SessionScoped
public class SScoped implements Serializable
{
   public void foo() {}
}
{code}

Comment 1 Marek Schmidt 2012-07-10 14:11:35 UTC
Link: Added: This issue Cloned from WELD-1159


Comment 2 Marek Schmidt 2012-07-10 14:12:14 UTC
Security: Added: Public
Docs QE Status: Added: NEW


Comment 3 Rajesh Rajasekaran 2012-07-11 20:21:22 UTC
Labels: Added: eap601candidate


Comment 4 Rajesh Rajasekaran 2012-09-07 22:45:18 UTC
The upstream issue seem to be fixed. Assigning to Shelly to accordingly set the fix version and make sure the upstream fixes are pulled in.

Comment 6 Marek Schmidt 2012-09-24 07:43:42 UTC
Verified on EAP 6.0.1.ER2

Comment 7 sgilda 2012-10-04 13:45:17 UTC
Does this need a release note for EAP 6.0.1? 
If so, the issue needs to be re-opened and the release notes flags set (Affects Release Notes, Not Yet Documented).
If not, the issue needs to be re-opened and the release notes flag set to "Release notes not required".


Comment 8 Marek Schmidt 2012-10-04 14:18:23 UTC
Release Notes Docs Status: Added: Not Yet Documented
Affects: Added: Release Notes


Comment 9 Marek Schmidt 2012-10-04 14:20:49 UTC
reopening for RN

Comment 10 Marek Schmidt 2012-10-04 14:24:46 UTC
Release Notes Text: Added: A possible deadlock could occur between Weld AbstractContext session and application contexts creationLock if two requests in the same session are run and a bean instance is produced inside a different-scoped producer. 


Comment 11 Dana Mison 2012-10-17 22:31:57 UTC
reopening for release notes updates

Comment 12 Dana Mison 2012-10-17 22:34:03 UTC
Writer: Added: elogue


Comment 13 Dana Mison 2012-10-17 23:13:31 UTC
Writer: Removed: elogue Added: tomwells


Comment 14 Tom WELLS 2012-10-18 06:24:00 UTC
Release Notes Docs Status: Removed: Not Yet Documented Added: Needs More Info


Comment 15 Tom WELLS 2012-10-18 06:24:15 UTC
Hey Marek,

What was done to prevent the deadlock?

Comment 16 Marek Schmidt 2012-10-18 07:08:10 UTC
The core of the fix is this commit:
https://github.com/weld/core/commit/b5095b8e17718e0cb9b443cd2c1388aca460ba86

The per context creation lock in the AbstractContext has been replaced by a a more fine-grained per bean-id creation lock in the bean store.

Comment 17 Tom WELLS 2012-10-19 00:12:07 UTC
Release Notes Docs Status: Removed: Needs More Info Added: Documented as Resolved Issue
Release Notes Text: Removed: A possible deadlock could occur between Weld AbstractContext session and application contexts creationLock if two requests in the same session are run and a bean instance is produced inside a different-scoped producer.  Added: A possible deadlock could occur between the Weld AbstractContext session and an application context's creationLock if two requests in the same session were run, and a bean instance was produced inside a different-scoped producer. The per context creation lock in AbstractContext has been replaced by a more fine-grained per bean-id creation lock in the bean store. A deadlock will no longer occur.


Comment 18 Anne-Louise Tangring 2012-11-13 20:07:49 UTC
Release Notes Docs Status: Removed: Documented as Resolved Issue 
Writer: Removed: tomwells 
Release Notes Text: Removed: A possible deadlock could occur between the Weld AbstractContext session and an application context's creationLock if two requests in the same session were run, and a bean instance was produced inside a different-scoped producer. The per context creation lock in AbstractContext has been replaced by a more fine-grained per bean-id creation lock in the bean store. A deadlock will no longer occur. 
Docs QE Status: Removed: NEW