5 Replies Latest reply on Jan 9, 2009 4:10 AM by kukeltje

    Stack overflow on recursive patten.

    jemodurn

      I am trying to understand 9.10 section of the user guide.

      * Token.signal(Transition)
      * --> Node.leave(ExecutionContext,Transition)
      * --> Transition.take(ExecutionContext)
      * --> Node.enter(ExecutionContext)
      * --> Node.execute(ExecutionContext)

      If my process contains a loop like this:

      <process-definition name="emailLoop" >
       <start-state name="start">
       <transition to="CheckEmail" />
       </start-state>
      
       <node name="CheckEmail">
       <action class="CheckEmailAction" />
       <transition to="SendEmail" />
       </node>
      
       <node name="SendEmail">
       <action class="SendEmailAction" />
       <transition to="CheckEmail" />
       <transition to="finish" />
       </node>
      
       <end-state name="finish"/>
      </process-definition>


      By the time I loop a gazillion times, will the repeated call to ExecutionContext.leaveNode() cause stack overflow?? I can see a deep recursive execution tree.



        • 1. Re: Stack overflow on recursive patten.
          kukeltje

          Correct... this is not supported (since it was never intended to be used in this way without a waitstate). jBPM 4.0 will have no problem supporting this.

          • 2. Re: Stack overflow on recursive patten.
            jemodurn

            Thank you for your reply.

            Can I achieve my looping in the client code like this:

            First change my process to include a wait-state:

            <process-definition name="emailLoop" >
             <start-state name="start">
             <transition to="CheckEmail" />
             </start-state>
            
             <node name="CheckEmail">
             <action class="CheckEmailAction" />
             <transition to="SendEmail" />
             </node>
            
             <state name="SendEmail">
             <action class="SendEmailAction" />
             <transition to="CheckEmail" />
             <transition to="finish" />
             </state>
            
             <end-state name="finish"/>
            </process-definition>


            Then in my client code I will do my loop:
            ...
            while(processInstance.hasEnded() == false) {
             processInstance.signal("CheckEmail");
            }
            ...


            • 3. Re: Stack overflow on recursive patten.
              kukeltje

              you could, but I'd implemented in a totally different way.

              I'd use an imap listener (with a noop) on a mailbox and trigger the processinstances once the mail arrives... I HATE polling this way and it is NOT acceptable in the architecture of the company I work for in at all. Suppose you have 100 processinstances polling.... yuck....

              • 4. Re: Stack overflow on recursive patten.
                insanely.freak


                I have a workflow requirement where I need to keep asking users in a system for approval till it is approved by all of them.
                I decided to loop over two jbpm nodes first being decision node and then a task node.
                Here I get a StackOverFlow Exception when i load the taskinstance from db again and try to end it. I have searched across various forums, only solution ppl seems to suggest for this is to persist it.
                Currently I am persisting the task instance created and then I end the task by fetching it from database. After this flow is suppose to go to decision node and decide whether to go to task node or to end. but as soon as it reached decision node I get StackOverflow exception.
                Cud anyone explain where and how i need to persist.

                It will be very help full if somebody can share what approach/design did they have used to resolve this problem. Any input will be helpful and is appreciated.

                • 5. Re: Stack overflow on recursive patten.
                  kukeltje

                  tripple post... .certainly does not help getting people motivated to respond