-
1. Re: async pain
estaub Jun 6, 2007 9:12 AM (in response to ax666)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
ax666 Jun 6, 2007 10:04 AM (in response to ax666)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
ax666 Jun 6, 2007 11:18 AM (in response to ax666)Ok, next one.
Looks like there's a problem with storing and signalling jobs. The last thing I see in the logs is16: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
estaub Jun 6, 2007 12:25 PM (in response to ax666)Alex,
That's not much to go on...
-Ed Staub -
5. Re: async pain
ax666 Jun 7, 2007 9:24 AM (in response to ax666)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
ax666 Jun 7, 2007 11:31 AM (in response to ax666)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
kukeltje Jun 7, 2007 12:30 PM (in response to ax666)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
estaub Jun 11, 2007 10:01 AM (in response to ax666)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
ax666 Jun 11, 2007 11:39 AM (in response to ax666)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
estaub Jun 19, 2007 8:47 AM (in response to ax666)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
ax666 Jun 20, 2007 7:37 AM (in response to ax666)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
kukeltje Jun 20, 2007 9:46 AM (in response to ax666)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
kukeltje Jun 20, 2007 9:48 AM (in response to ax666)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?