locked
Workflow ServiceHost multi-threading RRS feed

  • Question

  • Hi,

    If I execute my workflows in-process all is well but I would like to host a Workflow service with SQL persistence, there are enough docs out there on how to set this up but I was wondering about how such a service would handle multiple concurrent requests?

    ie. I invisage one service with one store that will process many long-running tasks from many different clients, at the same time.

    Thursday, January 31, 2013 10:06 AM

Answers

  • Exactly. Throttling settings just define a limit.

    Another problem with long-running workflows that you need to take into consideration is the following. As soon as you reach MaxConcurrentInstances the server will reject all incomming calls to the Workflow Service.

    From my point of view the expected behaviour is that client is able to quickly start many workflows and let server process them. Unfortunately this is not a default behaviour. There is a good explanation of the problem Throttling workflow services in WF4.

    This problem could be solved putting Delay activity after SendReply (like discribed in the article). To be honest I don't like this solution. Another approach is to start workflows async using MSMQ binding. It will allow to put requests into the queue and let system process them. It's not required to expose MSMQ to the client, but you could use WCF Routing Service with Protocol Bridging.

    • Marked as answer by albra Friday, February 1, 2013 11:58 AM
    Friday, February 1, 2013 10:46 AM

All replies

  • WCF provides throttling settings that could be used to limit how many instances or sessions are created at the application level

    • MaxConcurrentSessions: default is 100 * ProcessorCount
    • MaxConcurrentCalls: default is 16 * ProcessorCount
    • MaxConcurrentInstances: default is the total of the above two, which follows the same pattern as before.

    Thursday, January 31, 2013 1:49 PM
  • Hi Alex,

    So, it need to use WCF provider to set multi-threading, right? 


    Molly,
    Please Mark as the Answer, if this answers your question. Please vote as helpful, if this post is helpful.


    Friday, February 1, 2013 6:47 AM
  • What do you mean by "set multi-threading"? WCF service is multi-threaded by default. Concurrency behaviour could be changed  using ServiceBehaviorAttribute.InstanceContextMode Property

    The default value, PerSession, instructs the service application to create a new service object when a new communication session is established between a client and the service application. Subsequent calls in the same session are handled by the same object. 

    Number of concurrent threads configured using throttling settings.

    If you want to change the default behaviour you need to add behaviour to the WorkflowServiceHost. 

    WorkflowServiceHost wsh = ....
    ServiceBehaviorAttribute behavior = new ServiceBehaviorAttribute();
    behavior.InstanceContextMode = InstanceContextMode.Single;
    wsh.Description.Behaviors.Add(behavior);

    There are several way to do it. Check WCF documentation for details. But I would say that default settings are ok in most cases.



    Friday, February 1, 2013 8:46 AM
  • Thanks Alex, so are you saying that the service is already multi-threaded and will fire off a thread for each request automatically, depending on the throttling settings?
    Friday, February 1, 2013 10:27 AM
  • Exactly. Throttling settings just define a limit.

    Another problem with long-running workflows that you need to take into consideration is the following. As soon as you reach MaxConcurrentInstances the server will reject all incomming calls to the Workflow Service.

    From my point of view the expected behaviour is that client is able to quickly start many workflows and let server process them. Unfortunately this is not a default behaviour. There is a good explanation of the problem Throttling workflow services in WF4.

    This problem could be solved putting Delay activity after SendReply (like discribed in the article). To be honest I don't like this solution. Another approach is to start workflows async using MSMQ binding. It will allow to put requests into the queue and let system process them. It's not required to expose MSMQ to the client, but you could use WCF Routing Service with Protocol Bridging.

    • Marked as answer by albra Friday, February 1, 2013 11:58 AM
    Friday, February 1, 2013 10:46 AM
  • Thanks Alex, that article is very interesting.
    Friday, February 1, 2013 12:00 PM