Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-9391

Deadlock between SynchronizationInterceptor lock and Component.getInstanceFromFactory factoryLock

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: EAP_EWP 5.1.2
    • Fix Version/s: TBD EAP 5
    • Component/s: Seam2
    • Labels:
      None
    • Environment:

      EAP 5.1.2

    • Steps to Reproduce:
      Hide

      1. deploy the attached seam-registration.ear
      2. run the attached "test.py" in Python2

      Show
      1. deploy the attached seam-registration.ear 2. run the attached "test.py" in Python2
    • Release Notes Text:
      Hide
      In previous versions of JBoss EAP 5, a deadlock between SynchronizationInterceptor lock and Component.getInstanceFromFactory could be encounetered.

      This was becuase Seam often used factory lock when a Factory method was used.

      In this release of the product, the occurances of this behaviour has been reduced to prevent the deadlock occurring if a Factory method was called in more than one thread for the same Seam component.
      Show
      In previous versions of JBoss EAP 5, a deadlock between SynchronizationInterceptor lock and Component.getInstanceFromFactory could be encounetered. This was becuase Seam often used factory lock when a Factory method was used. In this release of the product, the occurances of this behaviour has been reduced to prevent the deadlock occurring if a Factory method was called in more than one thread for the same Seam component.
    • Release Notes Docs Status:
      Documented as Resolved Issue
    • Docs QE Status:
      NEW

      Description

      The following sample demonstrates a deadlock between the SynchronizationInterceptor lock and the Component.getInstanceFromFactory factoryLock:

      @Stateful
      @Scope(ScopeType.SESSION)
      @Name("test")
      public class TestAction implements Test
      {
         
         public String test()  {        
            Thread.sleep(500);
            Component.getInstance("foo", true);    
            return "test";
         }
         
         @Factory(value="testString", scope=ScopeType.EVENT)
         public String getTestString() {      
            return "testString";
         }
      
         @Remove
         public void remove() {}
      }
      
      @Name("testProducer")
      public class TestProducer {
         @Factory(scope=ScopeType.EVENT)
         public String getFoo() {
            return "foo";
         }
      }
      

      when test.xhtml contains:

      <h:outputText value="#{test.test()} " />
      

      and othertest.xhtml contains:

      <h:outputText value="#{testString} " />
      

      If the othertest.seam is requested just after (<500ms after) the test.seam with the same session cookie.

      The problem seems to be that the #

      {test.test()}

      first locks the TestAction SynchronizationInterceptor lock and then the Seam factoryLock in the Component.getInstance call, while #

      {testString}

      locks the factoryLock first.

        Gliffy Diagrams

          Attachments

          1. jboss-seam-registration.ear
            1.92 MB
          2. JBPAPP-9391-regression.tar.gz
            3 kB
          3. jstack.txt
            70 kB
          4. test.py
            2 kB

            Issue Links

              Activity

                People

                • Assignee:
                  manaRH Marek Novotny
                  Reporter:
                  maschmid Marek Schmidt
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: