WCF technical analysis of the nine: Service agents can not be closed in time what will be the consequences?

We want to have a certain understanding of WCF will know: in the client through the service call for service invocation process, the service agent should be closed in time. But what are the consequences if the service agent does not wait to be shut down in time? What do you want to close the service agent? Do you need to turn off the service agent at all times? Are there some exceptions? This article will revolve around these issues.

One, session channel (Sessionful Channel) v.s. Datagram Channel (Datagram Channel)

WCF implements the message encoding, transmission and special processing based on some special functions, while the binding object is the creator of the channel stack, and the channel stack created by different binding types has different characteristics. In terms of support for the session, we can divide the channel into the following two kinds:

Session channel (Sessionful Channel): The session channel ensures that messages transmitted between client and server are interconnected, but that channel errors (Fault) can affect subsequent message exchanges;

Datagram Channel (Datagram Channel): Even in the same datagram channel, each message exchange is independent of each other, and the channel error does not affect subsequent message exchange.

For most binding types (except BasicHttpBinding), the session channel is created by default. For WCF clients, if a service invocation based on a session channel is made, there are some issues that need to be paid attention to, and if used improperly, it affects not only the service invocation of the client itself, but also the throughput of the service processing request.

Ii. restrictions on the shutdown of service agents and concurrent sessions (Concurrent Sessions)

The first problem based on session channel service invocation is related to WCF traffic restrictions, in order to give readers an intuitive understanding of the problem, we routinely reproduce the problem to be solved by a simple experiment. This example uses the familiar example of compute services, which uses wshttpbinding at the time of service boarding, followed by the client program.

   1:binding Binding = new Wshttpbinding (); EndpointAddress address = new EndpointAddress ("Http://127.0.0.1:9999/calculateservice"); channelfactory<icalculator> ChannelFactory = new channelfactory<icalculator> (binding, address); for (int i = 1; I <= i++)
   2: {
   3:     Try
   4:     {
   5:         ICalculator calculator = Channelfactory.createchannel ();
   6:         Console.WriteLine ("{3}: X + y = {2}" when x = {0} and y = {1} ", 1, 2, calculator.) ADD (1, 2), i);
   7:     }
   8:     catch (Exception ex) {Console.WriteLine ("{0}t: {1}", I, ex. message); }
   9:}

Output results:

   1:1: x + y = 3 when x = 1 and y = 2
   2:2: x + y = 3 when x = 1 and y = 2
   3: ...
   4:10:x + y = 3 when x = 1 and y = 2
   5:11:x + y = 3 when x = 1 and y = 212: Request Channel timeout after waiting for 00:00:59.9840000. Increases the time-out value that is passed to the request call, or increases the sendtimeout values on the binding. The time allotted to this operation may be part of a longer timeout

From the output of the results can be seen, although in the code we have a for loop for 20 times service invocation, but the real successful execution of only 11 times, the 12th time when the service invocation, throw timeout exception. This occurs because of the WCF's control over the number of concurrent sessions. To be specific, WCF restricts the concurrent sessions that a ServiceHost can handle, by default, the maximum number of concurrent sessions allowed is 10.

So attentive readers will immediately ask a question, since the default number of concurrent sessions is 10, why in the above example, there will be 11 successful concurrent service calls? This is because the channel listener on the server side allows an additional session channel. In many cases, 11 concurrent sessions are certainly unable to meet the specific requirements, then whether the appropriate configuration to the specific requirements of the flexibility to specify a suitable maximum number of concurrent sessions? The answer is yes, the maximum concurrent sessions allowed by the service can be configured through the MaxConcurrentSessions attribute of the Servicethrottlingbehavior service behavior. In the following configuration, set the value to 20.

   1: <?xml version= "1.0" encoding= "Utf-8"?>
   2: <configuration>
   3:   <system.serviceModel>
   4:     <behaviors>
   5:       <serviceBehaviors>
   6:         <behavior name= "Highconcurrencybehavior" >
   7:           <servicethrottling maxconcurrentsessions= "/>"
   8:         </behavior>
   9:       </serviceBehaviors>
  :     </behaviors>
  One: ...     
     </system.serviceModel>
  </configuration>

WCF's restrictions on concurrent sessions of services give WCF clients a requirement that they should be shut down in a timely manner when the service agent is no longer in use. A session based on a service proxy object is closed as the service agent closes. When the server is processing a client request, if the current number of concurrent sessions exceeds the allowable range, subsequent requests will be placed in the wait queue to wait for the end of the existing session. For a client, a service invocation does not receive a reply within the allowable time-out period (the default 1 minutes), and a TimeoutException exception is thrown, as the example shows. If the service proxy object can be shut down in a timely manner, even 2000 calls are not problematic, as follows:

   1:binding Binding = new Wshttpbinding ();
   2:endpointaddress address = new EndpointAddress ("Http://127.0.0.1:9999/calculateservice");
   3:channelfactory<icalculator> ChannelFactory = new channelfactory<icalculator> (binding, address);
   4:for (int i = 1; i <=; i++)
   5: {
   6:     ICalculator calculator = Channelfactory.createchannel ();
   7:     Console.WriteLine ("{3}: X + y = {2}" when x = {0} and y = {1} ", 1, 2, calculator.) ADD (1, 2), i);
   8:     (Calculator as Icommunicationobject). Close ();
   9:}

Output results:

   1:1: x + y = 3 when x = 1 and y = 2
   2:2: x + y = 3 when x = 1 and y = 2
   3: ...
   4:1999:x + y = 3 when x = 1 and y = 2
   5:2000:x + y = 3 when x = 1 and y = 2