On a random daily check on CA we found workflow timer job in “Paused” state in Central Admin. Multiple of these pointing to each server in farm in paused state. Many blog posts pointing to restarting the timer service on each server and also clearing the timer cache (configuration cache) would resolve the issue.
After the cache is cleared initially the jobs ran for a couple of instances and they were again pausing and the reason was a modified workflow resulting in a “dead end” state. Which was a mistake by the user. Each server processing workflows timer job became “stuck” due to items reaching the “dead end” state. Allworkflows with pauses or state changes would have ceased to be processed at this stage.
Under normal operations, a workflow is first executed in the World Wide Web Publishing Service (w3wp.exe). After a delay or pause, in which the workflow “sleeps,” it wakes up and is then run by the SharePoint Timer Service (the owstimer.exe process).
When w3wp.exe is under excessive load, it postpones the workflow. The Timer Service is then used to the continue the process. SharePoint dictates which Workflow Timer service will run the workflow; the operation can occur on any server running the “Microsoft SharePoint Foundation Workflow Timer Service” service. However, when Nintex Workflow is installed, it only deploys the DLLs required to run workflows to WFE servers–specifically, those servers running the “Microsoft SharePoint Foundation Web Application” service.
This issue is discovered by enabling verbose logging both at CA and also at Nintex global settings and also querying for the workflow name and its site collections using Nintex NWAdmin.exe
After the workflow is modified and already the workflows which are started with the broken workflow is cleared and again restarting the timer services on servers with clearing the cache resolved the issue.
This issue is reported on SharePoint 2010 and Nintex 2010
by Venu Madhav Gummalla via Everyone's Blog Posts - SharePoint Community
No comments:
Post a Comment