This could be because your tasks are not blocking... Or i miss understand your problem...
Look in this direction...
Task instances can be blocking, meaning that the related token (=path of execution) is not allowed to leave the task-node before the task instance is completed.
all of our tasks are signalling, so when they are completed process execution is continued. What is interesting here is that we are almost certain that the task has not been 'submitted', yet a subsequent task has also been created and is in the 'not started' state simultaneously.
Thanks for the pointer though.
Any other ideas ?
sorry, no, I have not seen any behaviour like this before.
clutching at straws here, could it be transaction related? I cannot remember if transactions are enabled by default?
A user will submit his or her task, and instead of just flowing to the next task, in sequence, several are then created and listed as not started.
Just for clarification, I take it that the several task instances that are created, are all from different nodes, at not all defined on the SAME node?
thanks for trying to help.
Examining process instance 787, there is one token listed against it : 920,
this in turn is linked to one node : 2863, (with a name_ of 'dm rejection reason').
This is indeed the node which the process image states is currently running.
The problem is, running a query on jbpm_taskinstances:
SELECT * FROM jbpm_taskinstance where procinst_=787 and end_ is null
lists two tasks both of which are not started:
'detailed brief recorded' (which _should_ be the current active task)
'dm rejection reason' (which the process thinks is the current active task, and should activate when 'detailed brief recorded' has finished depending on the transition)
Both of these point to token_=920. I am wondering how this can be, when token 920 only points to one node = 2863?
Hope that helps provide more information.
Incidentally, I have posted a reply to a previous topic you wrote on, I am having some issues trying to reverse this error in the process using some code you wrote.. wonder if you have any ideas, the topic is : t=129059, heading : 'is it possible to force the token jump from one node to another'.
Thanks in advance for your help, greatly appreciated.
if you signal a token instead of ending a task (and have that signal the token) you get unfinished tasks but tasks not related to a token anymore.... so unexpected behaviour (like you have now)
just my 0.01 eurocents
back again on this topic... unfortunately this is still a problem with our implementation, and before we roll this marvellous engine out to other projects, of course the boss is expecting me to solve this problem.
I imagine the problem is related to how we have implemented and integrated the JBPM platform into our own domain specific webapp.
I was hoping someone else had encountered this problem and could tel me something easy like its related to database interruption or transaction problems :-)
Has anyone else seen simultaneously active tasks out of their intended sequence ?
I hope to piece a little more info on this together early next week to tell a more detailed story.
Thanks for your help in advance.
Yes, like said kukeltje before, you must look about the properties of your tasks.
Signaling and Blocking properties are important in multiuser environments.
Let us know the details of your implementation.
I will try to piece together a concise report on some implementation details, to attach to a post on Monday,
thanks for your help,
Better yet, make a unit test with embedded processdefinition and needed actionhandlers (as embedded classes) that demonstrates the problem.
I have looked through the latest process to exhibit this problem, and examined the tasks in the eclipse properties panel.
The 'Signalling' checkbox is ticked, and the 'Blocking' checkbox is not ticked.
So Salaboy21's post may shed some light on this for me.
Can anyone confirm it is possible for tasks to get out of sequence without blocking checked ? Or is it possible to reproduce this behaviour with non blocking tasks ?
Thanks for your help,
reading the snippet again, which Salaboy21 posted in an earlier post, I must confess to having difficulty grasping the difference between signalling and blocking tasks...
Task instances can be signalling. A signalling task instance is a task instance that, when completed, can send a signal to its token to continue the process execution. Task instances can be blocking, meaning that the related token (=path of execution) is not allowed to leave the task-node before the task instance is completed. By default task instances are signalling and non-blocking.
It looks like both types of task halt execution until task completion... can anyone explain this with a simple real work example ?
Thanks very much for your help,
You are right,
It looks like both types of task halt execution until task completion
The diference is that a blocking task need that the tasks created inside this node must be ended to continue. This means that you can not signal a task node to continue the execution if one or more task are not ended.
In the other hand, if you mark a task as non blocking you can signal the task node to continue, no mather if there are or not tasks not ended.
Hope, it helps