[Design of JBoss jBPM] - Re: Failure handling
by kukeltje
anonymous wrote : Less importantly, recursive evaluation causes resources to be tied up unnecessarily. I've seen posts on this forum complaining about a "memory leak in JBPM" - they perform a process loop a zillion times and watch the heap grow without bound. This would be silly as a production scenario, but it's a very typical kind of test to run.
This is 'fixed' in the PVM (upcomming core of jbpm 4.0) Koen gave Tom some good spanking and in the meantime came up with a solution.
With regard to the discussion about exceptionhandlers or the 'failure transitions', this is a hot topic in all processlanguages. I tried this once in a small test example where the actionhandler on getting an exception, did not throw it, but set a variable (which is possible if no exceptionhandlers are used). Transitions can be 'guarded' by expressions/conditions so the presence of a value in a certain variable can make the process leave on a certain transition. This can be decided upon designtime. On this leaving node you can e.g. use a compensating action that undo's previous actions. Kind of complex though, but that is the case with all (afaik) 'languages' like bpel, ebbp, bpmn etc. Maybe Tom or Alex could comment on this as well.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069715#4069715
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069715
16 years, 9 months
[Design of JBoss jBPM] - Re: Failure handling
by estaub
...Sorry, I miskeyed and posted my last post prematurely.
Re recursive execution:
I can't really point at a specific "this test fails"... it's more that it's a likely source of bugs due to incorrect analysis, both for JBPM developers and JBPM users.
For example, an actionhandler might be incorrectly written:
acquireSomeResource()
| try
| {
| useTheResource();
| leaveNode();
| }
| finally
| {
| releaseSomeResource()
| }
|
Can you spot the bug?
The release is happening after all subsequent nodes that can be executed are executed. If any of them needed the same resource, they would be surprised to find that it was already in use. Billy Pilgrim would be at home ;-).
Less importantly, recursive evaluation causes resources to be tied up unnecessarily. I've seen posts on this forum complaining about a "memory leak in JBPM" - they perform a process loop a zillion times and watch the heap grow without bound. This would be silly as a production scenario, but it's a very typical kind of test to run.
The fix is to raise a flag in the token while a node's executionHandler is being performed, so that any internal leaveNode() or signal() calls know that they are being performed within this context. If an actionHandler performs a leaveNode or signal, the transition to take is recorded, but not actually taken until after the actionHandler exits.
-Ed Staub
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069653#4069653
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069653
16 years, 9 months
[Design of JBoss jBPM] - Re: Failure handling
by estaub
>> you wouldn't be able to do JBPM related actions is this isolated transaction
Correct, but I'm not sure it's a problem. The actionhandler calls a local EJB to perform the transactional behavior unrelated to JBPM. The return value from the local EJB is then used to perform whatever JBPM-specific behavior is necessary, on the JBPM transaction.
>> Kind of making things like Seam unusable.
I don't know enough about Seam to have an opinion.
--
Re recursive execution:
I can't really point at a specific "this test fails"... it's more that it's a likely source of bugs due to incorrect analysis, both for JBPM developers and JBPM users.
For example, an actionhandler might be incorrectly written:
acquireSomeResource()
try
{
useTheResource()
leaveNode();
}
finally
{
releaseSomeResource()
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069640#4069640
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069640
16 years, 9 months
[Design of JBoss jBPM] - Re: Failure handling
by bill.burke＠jboss.com
"estaub" wrote : Bill,
|
| In your original scenario, I'm picturing the rollback as originating in an actionhandler performing a non-JBPM-related action. For these cases, I'm dealing with the transactional difficulties by isolating them in their own transaction. Once this is done, exception handlers should be usable.
But, in this scenario, you wouldn't be able to do JBPM related actions is this isolated transaction, specifically the setting of variables, correct? Kind of making things like Seam unusable.
anonymous wrote :
| You should probably also be aware that JBPM uses recursive execution of the graph. I mean that, when a node actionhandler calls leaveNode() or, less properly, signal(), the downstream execution of subsequent nodes happens within that method call; the execution of later nodes happens within the execution scope of the first actionhandler. This can lead to surprising behavior in error conditions, at least for me. I have a fix for this, but I'm not sure that anyone else believes it's a problem!
|
| -Ed Staub
|
Ed, can you elaborate why this is a problem? I just want to learn something. IMO, this seems like an advantage. And, can't you just fix your issue with an asynchronous continuation?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069633#4069633
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069633
16 years, 9 months