cancel
Showing results for 
Search instead for 
Did you mean: 

Trigger Activiti workflow for task sitting in ReceiveTask causes a loop

ungawunga
Champ in-the-making
Champ in-the-making
I have an Activiti workflow that contains a ReceiveTask where I'm grouping tasks. I have a Listener that triggers on the event start of the ReceiveTask where I check the property of the newly added task to see if others with the same properties are in the same state. If yes, then I want to trigger them all to move to the next step in the workflow


    <receiveTask id="IssuePost" name="Issue Post">
      <extensionElements>
        <activiti:executionListener event="start" delegateExpression="${IssuePost}"></activiti:executionListener>
      </extensionElements>
    </receiveTask>


My Java Listener class IssuePost gets called when the task moves to the ReceiveTask just fine. I can get the list of other tasks sitting in that ReceiveTask. I'm having a problem triggering the tasks to move to the next step in the workflow. I get caught in a loop when calling "signal" on the tasks. The IssuePost listener keeps on getting triggered in an infinite loop until Alfresco/Activiti gives up and throws an exception.


    List<NodeRef> siblingNodes = searchService.selectNodes( parent, xpath, null, namespacePrefixResolver, false );
    if( siblingNodes.size() == batchCount )
    {
        for( int i=0; i < siblingNodes.size(); i++ )
        {
            List<WorkflowInstance> workflows = workflowService.getWorkflowsForContent( siblingNodes.get( i ), true );
            // this line causes the loop.
            workflowService.signal( workflows.get(0).getId(), null );


How can I signal the tasks in the ReceiveTask to move to the next step in the workflow without triggering the same listener in an infinite loop? There's only one flow out of the ReceiveTask to the next step in the workflow.

Should I signal the workflow in a different way?

I want to use a ReceiveTask since it holds the workflow tasks until I signal them to move on. Other tasks won't do that.
2 REPLIES 2

ungawunga
Champ in-the-making
Champ in-the-making
Let me ask the question in a different way: What is the correct process to follow to signal a task to continue in the workflow in a listener when the task in question is the one that triggered the listener?

I made some changes to the above code by hunting through the source code and randomly trying things. Calling "signal" on the WorkflowPath associated with the NodeRef's WorkflowInstance instead of the WorkflowInstance itself seems to have changed the infinite loop behavior, but my listener is still be called multiple times.


for( NodeRef siblingNode : siblingNodes )
{
    List<WorkflowInstance> workflows = workflowService.getWorkflowsForContent( siblingNode, true );
    List<WorkflowPath> paths = workflowService.getWorkflowPaths( workflows.get(0).getId() );
    for( WorkflowPath path : paths )
    {
        workflowService.signal( path.getId(), null );
    }
}


This lead to a different exception the second time the listener was called :

JavaException: org.activiti.engine.ActivitiOptimisticLockingException: ExecutionEntity[7925] was updated by another transaction concurrently

This makes sense, as the first time the listener is called, the task moves on through the workflow and is deleted before the listener is called a second time. But I still need to resolve why the listener is being called multiple times.

ungawunga
Champ in-the-making
Champ in-the-making
Not too many people with experience with Activiti? lol… Any suggestions on ways to debug this instead of just hunting/pecking/trying stuff?