You are viewing limited content. For full access, please sign in.

Question

Question

Terminate Runaway Workflows

asked on March 31, 2014 Show version history

We have a customer with hundreds of runaway workflows.  We've managed to disable the timer job that is causing the issue but cant terminate the workflows that started as the terminate action in the designer and the Delete Instance action in the WF Admin console both time out because the runaway Workflows are eating up all of the server resources.  We've stopped the Workflow services but as soon as we restart them the runaway workflows start back up and cripple the server.  Does anyone know of another way to terminate all workflows? Maybe through SQL?

0 0

Answer

SELECTED ANSWER
replied on April 1, 2014

Turns out we couldn't remove the permissions on the database lookup user as the customer had used a shared account that other apps utilized.  Instead I just disabled the Workflow user so it couldn't see into Laserfiche and that allowed me to terminate the remaining workflows.  Not the most elegant way to handle this but it worked.

0 0

Replies

replied on April 28, 2017 Show version history

Further to this, there has to be an easier way to terminate all running workflows than through the designer.

 

Can we make a feature request for a "Kill All" button or similar?

1 0
replied on April 28, 2017

You can search for them, select them all and terminate them.

0 0
replied on April 28, 2017

Hi Miruna,

 

Yes that's what I'm currently doing, but in the instance I'm working on now, it has 80,000 running workflows (the customer built their own runaway workflow indecision), I've disabled all the rules and am terminating the workflows through the search. It's been running through terminating the workflows now for 2 and a half hours and is only 11% through them.

 

It would be nice if there was a 'cleaner' way of doing this rather than through the designer. Even a 'workflow kill' EXE or something we could run (or a SQL script).

 

Just a thought....

0 0
replied on April 28, 2017

Tech Support can provide an utility that will clean up these instances from the database directly.

3 0
replied on April 28, 2017

Awesome, thanks Miruna.

0 0
replied on March 31, 2014 Show version history

Have you tried just stopping the starting rules of the Workflow in question?  Open the Designer and go to the Rule Manager.  Disable the starting rules for the WF in question.

 

I believe you can also right-click and delete the WF from the All Workflows node in the designer.  However you need to make sure you have saved the workflow (.wfx) file before you try this so you can republish.

 

Edit:  Hmm, after reading the question again that's about what you tried correct?

 

Maybe change the password of the WF account so that the Workflows fail?  Maybe that would give you enough time to delete the Workflow?

0 0
replied on April 1, 2014

Yeah, I've disabled the start rules and am having to slowly terminate the running workflows when it lets me.  The issue appears to be with the SQL query the customer used so I am going to remove permissions for the WF account on the SQL db which should force the queries to die and hopefully kill the Workflows.  I wish there was a way to start workflow in "safe" mode where you could get to the workflows to edit/kill them without it actually starting any.  Or a way to clear the queue so when you start workflow any that were in process wont start.  I haven't run across this issue very often but it would be handy if there was an easy way around it.  Thanks for your advice.

0 0
SELECTED ANSWER
replied on April 1, 2014

Turns out we couldn't remove the permissions on the database lookup user as the customer had used a shared account that other apps utilized.  Instead I just disabled the Workflow user so it couldn't see into Laserfiche and that allowed me to terminate the remaining workflows.  Not the most elegant way to handle this but it worked.

0 0
replied on June 24, 2014

I had the same thing happen where a runaway started before the weekend (without anyone noticing) and come Monday, SQL was pegged down in RAM and bogged down.

 

I ended up putting a Terminate WF action at the beginning of the fouled workflow and publishing, updating existing instances.  Turning off the rule didn't clear the.  Terminating persisted instances/waiting instances would hang and crash designer.

 

After a bit, the backed up queue was clear and I could fix what had happened.  I believe there is an easier way to do this on the SQL server.  Something with clearing the messaging queue/pending messages/dead letter messages?  If any SQL gurus out there would chime in, that would be great.

0 0
replied on September 26, 2017

I like the "End Workflow" activity at the start of it idea.  I just had another customer do this and your suggestion worked great in this case.  Still would love a quick/easy button to "Kill All Running Workflows" but this was a great solution.  Thanks again!

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.