locked
WF service - WCF configuration RRS feed

  • Question

  • I have an issue configuring the WF & WCF service altogether. The problem is that I cannot get the behavior wanted from the service.
    I have a WF service hosted in a console app for which I have setted
    InstanceContextMode.Single and
    ConcurrencyMode.Multiple .
    The service contract used has as attribute SessionMode.NotAllowed.
    In app config I have
    <serviceThrottling maxConcurrentCalls="2" maxConcurrentSessions="5" maxConcurrentInstances="2147483647" />
    In the client app I have created X parallel threads that perform calls to the WF service.
    Each thread executes the following code:

    WfService client = new WfService();
    while( iteration < 250 )
    {
    	client.MethodA(); // new WF instance gets created (service has CanCreateInstance=true )
    	client.MethodB();
    	client.MethodC();
    	client.MethodD(); // completes the WF</strong>
    
    	iteration ++;
    }
    
    
    1. If I run the client app with client.MethodD() and every instance completes at the end of the opperations the app runs smoth to the end.
    2. If I commment out client.MethodD() and every instance is executed up to the point of the completion but without executing the last activity, the client app gets stuck and crashes due to connection time-out.

    I have read the docs explaining every attribute and property used here without succeding in obtaining the behavior I want.

    I would like to WF service, to have client calls stacked up in queues while waiting to get processed by a relative small number of service instances ( 2-3). I would also like that the service accept an infinite number ( at least theoretically ) of instances opened at the same time. Since I have SQL persistance service activate all these instances will pile up in the DB.

    How can I get this behavior? Is there something wrong about this need ( to allow the client apps to create an unlimited number of workflow instances in the same time ) ?

    Thanks,
    Victor
    Wednesday, November 25, 2009 9:45 PM

Answers

All replies

  • We have been working in giving support for queues in WF, via the Buffered Receive feature. In order to use this feature, your WF service requires ReceiveContext support from the service endpoint binding. The binding that needs to be used in this case is NetMsmqBinding (http://msdn.microsoft.com/en-us/library/system.servicemodel.netmsmqbinding.aspx). You can change the binding to be used by the endpoint in config, via the <endpoint> tag, or via the <protocolMapping> if you are using the new default configuration system developed in .NET 4.

    Also, the client endpoint needs to be using the NetMsmqBinding, but I believe you will have no problems with that since that part is autogenerated by using "Add Service Reference" in VS10, or the svcutil.exe tool.

    Also, we are currently working on sample that shows you how to turn on the Buffered Receive feature at the service, and how the different out-of-order messages are buffered at the service, and processed when the workflow becomes ready to receive them. That sample will be available in MSDN soon.

    Hope this helps.

     

    Tuesday, December 1, 2009 7:06 PM
  • I see. I believe there will be something similar or equivalent to in the case of usage WCF on Azure with .Net Services and Service Bus. Is this correct?

    Unfortunately MSMQ is not an option for me so I will have to stay on NetTcpBinding. How can I remove the limitation of maximum Workflow Instances that can be created inside a hosted WF? For the moment I've set the value of MaxConcurrentInstances and maxConcurrentSessions  to 2147483647 but this seems to me a little bit savage.

    Supposing we are hosting one similar WF service on one single machine, could you share with us some recommended values for maxConcurrentCalls, maxConcurrentSessions and maxConcurrentInstances for optimum performance. This would be very helpfull. When thinking about performance my main concern is having at one time to many pending threads that will cause a performance penalty.

    Thanks,
    Victor

    Wednesday, December 2, 2009 9:17 PM
  • The recommended values for those settings really depend on your application. Setting those to the maximum value might make sense. You need to figure out what values are best for your application. The following blog post gives some information about those settings: http://blogs.msdn.com/wenlong/archive/2009/07/26/wcf-4-higher-default-throttling-settings-for-wcf-services.aspx

    Hope this helps.

    Wednesday, December 2, 2009 11:11 PM