1 2 3 Previous Next 37 Replies Latest reply on Jul 3, 2007 3:53 AM by Gennadi Bereschneu

    async pain

    Alexander Schlett Newbie

      I'm really about to throw it. I have a node with two timers, one to perform a check every x seconds and make a transition if a condition is met, and one to make a cancel transition after a certain timeout time. now if it happens that timer1 is checking for the condition and timer2 decides its time for timeout, of course there's a concurrency problem because both try to work with the same token! It's two different threads and the token is locked by the first timer and it's action, so the second timer (timeout) fails because the token is still locked.

      to me that's a bug, but maybe I'm missing something? I wish jbpm would simply support async concurrent node execution...

        • 1. Re: async pain
          Edward Staub Expert

          Alex,

          Maybe in Timer.Timer(token) and Timer.Timer() you could try calling setExclusive().

          Once again, both thanks and condolences for being a pioneer in this area!

          -Ed Staub

          • 2. Re: async pain
            Alexander Schlett Newbie

            I reworked my processes and avoid timers now at all. The waiting and timing out is done in the ActionHandlers now. Let's see what the next problem is.

            The jBPM guys should write a simple process definition to test with, just async join/fork with nodes using timers, all with multiple JobExecutor threads. Lots of problems, guaranteed!

            • 3. Re: async pain
              Alexander Schlett Newbie

              Ok, next one.
              Looks like there's a problem with storing and signalling jobs. The last thing I see in the logs is

              16:26:55,267 JbpmJobExector:192.168.x.x:2 DEBUG DbMessageService - messages were produced the jobExecutor will be signalled
              


              after that no more jobs are executed though there should be stuff to do. This is frustrating.

              • 4. Re: async pain
                Edward Staub Expert

                Alex,

                That's not much to go on...

                -Ed Staub

                • 5. Re: async pain
                  Alexander Schlett Newbie

                  I can't provide anything useful to go on with, in every run something different doesn't work. Sometimes a subprocess is not executed any more, sometimes variables are lost or an action handler's executionContext doesn't have a contextInstance (executionContext.getContextInstance() returns null).
                  It's just something goes terribly wrong, and its hard to tell what. I don't have the time to dig further in this. I guess we will leave it to single threaded execution for now and look for some other product to use. Our project has to be finished soon...
                  I might do some test case and open a jira issue...
                  alex

                  • 6. Re: async pain
                    Alexander Schlett Newbie

                    Could someone please confirm that this simple process doesn't work with more than 1 JobExecutor thread configured?

                    <?xml version="1.0" encoding="UTF-8"?>
                    <process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="simpletest">
                     <start-state name="start-state1">
                     <description>start of the process</description>
                     <event type="node-enter">
                     <script name="script_start">
                     System.out.println("START");
                     executionContext.leaveNode();
                     </script>
                     </event>
                     <transition name="start-to-check" to="fileCheck" />
                     </start-state>
                    
                     <node name="fileCheck" async="true">
                     <script name="script_filecheck">
                     System.out.println("FILE-CHECK");
                     executionContext.leaveNode();
                     </script>
                     <transition name="check-to-fork" to="fork1"></transition>
                     </node>
                    
                     <fork name="fork1" async="true">
                     <transition name="toNode1" to="node1"></transition>
                     <transition name="toNode2" to="node2"></transition>
                     </fork>
                    
                     <node name="node1" async="true">
                     <script name="script_node1">
                     System.out.println("NODE1");
                     executionContext.leaveNode();
                     </script>
                     <transition name="node1toJoin1" to="join1"></transition>
                     </node>
                    
                     <node name="node2" async="true">
                     <script name="script_node2">
                     System.out.println("NODE2");
                     executionContext.leaveNode();
                     </script>
                     <transition name="node2toJoin1" to="join1"></transition>
                     </node>
                    
                     <join name="join1" async="true">
                     <transition name="joinToEnd" to="end-state-success"></transition>
                     </join>
                    
                     <end-state name="end-state-success">
                     <description>process finished normally</description>
                     <event type="node-enter">
                     <script name="script_endSuccess">
                     System.out.println("END-SUCCESS");
                     </script>
                     </event>
                     </end-state>
                    </process-definition>
                    


                    thanks,
                    alex

                    • 7. Re: async pain
                      Ronald van Kuijk Master

                      executionContext.leaveNode(); in a startnode on an event? Does that work correctly?

                      and the same in async nodes? hmmmmm... looks a bit strange to me.... What if you use java classes for leaving these nodes. Same errors then?

                      • 9. Re: async pain
                        Edward Staub Expert

                        Alex,

                        I took a quick look at the unit test. It uses a JbpmContextCallback class that I don't recognize, or see an import for. Do you need to attach it?

                        I didn't look rigorously for other missing bits; you might want to.

                        -Ed Staub

                        • 10. Re: async pain
                          Alexander Schlett Newbie

                          ed, thanks for pointing htat out, I added the missing interface, the unit test should not depend on anything now... alex

                          • 11. Re: async pain
                            Edward Staub Expert

                            Alex,

                            Apart from Ronald's request for scriptlessness, it doesn't look like anyone's dug into your http://jira.jboss.com/jira/browse/JBPM-983. Do you still need a fix? If so, I'll try to go after it in the next few days.

                            -Ed Staub

                            • 12. Re: async pain
                              Alexander Schlett Newbie

                              I fulfilled Ronalds request and added a version of the test case that uses an action handler. Our project state is, that jBPM allows only single thread execution which isn't something we can live with, but I don't have the time to investigate further. And yes, this should be fixed, right now I'm waiting for any reaction on this. Thanks for your efforts Ed!
                              Alex

                              • 13. Re: async pain
                                Ronald van Kuijk Master

                                The reason I asked for a scriptless version is that I'm not the scripted version can run async very wel.. I assume the non-scripted version shows the same (for you unwanted) behaviour?

                                • 14. Re: async pain
                                  Ronald van Kuijk Master

                                  Now I come to think of it.... I/we overlooked something.

                                  AFAIR, the async mechanism in the WAR version of jBPM was for simple environments. For enterprise grade solutions, a switch should be made to JMS. More than one MDB can be deployed there which can process the async actions. (not scripted ones)

                                  Alex, do you use JMS or not? Is it an option?

                                  1 2 3 Previous Next