none
Timeout to end workflow? RRS feed

  • Question

  • Hi!

     

    I would like to create a timeout in our workflow in case something goes completely wrong and calls are not disconnected for some reason. I tried a parallelactivity with a delay on one side but this was very wrong. I hope the error handling we use is sufficient but if the workflow slows down during high load or a transfer goes wrong, the server would have an extra chance to recover.

     

    Has anybody done anything similar?

     

    Thanks for your help!

    Wednesday, May 23, 2007 2:35 PM

Answers

  • Hi!

     

    Current status is that performance has improved. We found that db access performance was low and made the following changes:

    1. db lookups that where supposed to be real time are cached for 2 minutes which in practice lowers the amount of db access with 50%

    2. all database acces tries to get an connection from a connection pool of 120 connections (before connection pool with size not set rapidly rose to 60). If connection is not received within 2 s, a non-pooled connection is created.

    3. data required for if-else branches (conditions used properties that performed db lookups) where fetched before the if-else was reached to avoid locks and extra fetches. 

    4. maxiothreads and maxworker threads in machine.config where set to 200

     

    1 and 4 had great impact and 2 is just an extra precaution. 3 was not tested seperately and I do not believe this had any real impact but it looks safer anyway.

     

    So I guess I do not need the Timeout, even though I am still curious how this could be done.

     

    Thanks for you help!

    Monday, June 18, 2007 7:25 AM

All replies

  • Markus,

    When you say the workflow slows down, what operation are you performing? You can perform the operation asynchronously and have a timeout on the callback and the throw a custom exception that is caught by workflow to make furthur decisions.

     

    Sujeet 

    Wednesday, May 23, 2007 10:49 PM
  • Hi Sujeet,

    I am not sure what happens when the workflow slows down. The timeout on the callback would solve some parts but I would like a general way to handle all types of errors, whatever they might be. So if a normal call takes 15s and the workflow has been running for 60s, I would like it to disconnect the call. Do you know how to implement this?

     

    Thanks for your input!

    Thursday, May 24, 2007 6:33 AM
  • Are you trying to solve a theoretical problem problem of how to handle an overloaded system, or are you actually seeing your workflow slow down?  If the former then I suggest that you leave it up to the platform to handle.  Speech Server rejects calls when various latencies get high, and this should keep the performance reasonable by avoiding overloading the system. 

     

    If the latter, then you need to investigate the problem.  Is this the same problem as in the "high load issues" thread, or something different?  If your slow-down is due to a shortage of threadpool threads, then starting timers isn't going to help, because the timers themselves fire on threadpool threads.

    Wednesday, May 30, 2007 8:47 AM
  • Hi Markus,

    Can you let us know the status of your issue? Did you try Anthony's suggestions?

    Wednesday, June 13, 2007 10:24 PM
  • Hi!

     

    Current status is that performance has improved. We found that db access performance was low and made the following changes:

    1. db lookups that where supposed to be real time are cached for 2 minutes which in practice lowers the amount of db access with 50%

    2. all database acces tries to get an connection from a connection pool of 120 connections (before connection pool with size not set rapidly rose to 60). If connection is not received within 2 s, a non-pooled connection is created.

    3. data required for if-else branches (conditions used properties that performed db lookups) where fetched before the if-else was reached to avoid locks and extra fetches. 

    4. maxiothreads and maxworker threads in machine.config where set to 200

     

    1 and 4 had great impact and 2 is just an extra precaution. 3 was not tested seperately and I do not believe this had any real impact but it looks safer anyway.

     

    So I guess I do not need the Timeout, even though I am still curious how this could be done.

     

    Thanks for you help!

    Monday, June 18, 2007 7:25 AM