4 Replies Latest reply: Mar 30, 2012 7:31 AM by Sylvain berthouzoz RSS

Infinite Loop (bug?) in JBPM integration

Elias Ross Master

I've been running some unit tests and get a StackOverflowError (infinite loop) of the following calls:




     at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:154)
     at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
     at org.jboss.seam.Component.unwrap(Component.java:2237)
     at org.jboss.seam.Component.getInstance(Component.java:2004)
     at org.jboss.seam.Component.getInstance(Component.java:1967)
     at org.jboss.seam.Component.getInstance(Component.java:1961)
     at org.jboss.seam.Component.getInstance(Component.java:1934)
     at org.jboss.seam.Component.getInstance(Component.java:1929)
     at org.jboss.seam.bpm.ProcessInstance.instance(ProcessInstance.java:65)
     at org.jboss.seam.contexts.BusinessProcessContext.getProcessInstance(BusinessProcessContext.java:229)
     at org.jboss.seam.contexts.BusinessProcessContext.getContextInstance(BusinessProcessContext.java:217)
     at org.jboss.seam.contexts.BusinessProcessContext.get(BusinessProcessContext.java:68)
     at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:209)
     at org.jboss.seam.Component.getInstance(Component.java:1949)
     at org.jboss.seam.Component.getInstance(Component.java:1944)
     at org.jboss.seam.Namespace.getComponentInstance(Namespace.java:55)
     at org.jboss.seam.Namespace.getComponentInstance(Namespace.java:50)
     at org.jboss.seam.el.SeamELResolver.resolveBase(SeamELResolver.java:166)
     at org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:53)
     at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
     at org.jboss.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
     at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
     at org.jboss.seam.core.Expressions$1.getValue(Expressions.java:112)
     at org.jboss.seam.transaction.EntityTransaction.initEntityManager(EntityTransaction.java:67)
     at org.jboss.seam.transaction.EntityTransaction.begin(EntityTransaction.java:79)
     at org.jboss.seam.util.Work.workInTransaction(Work.java:42)
     at org.jboss.seam.bpm.ProcessInstance.getProcessInstance(ProcessInstance.java:39)
     at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
     at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)



Here's how to reproduce the issue:


From a SeamTest. Invoke the following code directly:


         JbpmContext context = config.createJbpmContext();
         try {
             GraphSession graphSession = context.getGraphSession();
             ProcessInstance processInstance = graphSession.getProcessInstance(processDefinition, user.getNumber());
             Token token = processInstance.getRootToken();
             log.debug("before signal");
             token.signal();
             log.debug("after signal");
             context.save(processInstance);
         } finally {
             context.close();
         }




Within the signal method, have the transition call an EL expression, e.g.



     <decision name="check msg">
          <transition to="foo" name="foo">
               <action expression="#{user.send(messages['foo'])}"/>
          </transition>
     </decision>





Any help with this bug? Should I file a JIRA and maybe fix it myself ? :-)


This is Seam 2.2.1.GA.

  • 1. Re: Infinite Loop (bug?) in JBPM integration
    Elias Ross Master

    I think the bug is this:



    package org.jboss.seam.bpm;
    
    public class ProcessInstance 
    {
    
    ...
       public static org.jbpm.graph.exe.ProcessInstance instance()
       {
          if ( !Contexts.isConversationContextActive() || !BusinessProcess.instance().hasCurrentProcess() ) return null; //so we don't start a txn
          
          return (org.jbpm.graph.exe.ProcessInstance) Component.getInstance(/* WRONG TYPE */ ProcessInstance.class, ScopeType.STATELESS);
       }
    }
    



    Should probably be written as:


          return (org.jbpm.graph.exe.ProcessInstance) Component.getInstance(org.jbpm.graph.exe.ProcessInstance.class, ScopeType.STATELESS);




  • 2. Re: Infinite Loop (bug?) in JBPM integration
    Elias Ross Master
    Ignore this post ^^^ ... should have thought more before typing.

    The loop is basically doing this:

    org.jboss.seam.bpm.ProcessInstance.getProcessInstance() is attempting to get a reference to #{entityManager}. Now, the value expression evaluator sees that the business process scope is active, and tries to obtain a reference to ProcessInstance through org.jboss.seam.bpm.ProcessInstance.instance... which in turn calls getProcessInstsance and the cycle continues.

    So, something needs to prevent the business process scope from being active when this call is being made somehow.
  • 3. Re: Infinite Loop (bug?) in JBPM integration
    Sylvain berthouzoz Newbie

    Any news about this problem? Is it solved in seam 2.2.2.Final? If not, is there a workaround to avoid this problem?

     

    I'm having the same issue on an application using seam 2.1.1.GA, our new version of our application is using 2.2.2.Final, the problem occurs when the following timer is fired:

    <state name="wait for protocol receipt">

            <description>WAIT_PROTOCOL_RECEIPT</description>

            <timer name="timeout" duedate="#{directoryRepository.getProtocolTimeout(processInstance.key)}" transition="timed out">

                <action></action>

            </timer>

            <transition to="move to failed to transmit" name="timed out"></transition>

            <transition to="positive protocol receipt?" name="next"></transition>

        </state>

  • 4. Re: Infinite Loop (bug?) in JBPM integration
    Sylvain berthouzoz Newbie

    I test it with seam 2.2.2.Final and had the exact same behaviour, but I had the problem only on Tomcat (Tomcat 7.0.16), with JBoss 4.2.3 it works fine.