Is jBPM 4.X workable in a production environment ?

[jedizippy]

Hi,

We made a decision to use jBPM 4.X for a production release at the end of January. After beginning development on 4.1 we soon ran into issues with not being able close the process engine session meaning we could not undeploy/redeploy or application. This was fixed in 4.2 but the 4.2 completely broke all of our processes which make basic use of subprocesses (JBPM-2683). In a vain hope of progressing we are working on a latest trunk from a few days ago which seems to fix the previous issues. However now yet again we have subprocess issues with timers and also upto task completions.

So I guess my question is given the unstability mentioned above is anyone really using jBPM 4.X in any kind of production environment. If so do you use subprocesses etc.

With release 4.3 scheduled for start of January we are in a position of having to make a decision to throw away all the time invested in this as we have a production release (high availability) at the end of January and the experience so far is indicating that we could be in serious trouble. It is to be expected that the current trunk has of course bugs and issues. But given that 4.1 and 4.2 also have serious issues then is it even sensible to be hoping that 4.3 might be stable and workable.Is January even a likely date for a release ?.

Or should we bite the bullet now and look for another workflow engine ?.

Would be grateful for any thoughts or experiences (especially in relation to subflows/timers etc).

Regards

Martinh

[jedizippy]

Incidentally the latest trunk fails to build the distribution as follows:-

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) org.jboss.bpm:gwt-console-server-integration:jar:1.3.0

[kukeltje]

What are the issues you have with subprocesses and timers? I cannot find a post about this anywhere. It's hard to help out if we do not know what the issue is.

[update]

I just noticed you responded to another post:

http://community.jboss.org/message/516749#516749

Still, do you have more info? An example? Unittest preferably...

[kukeltje]

I do not get this error. The module is downloaded and put in my local maven repo (~/.m2/repository/....)

[jedizippy]

Hi Ronald,

Basically we have a simple process that as the first step executes a <java> with the continue=async. After this step it calls a subprocess which then has a custom java callout (just prints System out for now) and sets a value in the process execution which is evaluated in a decision which then does a <state> which has a timeout which then goes back to the custom java class. The idea being when the custom java call returns a state of retriable error we increment a count and allow 3 retries before creating a manual error task which forces a user to signal the process then to either the retry or an abort state. But when the timer fires the process gets signalled but then a constraint violation is thrown.

I am travelling right now but I can send you the simple eclipse project. The problem is we need to make use of subprocesses due to the complexity of our processes (vfor example we want to have a common custom java component invoker which handles all of this retry and task creation) and we just pass in the name of the custom java class that we want to invoke. But as yet we cannot get the simple subprocess working.

Should I create a jira and post the project on there ?

I appreciate your efforts here !

Regards

Martin

[kukeltje]

Just attach the project to this topic (should work) If we really encounter an issue or in detail know what it is we can file a jira issue.  It might be that you use jBPM in a way that was not intended, so in that case it is not a bug, but might be a feature request.

Cheers,

Ronald

[jedizippy]

Hi Ronald,

I have attached the eclipse project files as requested. There are actually 2 issues in this simple project. In order to reproduce then simply run the 'CreateUsersAndGroupsTest' first which creates a user and group and assigns the user to the group.

Then run SimpleErrorHandlingTest. I have done all the process engine creation inside the class just to make sure there is nothing untoward caused byu the stuff happening in JbpmTestCase !.

