6 Replies Latest reply on Jul 11, 2012 7:53 PM by bradleydouglas

    Stateful session bean method invocations serializied on common lock

    bradleydouglas

      Hi all,

       

      I'm seeing odd locking behavior in JBoss AS 6.1 I'm hoping someone can give some insight into - and how to fix/work around it.

       

      We've got a Seam app and have a problem with a stateful session bean that is backing some EL on a JSF page.   Under load / stress testing using jmeter wirth 50 http sessions and I'm noticed we're not getting any concurrency in JBoss and guessed that something was serializing the calls across the JVM.

       

      I've done some digging and attached a full thread dump.  Looking at it you'll see 47 out of 50 of http-0.0.0.0-8080-XX threads waiting for the same lock (0x23471e11).  This lock appears to be a system wide lock on the stateful bean rather than a session scoped lock.

       

      Here is the definition of the stateful bean:

       

      @SuppressWarnings("unchecked")
      @Stateful
      @Name("documentGenerationBean")
      @Scope(ScopeType.CONVERSATION)
      public class DocumentGenerationActionBean extends MaintenanceActionBean implements DocumentGenerationAction {
          .....
      }
      

       

      Any help is greatly appreciated - even ideas about where to look for more info.

       

      Thanks,

      Brad

        • 1. Re: Stateful session bean method invocations serializied on common lock
          jaikiran
          • 2. Re: Stateful session bean method invocations serializied on common lock
            bradleydouglas

            Yep that looks like it.

             

            How did that ever get through two GA versions?

             

            So is there no plan to fix this in 6.x?  No patch?

            • 3. Re: Stateful session bean method invocations serializied on common lock
              jaikiran

              There's no more development for AS6 so no one (== me) has investigated the root cause of that issue. The reporter in that JIRA mentioned that it's been fixed in AS7 which is a good sign. With AS7 now fully certified we no longer recommend AS6 to users. Is it an option for you to move to AS7?

              • 4. Re: Stateful session bean method invocations serializied on common lock
                bradleydouglas

                The story is that we ran into a memory leak in 4.2.3 and were looking for the minium churn to get a fix for it.  The fix we were told was to upgrade to 5.X.

                 

                So we upgraded to 5.X and then ran into another show stopper bug (can't remember exact details now).  The solution was to upgrade to 6.X (7 wasn't out then).

                 

                So now we've hit another show stopper in 6.X and the "solution" is to upgrade to 7.  So convincing management that another migration exercise will fix the problem, and more imortantly not introduce more, will be almost imossible.

                • 5. Re: Stateful session bean method invocations serializied on common lock
                  jaikiran

                  You probably would have benefitted if you had become a EAP customer. Unlike the community versions, in EAP versions you would be entitled to patches and fixes for issues like these. For this specific issue however, that isn't applicable since AS6 never had a EAP version. AS7 has EAP6 though, if at all you decide to switch to it later on. This will give you an idea of why EAP is better is cases like these http://www.jboss.com/products/community-enterprise/.

                   

                  As for this specific issue, if anyone from the community wants to investigate and provide a fix then I can help review it and maybe even commit it at the right place. I would have done the investigation myself, but right now I'm already busy with too many other tasks.

                  • 6. Re: Stateful session bean method invocations serializied on common lock
                    bradleydouglas

                    Becoming an EAP customer is something we looked at when we hit the memory issue in 4.2.3, but it'scrazy expensive.  It' not reasonable to suggest that a start up etc. could fork out that sort of money.  The Redhat open source management where all the energy in "community" editions is on the bleeding edge that are flakey and where if you hit a problem the only "solution" is to upgrade to a new version (along with all it's new bugs) seems a little like a bait and switch.  All sorts of claims are made about how good JBoss etc is but if you actually try to use it you need the supported EAP version.

                     

                    And before people object too loudly, I'd add that we use alot of open source software: eclipse, MySQL, many apache tools, and others.  JBoss projects (AS, Seam and Richfaces) are the only projects that burn us in this way.

                     

                    Anyway back to this actual problem, I'll take a look at it if you can give me a leg up with where to start.  It looks to me like a problem with PerInstanceInterceptor or ContainerManagedConcurrencyInterceptor.. but I could be worng.  Where can I get the source for these (jboss aop and ejb3) at the revision they were in 6.1?