topic Correct way to signal a receiveTask in Alfresco Archive

Correct way to signal a receiveTask

exp2345 — Tue, 19 Aug 2014 10:38:15 GMT

I am attempting to signal a receive task from a delegate Java thread started from a Service Task and have run into two issues with the implementation.I have already read the threads http://forums.activiti.org/content/error-while-signaling-activity-receive-task and http://forums.activiti.org/content/

Re: Correct way to signal a receiveTask

jbarrez — Tue, 19 Aug 2014 11:28:22 GMT

> I expect that registering an event listener on ACTIVITI_STARTED before leaving the Service Task will allow me to wait until the receive state > has started before starting the delegate thread. When I query for the Execution using the executionId from ActivitiEvent RuntimeService
> returns a null execution which prevents me from verifying that the correct task has started. Is this expected behaviour?

Yes - the event is fired but probably the transaction hasn't been committed to the database.

If the call is so fast, why make the call async? Doing the call synchronous would be logical here.
Anyway, in this case polling is probably easiest.

Re: Correct way to signal a receiveTask

exp2345 — Tue, 19 Aug 2014 11:42:24 GMT

Thanks for your reply. Many of the calls do take a long time, but I created this example to reproduce behaviour I observed then the calls happened to return immediately.

I'll go ahead with polling and look into patching signal() to throw something other than NullPointerException when the execution hasn't been committed yet.

Edit: According to the API it should return ActivitiObjectNotFoundException (http://activiti.org/javadocs/org/activiti/engine/RuntimeService.html#signal(java.lang.String))

Re: Correct way to signal a receiveTask

exp2345 — Wed, 20 Aug 2014 17:58:01 GMT

Is it expected behaviour for the thread that calls signal() to continue executing the process even if that thread is not part of the executor pool?

The documentation indicates that this is not the case:

"A process instance can have various wait states and this service contains various operations to 'signal' the instance that the external trigger is received and the process instance can be continued."

I'd expect the 'signal' to immediately return yielding control back to the external trigger instead of executing further commands within the external trigger's thread. Please find attached a log file demonstrating this behaviour using the class and bpmn above.

Re: Correct way to signal a receiveTask

exp2345 — Wed, 20 Aug 2014 18:00:14 GMT

Re: Correct way to signal a receiveTask

trademak — Thu, 21 Aug 2014 13:16:08 GMT

Yes this is expected behaviour. It will execute until the next wait state.
If this is not the desired behaviour you can add an asynchronous element in the process definition so the thread will only execute until this asynchronous element.

Best regards,