All that happens is the process runs. Enters the subprocess (SimpleSubprocessA) which in turn calls CustomJavaA which just prints a message and is hard coded to return a status of 'error_retry' which should then take the process to a decision to see how many retries there has been. If < 3 then it enters the  'Wait for timeout' state until the timer fires (currently 1 min) and then it should go back around the loop. Unfortunately it fails with a constraint violation (ORA-00001: unique constraint (JBPM.SYS_C0010985) violated. The whole trace from here can be seen in the following file in the attached zip:-

SubprocessTimeout-ConstraintViolation-ErrorTrace.txt

This is the first issue. The second is easily reproduced by removing the timer and state from the transition in that subprocess so that it goes straight round the loop without waiting. In this case it goes around 3 times and then sends a task to the 'sebulaAdmin' group and waits there. You can now run the TaskTaker. When you run this you need to add 2 args to the command line as follows:-

sebulaAdmin end-abort

The idea being that the manual task can either be retried by passing end-rety when the task is taken. Or end-abort (this case) to exit the sub-process with an exit state. When the task is taken the diags show that the sub process does end with end-abort but it looks as if the expression in the parent process is still being executed (it does not recognise the end-abort state) so then the parent process falls over with a null pointer as it is looking for a transition named 'error_retry' which is the value in the 'resultA' variable that was set previously in the sub-process and of course there is no transition here it should be using the end-abort transition. You can see the output trace in the following file in the attached zip:-

SubprocessTakeTaskSignalEndAbort-ErrorTrace.txt

I would be grateful for your input here as  I am not sure how really to proceed. As stated before the idea we had was to create this 'Generic Error Handler' subprocess which handles all of this auto/manual retry processing and then pass it the name of the real java custom class we want invoked....and then this simply returns a status of 'success','error_retry', 'error-fatal;' or 'abort'. Hence making the modelling of our processes much simpler.

Maybe you would recommend a different approach ? I would be interested to hear what your opinion is on this.

Regards

Martin

[kukeltje]

Regarding the subprocess ending, I think you have to use the outcome-value on transitions (see docs) This is just guessing though, since I've not used subprocesses with different transitions. I always use it with one transition and a separate decision node, but that is a personal choice (and a habit I inherited from jBPM 3 where you had to do it like this)

Regarding the other issue, I have no clue yet... If I find the time the coming days, I'll keep you informed.

edit: The outcome-value is mentioned in the docs as an attribute, but does not show up in the examples in the docs... Now I'm confused as well. Best is to have a look in the jBPM JPDL testcase (in the test-db module, *not* in the jpdl module) to see how it is done there.

edit2: Might be that you either have to add the outcome-value attributes if the real subprocess end state is not equal to the transition name in the parent process, OR remove the outcome attribute if they do match. So only if you need a mapping, you need the outcome/outcome-value construct.

edit3: I've not seen examples/testcases with the outcome/outcome-value construct

[jedizippy]

Hi Ronald,

Thanks for your time !. I will look into that outcome/outcome-value then and see if I can get that to work. As you stated its not in the examples and I based this on the subflow examples ! Maybe one of the core guys knows how this is supposed to be done now in 4.x ? In the meantime I will try and figure out how to get it working. I will update here any more info once I know one way or the other !.

Regards

Martin

[jedizippy]

Hi Ronald,

I updated with the latest trunk and then checked the 'test-db' module but I cant find any references to outcome-value. The subprocess folder in the test cases is empty. There is one at 'org.jbpm.test.activity.subprocess' which has two tests in it but neither is useful in this context.

The only references i could find to 'outcome-value' was in the the src/main/docbook/en/modules/ch06-jpdl.xml docs and in the actual SubProcessBindings.java class and 4.3 xsd of course !!!!.

It seems the usage is not really documented anywhere !. I will look at the xsd and try to figure it out.

Regards

Martin

[kukeltje]

jedizippy wrote:

I updated with the latest trunk and then checked the 'test-db' module but I cant find any references to outcome-value. The subprocess folder in the test cases is empty. There is one at 'org.jbpm.test.activity.subprocess' which has two tests in it but neither is useful in this context.

That is what I meant. But.... the examples *do* have multiple outgoing transitons from what I see, so if those work, the only difference is the 'mapping' that could be done if the outcome (on the process node) and outcome-value (on transitions in the process node). If not, the end state names in the subproces and the names of transitions in the process node should match (which afaics is also the case in your example)

jedizippy wrote:

The only references i could find to 'outcome-value' was in the the src/main/docbook/en/modules/ch06-jpdl.xml docs and in the actual SubProcessBindings.java class and 4.3 xsd of course !!!!.

It seems the usage is not really documented anywhere !. I will look at the xsd and try to figure it out.

I'm at least sure, using just the outcome and not having outcome-values on transitions is wrong. The xsd will not show you much more since docs are partly generated from them.

[jedizippy]

Hi Ronald,

Ok you beat me to it there. I now got it working. Actually the 'outcome' was a left over from the first incarnation of the subprocess when the Custom java class was driving the next transition and end state. Now it was actually not needed and I was so deep looking at the timer issue I didnt see it !. So now I changed it to have multiple end conditions that are evaluated in the calling process using the transition name matching the end state name and it works just fine now.

In addition I rolled back to 4.2 and it seems that timers work fine there as well. We managed to get around the issue we had in 4.2 with the constraint violation by adding continue="async" on the the subprocess call and the custom java call which seemed to solve the problem (maybe only in the short term though). Time will tell. So for the time being we can continue down this road at least.

Thanks for your input !.

Regards

Martin

[kukeltje]

Great it works, but I'm still curious to the constraint issue since one other post has an issue with timers as well, but there it leads to deadlocks. (different db) so I want to make sure the cases are not realted in any way at a low level.

What I think happend in your case is that the outcome has a value, there is no outcome-value found with the same value and the default transition was choosen.

You may rate the responses in this forum you know ;-)

