Documentation Center

Avoiding workflow slowdowns and deadlocks

There are certain workflow designs that, in releases prior to WorldServer 9.0, could lead to performance delays or complete deadlocks. These problems have been addressed in WorldServer 9.0.

The following sections walk through various workflow scenarios and describe how the worfklow engine now handles each.

Workflow with Human Step in One Branch and Project-scope Action in Another

Consider the following workflow, where some tasks reach a project-scope action while others reach a human step:

Figure 1. Workflow where blocked tasks waited for tasks to complete human steps

In versions of WorldServer prior to 9.0, if tasks A, B, and C went to the Block Tasks project-scope automatic action, and tasks D, E, and F went to the Translate human step, the workflow would have to wait until tasks D, E, and F were translated and finished (or canceled) before it released tasks A, B, and C.

In WorldServer 9.0, the workflow engine recognizes that tasks D, E, and F can never reach the Block Tasks step. Because of this, the workflow engine would not wait for those tasks before releasing A, B, and C.

Workflow with Multiple Project-scope Actions

Consider the following workflow, where tasks can reach different project-scope actions simultaneously:

Figure 2. Workflow where tasks at different project-scope actions deadlocked

In versions of WorldServer prior to 9.0, if tasks A, B, and C went to the Block Tasks project-scope automatic action, and tasks D, E, and F went to the other Block Tasks project-scope action, the workflow would deadlock; the first project scope automatic action would be waiting on tasks D, E, and F while the second project scope automatic action would be waiting on tasks A, B, and C.

In WorldServer 9.0, however, the workflow engine recognizes that tasks A, B, and C can never reach the other Block Tasks step and that tasks D, E, and F can never reach the other Block Tasks step. Because of this, the workflow engine would not wait for those tasks.

Workflow with Human Steps that Can Loop Back to Project-scope Actions

Consider the following workflow, which contains a branch whereby a task can loop back to a project-scope action:

Figure 3. Workflow where tasks looped back and were blocked waiting for other tasks to complete

In versions of WorldServer prior to 9.0, if tasks A, B, and C looped back to the Block Tasks project-scope automatic action from the Translate step, they would no longer behave like project-scope steps and would behave like task steps. They wouldn't wait for each other and they wouldn't wait for tasks D, E, and F. Nor would they wait for any new tasks.

In WorldServer 9.0, however, when tasks A, B, and C loop back to the Block Tasks step, they retain their project scope, and the workflow doesn't release D, E, and F to Review until A, B, and C have passed the Translate step.

This scenario becomes complex in the case where tasks are added to the project when older tasks have already passed the Block Tasks step. If new assets are added to the project and old assets have already completed the project scope step, as before, in simple cases, workflow engines will not wait for the old assets before executing the new ones when they all get to the project scope step. But now the change in behavior for WorldServer 9.0 is that workflow engines will wait for the old assets in complex cases where the old assets are on a path that can in some way lead back to the project scope step.

Because the Translate step can loop back to the project-scope Block Tasks step, it will be handled the same way as steps preceding the project-scope step in the workflow. This means that any tasks that were restarted (for example, because the project manager was notified that the assets had been updated) and are now on the Block Tasks step will block until the translator has finished with all the other original tasks, to ensure that if he or she did later decide to restart some of those tasks, they would be processed along with the other restarted tasks.

This blocking on tasks on steps following the project-scope step only happens in this case, where:
  1. All original tasks have already passed the project-scope step.
  2. Some tasks are still on subsequent workflow steps that can loop back to the project-scope step.
  3. Some original tasks have looped back to the project-scope step, or some new tasks have been added that have reached the project-scope step.

Summary of Workflow Enhancements

These improvements to the workflow engine have:
  • Eliminated the possibility of deadlocks in workflow.
  • Enabled work to progress at a faster pace through the workflow because unnecessary wait conditions have been eliminated.
  • Let the translator work on the assets she or he needs to work on without being blocked by reviewers who are working on a completely different set of assets.