cancel
Showing results for 
Search instead for 
Did you mean: 

Recommended approach for long running tasks

lofi
Champ in-the-making
Champ in-the-making
What is the recommended approach to run a long running task? Currently I'm using a java service task which starts the external processes via ProcessBuilder. In extreme cases these processes can run for hours and days.

From what I found on this forum regarding the same question it may be that some activiti connections remain open which will cause a timeout. In order to prevent this, the task is flagged with async=true. However that means that the task is flagged as "finished" and activiti continues the workflow while the process is actually still running, but it should wait until the external process is finished.

Is there a mechanism to run long running tasks without system resources being occupied and with activiti waiting for the task to finish?

Thank you very much for the feedback!
15 REPLIES 15

rajivmoghe
Champ in-the-making
Champ in-the-making
Lofi / Martin,

For the  RuntimeService.signal(execId, signalName, signalData) call, you may want to note that the signal in the RuntimeService.signal and the signal of the signalName/signalData are two different concepts as explained by Joram in this post.

Basically the method call signal refers to a 'trigger', while the signal objects in the signature are 'BPMN Signal' artefacts.

Subscribing to a signal is most likely not going to be helpful, since those 'subscribe-able signals' are expected to be thrown from _within_ the engine, by some (other) running instance.

Cheers
Rajiv

lofi
Champ in-the-making
Champ in-the-making
Thank you very much Rajiv! Following your link I found this one in your post:

http://long-running.net/blog/2015/should-asynchronous-service-invocations-be-visible-in-a-bpmn-diagr...

It confirms that the SignallableActivityBehavior with sending a signal( executionId) and an optional map with parameters seems to be the right approach.

martin_grofcik
Confirmed Champ
Confirmed Champ
Hi Rajiv,

Subscribing to a signal is most likely not going to be helpful, since those 'subscribe-able signals' are expected to be thrown from _within_ the engine, by some (other) running instance.

Subscribing to signals can help.

  /**
   * Notifies the process engine that a signal event of name 'signalName' has been received. This method delivers the signal to a single execution, being the execution referenced by 'executionId'. The
   * waiting execution is notified synchronously.
   *
   * @param signalName
   *          the name of the signal event
   * @param executionId
   *          the id of the execution to deliver the signal to
   * @param processVariables
   *          a map of variables added to the execution(s)
   * @throws ActivitiObjectNotFoundException
   *           if no such execution exists.
   * @throws ActivitiException
   *           if the execution has not subscribed to the signal
   */
  void signalEventReceived(String signalName, String executionId, Map<String, Object> processVariables);

Signals (and messages) can be invoked outside of the engine.

Regards
Martin

lofi
Champ in-the-making
Champ in-the-making
Subscribing to signals can help. Signals (and messages) can be invoked outside of the engine.

How do you subscribe to a signal from within a JavaDelegate or an ActivitiBehavior?

Thank you very much!

martin_grofcik
Confirmed Champ
Confirmed Champ
Hi Lofi,

example


  public void execute(DelegateExecution execution) {
    ExecutionEntity executionEntity = (ExecutionEntity) execution;
    Context.getCommandContext().getEventSubscriptionEntityManager().insertSignalEvent(signalEventDefinition, signal, executionEntity);
  }

regards
Martin

martin_grofcik
Confirmed Champ
Confirmed Champ
Hi Lofi,

example


  public void execute(DelegateExecution execution) {
    ExecutionEntity executionEntity = (ExecutionEntity) execution;
    Context.getCommandContext().getEventSubscriptionEntityManager().insertSignalEvent(signalEventDefinition, signal, executionEntity);
  }

regards
Martin