[jedizippy]

One thing I think is really needed is a test case which actually relates to a common real world use case as it seems this error handling model is something most people are trying to figure out (based on one of the recent posts on the topic this week also). A process that creates a subprocess and has timer and creates a task for example with a wait state would be simple to implement and include in the test suite and would probably catch most of these issues we are finding.

For example I have already run into the next one. We used to have the start of the main process go to a java class to just print a message so we could use continue="async" which at 4.0 was not available on the <start>. I now changed the start element to have this and removed the java state and it now falls over with a NullPointerException !. So for now we go back to the original method with a java state again. It seems like every time we try to use a feature we run into an issue and then try to work around it !.

But with an end of Jan production deployment coming up I dont have a good feeling of stability based on this issues !. Hopefully we can iron out the remaining ones.

I did try the outcome-value by the way. But it didnt work either. From the xsd the only wireGroupType I could think that would match was the simple string so I tried something along the lines of below but it still didnt work:-

<transition........>

    <outcome-value><string name="error-abort" value="error-abort"/>

</transition>

Thanks for the input.

Regards

Martin

[kukeltje]

jedizippy wrote:

For example I have already run into the next one. We used to have the start of the main process go to a java class to just print a message so we could use continue="async" which at 4.0 was not available on the <start>. I now changed the start element to have this and removed the java state and it now falls over with a NullPointerException !.

With just mentioning the 'it fails with a nullpointer' we cannot do much. Sorry. A small isolated testcase would help

jedizippy wrote:

I did try the outcome-value by the way. But it didnt work either. From the xsd the only wireGroupType I could think that would match was the simple string so I tried something along the lines of below but it still didnt work:-

<transition........>

    <outcome-value><string name="error-abort" value="error-abort"/>

</transition>

The outcome-value in the xsd is indeed strange. I'll make an issue about either fixing it, or as long as it is not supposed to work, remove it from the docs.

jedizippy wrote:

One thing I think is really needed is a test case which actually relates to a common real world use case as it seems this error handling model is something most people are trying to figure out (based on one of the recent posts on the topic this week also). A process that creates a subprocess and has timer and creates a task for example with a wait state would be simple to implement and include in the test suite and would probably catch most of these issues we are finding

Isn't this what you have now? And to me it looks fairly basic (what you have know), no strange things. So yes, maybe yours could be included as an example. Or do I miss something.

jedizippy wrote:

So for now we go back to the original method with a java state again. It seems like every time we try to use a feature we run into an issue and then try to work around it !.

Well, that, and without wanting to offend you or any other user, is something that irritates me. People 'invent' workarounds and when with a newer version their workaround do not work anymore they get annoyed. I've told many people before that the jBPM 4 code is very clean and causes of something not working can often be found very easily when running a testcase in debug mode in e.g. Eclipse. Fixing bugs is then not that hard instead of making a workaround of which you do not know the 'best before' date. Even if you can or dare not realy fix it, pointing out what is wrong where would already help a lot. Most likely, in the time I spent helping you, I could (I guess) have fixed the outcome-value thing, updated the docs and maybe even created an example/testcase.

Cheers,

Ronald