Hi,
I have a process that in phase one pretty much does nothing but I’ve found a problem with SignalEnd as follows.
Similar to bug/error report here
Basically - I had a (1) Terminate End event that I turn into a (2) End Signal event. Nothing else except assigning a code to the signal being thrown.
Save it and execute, in the first version (1) everything works fine and the process finishes correctly (though the TE event is not logged in the log). in the second version I get an error message as follows:
2014-08-04 19:56:13 org.bonitasoft.engine.execution.work.FailureHandlingBonitaWork
WARNING: THREAD_ID=133 | HOSTNAME=ComputerName | TENANT_ID=1 | The work [ExecuteFlowNodeWork: processInstanceId:64, flowNodeInstanceId: 333] failed. The failure will be handled.
2014-08-04 19:56:13 org.bonitasoft.engine.execution.work.FailureHandlingBonitaWork
WARNING: THREAD_ID=133 | HOSTNAME=ComputerName | TENANT_ID=1 | org.bonitasoft.engine.core.process.instance.api.exceptions.SActivityStateExecutionException : "PROCESS_DEFINITION_ID=5906563981635185748 | PROCESS_NAME=POLICY | PROCESS_VERSION=1.0 | PROCESS_INSTANCE_ID=64 | ROOT_PROCESS_INSTANCE_ID=64 | FLOW_NODE_DEFINITION_ID=-6355327042301948826 | FLOW_NODE_INSTANCE_ID=333 | FLOW_NODE_NAME=SignalEndPOLICY | unable to handle throw event SFlowNodeInstanceImpl [stateId=26, stateName=executing, previousStateId=0, reachedStateDate=0, lastUpdateDate=0, displayName=SignalEndPOLICY, displayDescription=Desc SignalEndPOLICY, tokenCount=0, loopCounter=-1, executedBy=0, deleted=false, stateExecuting=false, flownodeDefinitionId=-6355327042301948826]"
Why and what could be happening here?
many thanks and best regards
Seán
Thanks Yannick,
Bonitasoft gives me a solution that work :
I install Bonita BPM 6.3.3 with Java jdk 1.7.0_67 and now it works.
Marked as an answer…
Hi,
I opened an issue to report this, but nobody find why this happens.
If you find a solution, I am interested.
could you tell your version of Bonita BPM, OS, Java, etc. ?
Mine is 6.3.2 Studio on Windows 8.1 using Java 7.0.67
it is intermittent which is annoying as I can’t say when it happens.
regards
Seán
Hi,
Bonitasoft gives me a solution that work :
I install Bonita BPM 6.3.3 with Java jdk 1.7.0_67 and now it works.
JRE 1.7.0 won’t fix this, at least on Bonita 6.3.7. Also I don’t get this in a random manner, I get this everytime I hit a Throw Signal event.
Any ideas?
Make sure you’re using java 1.7.0.67 or above, it’s possible that anything lower may be the bug…only a thought.
I am running:
Java: 1.7.0_71-b14
jBoss: EAP 6.3
Bonita Studio: 6.3.7
Problem still reproducible.
This is a simplified version of my process:
![something][something]
[something]: http://i57.tinypic.com/biph7o.png
@TinyPic > http://tinypic.com/r/biph7o/8
09:51:19,101 WARN org.bonitasoft.engine.execution.work.FailureHandlingBonitaWork THREAD_ID=270 | HOSTNAME=dwonder04.knowledgeworks.pt | TENANT_ID=1 | The work [ExecuteFlowNodeWork: processInstanceId:30, flowNodeInstanceId: 565] failed. The failure will be handled.
09:51:19,123 WARN [org.bonitasoft.engine.execution.work.FailureHandlingBonitaWork] (Bonita-Worker-1-09) THREAD_ID=270 | HOSTNAME=dwonder04.knowledgeworks.pt | TENANT_ID=1 | org.bonitasoft.engine.core.process.instance.api.exceptions.SActivityStateExecutionException : “PROCESS_DEFINITION_ID=5327852080155624334 | PROCESS_NAME=work order vodafone gpe | PROCESS_VERSION=0.991 | PROCESS_INSTANCE_ID=30 | ROOT_PROCESS_INSTANCE_ID=30 | FLOW_NODE_DEFINITION_ID=-5182376059600065836 | FLOW_NODE_INSTANCE_ID=565 | FLOW_NODE_NAME=Envia Terminar 1.2 | unable to handle throw event SFlowNodeInstanceImpl [name=Envia Terminar 1.2, stateId=26, stateName=executing, previousStateId=0, reachedStateDate=0, lastUpdateDate=0, displayName=Envia Terminar 1.2, displayDescription=null, tokenCount=0, loopCounter=-1, executedBy=0, deleted=false, stateExecuting=false, flownodeDefinitionId=-5182376059600065836]”
That error is printed as soon as the process hits any of the “throw ‘endSignal’ signal” . I don’t really understand what I changed to break it because this was thoroughly tested and now the error seems to happen, I suspect, because either the task that catches the signal is on the same path than the signal thrower or the thrower can’t reference/find same path tasks that should catch the signal.
In the above diagram you are throwing an event, to be caught by a proceeding catch event on a step that has already finished…
I’m trying to understand the logic of it
Right, I think I have it…
You generate three process steps to be done by anyone of three people, if one of them does the job, then cancel the other steps. You don’t say if HTA, B and C are the same or if they are different. I will assume they are the same.
Yeah - this is not the right way.
Here I would generate ONE instance of HT and apply a Actor Filter to the three people who can do the job. This way you remove the need for any throw/catch events.
People in the Actor Filter will be notified there is a job to do and by taking it will remove it from the queue for others to do.
What happens if you need to add HTD or HTE? Will you rewrite the process, or would you prefer to simply add a user to the the Actor Filter via the organization? I think the latter would be much easier.
In the end, I think we rewrote the process to work the correct way rather than trying to use the signals in a way that in the end got a little confusing.
Hope this helps,
regards
Seán
All those HT’s are different in the sense that they have different business logic meanings and thus must respond to isolated stimuli but still coexist until one of them finishes and invalidates the other two which should not be accessible anymore from that point on (the stimuli is related to the current state of an outside, real-world, event). Actors on the other hand are not relevant here, it can be anyone with permission to execute this “task” but I don’t currently manage those permissions inside the process.
I understand the “(…) you are throwing an event, to be caught by a proceeding catch event on a step that has already finished…” statement, it seems very clear to me too that despite being possible to design it this way it could be a problem and the solution I found was exactly to avoid that from happening. I created different, task specific, signals that are conditionally thrown in accordance to the path of the throw event, which will throw only the remaining two signals, not the (now extinct) “global” signal that would be caught by all three tasks, including the already finished one.
Apart from the aforementioned implementation details (and even forgetting the fact that the designer should be able to identify this particular pitfall!) which I may agree could be optimized and done in a better, more easily maintainable way, what boggles my mind is the simple fact that the process has been like this for a long time and I just can’t understand how this only started manifesting now.
The only thing I can’t come up with is the fact that I needed to perform minor changes, not even remotely related to this subject, and had to build a new version to update the the server side. This could be a problem if the process had originally been build with a different Studio version but this is not the case, still using 6.3.7…
This is not something I was not expecting but I am really pissed right now!..
The aforementioned workaround is now, eventually (and until I figure out why also mysteriously!) rendered useless since the original behavior is back and I can no longer successfully throw a signal to be caught by a parallel human task catch signal… WHY!? Yes, once again this is happening after having performed some totally unrelated modifications and building the process again, in order to update it server side.
Coming from Bonita 5.7 , 6.3 was a big leap but the devil is in the details and right now I have, once again, lost hope on this engine, too buggy, if i had shed my money for the commercial version I would be slitting my wrists right now…
All I can suggest is add it to the Bug list…
One thing that might help in trying to isolate the issue is to change the logging to a finer detail.
I think it’s in \workspace\server_configuration\tomcat_conf
At least that’s where I’ve changed things in the past and got clearer results on what’s happening.
I’ve had things fixed on there, though I also have some - Not a Bug - and some are still waiting…
Sorry to hear you’ve got the problem again.
regards
Seán
[https://bonita.atlassian.net]
[https://bonita.atlassian.net]: https://bonita.atlassian.net
Simply changing the names of the thrown/caught signals restored the workaround behavior… sort of! Now the catch signals, which all lead to an end event as per my aforementioned simplified process design, are not aborting the human tasks, they are instead resuming them which casuses the parallel branches to resume execution when they should abort and never be executed! Am I wrong?
Despite whatever is happening with the end signals not aborting the tasks, should not the designer be able to warn the user in case a thrown signal is never caught? Or when a caught signal is never being thrown? Clearly this was a case where the GUI component was not inline with what was actually happening underneath because I am led to believe that if a simple signal name change fixed the problem then It could mean that after compiled the process was not recognizing either one of the thrown or one of the caught signals.
I believe something is very wrong with my process design, even though the designer is not detecting the pitfall…
PS: yes I have it in DEBUG mode already, but I don’t think it is necessary in my case.
