WCF Reliable Sessions Puzzle - Powered by Discuz!NT Archiver

admin - 2008-6-14 18:34:00

WCF Reliable Sessions Puzzle(解决:System.ServiceModel.Channels.ServiceChannel)
As I mentioned on my previous post, I have spent a few days very puzzled with a behaviour in WCF reliable messaging/sessions.
THe problem all starts because as documented here, creating WCF clients (the classes generated by svcutil.exe) is quite expensive due to the rich set of functionality implemented in WCF. You can learn more about the client model here. To overcome the problem, there are basically two options:

Create aChannelFactory instance and keep that in the application contextsomewhere, so you don't have to initialize the factory every time youneed a client. You then use this factory to create client channelsdirectly;

Create a client instance and cache that to be reused for multiple calls.

Ultimatelly, option 2offers the best performance, as you go through the expense ofinstantiating the client only once. I then wrote a pool class to managea number of client instances and all was nice and cool until theclients' connections started to be closed by the WCF host due toinactivity (I'm using NetTcp binding). As my application is the onlyone to use my WCF service and I can control the number of clientconnections open to the host at one time, I wanted just to keep theseconnections alive for as long as the client application lived, so Ithought about using Reliable Sessions for that. Basically, asdocumented here, reliable sessions are kept alive by the WCF architecture indefinitely, so that's good for what I need.
The weird thing started whenafter enabling reliable sessions in my app, the behaviour of the hostdidn't change: it would still drop my connections after 10 minutes andeverything would go bad. I then wrote some simple code to try toreplicate the problem, code that can be seen below:
using System;
using System.ServiceModel;

namespace Service
{

[ServiceContract(SessionMode = SessionMode.Allowed,

Namespace = "http://tempuri.org/Services/IServiceContract")]

public interface IServiceContract

{

[OperationContract]

string DoSomething(string arg);

}

[ServiceBehavior(Namespace = "http://tempuri.org/Services/ServiceImplementation")]

public class ServiceImplementation : IServiceContract

{

#region IServiceContract Members

public string DoSomething(string arg)

{

return string.Format("The string passed in was '{0}'.", arg);

}

#endregion

}

class Program

{

static void Main(string[] args)

{

using (ServiceHost serviceHost = new ServiceHost(typeof(ServiceImplementation)))

{

serviceHost.Open();

Console.WriteLine("Service running. Press any key to exit.");

Console.Read();

serviceHost.Close();

}

}

}
}

The configuration file for the service looks like the following:

<?xml
version="1.0"
encoding="utf-8" ?>
<configuration>

<system.serviceModel>

<bindings>

<netTcpBinding>

<binding
name="NetTcp_Reliable">

<reliableSession
ordered="false"
inactivityTimeout="00:10:00"

enabled="true" />

</binding>

</netTcpBinding>

</bindings>

<behaviors>

<serviceBehaviors>

<behavior
name="MetadataBehavior">

<serviceMetadata
httpGetEnabled="true"
httpGetUrl="http://localhost:2526/Service" />

</behavior>

</serviceBehaviors>

</behaviors>

<services>

<service
behaviorConfiguration="MetadataBehavior"
name="Service.ServiceImplementation">

<endpoint
address="net.tcp://localhost:2525/Service"
binding="netTcpBinding"

bindingConfiguration="NetTcp_Reliable"
contract="Service.IServiceContract" />

</service>

</services>

</system.serviceModel>
</configuration>

Forthe client application I have used svcutil.exe to generate the WCFclient and the configuration file. The client is pretty ordinary and Ihaven’t changed anything so I will spare you the bore of reading it,but the config file looked like this:

<?xml
version="1.0"
encoding="utf-8"?>
<configuration>

<system.serviceModel>

<bindings>

<netTcpBinding>

<binding
name="NetTcpBinding_IServiceContract"
closeTimeout="00:01:00"

openTimeout="00:01:00"
receiveTimeout="00:10:00"
sendTimeout="00:01:00"

transactionFlow="false"
transferMode="Buffered"
transactionProtocol="OleTransactions"

hostNameComparisonMode="StrongWildcard"
listenBacklog="10"

maxBufferPoolSize="524288"
maxBufferSize="65536"
maxConnections="10"

maxReceivedMessageSize="65536">

<readerQuotas
maxDepth="32"
maxStringContentLength="8192"
maxArrayLength="16384"

maxBytesPerRead="4096"
maxNameTableCharCount="16384" />

<reliableSession
ordered="false"
inactivityTimeout="00:10:00"

enabled="true" />

<security
mode="Transport">

<transport
clientCredentialType="Windows"
protectionLevel="EncryptAndSign" />

<message
clientCredentialType="Windows" />

</security>

</binding>

</netTcpBinding>

</bindings>

<client>

<endpoint
address="net.tcp://localhost:2525/Service"
binding="netTcpBinding"

bindingConfiguration="NetTcpBinding_IServiceContract"
contract="IServiceContract"

name="NetTcpBinding_IServiceContract">

</endpoint>

</client>

</system.serviceModel>
</configuration>

Thesesettings are pretty much the defaults for NetTcp binding except for thereliableSession element that enables RM and disables message ordering.The console application that uses the WCF client looks like thefollowing:

namespace Client
{
class Program

{
static void Main(string[] args)

{
ServiceContractClient client = new ServiceContractClient();

client.InnerChannel.Faulted += new EventHandler(InnerChannel_Faulted);
Console.WriteLine("The call was made at {0} and the response was '{1}'", DateTime.Now, client.DoSomething("First Call"));
Console.WriteLine("Press any key to call the server again!");
Console.Read();
Console.WriteLine("The call was made at {0} and the response was '{1}'", DateTime.Now, client.DoSomething("Second Call"));
Console.Read();

}

static void InnerChannel_Faulted(object sender, EventArgs e)

{
Console.WriteLine("The channel faulted!");

}

}
}

Theabove console application allowed me to let the application hit theservice once, then I could leave it idle for as much as I wanted andtry to hit the service again after pressing any key. It will alsohandle the Faulted event in the client’s inner channel. The behaviour Iwas expecting is that regardless of how long I left the applicationidle after the first call to the service, when I pressed a key I wouldstill be able to call the service again. What happenned instead is thatafter 10 minutes of the application iddle, the Faulted event of thechannel would be raised, telling me that the connection was gone.

Myfirst thought was to increase the InactivityTimeout on the reliablesession configuration in both client and server to 20 minutes insteadof 10 and see what happened. When running the application it wouldstill fault the channel after 10 minutes.

Afterposting in the WCF forums I was pointed to the Receive Timeout in thebinding configuration. After reading the extensive (NOT) documentationavailable for this property I was led to believe that it was the timealowed for a receive operation (i.e. the time the client takes to senda full message stream) to be completed, but in reality this property isthe time the service allows between client calls(poor, poor documentation Microsoft). Even though, my understanding wasthat the WCF infrastructure messages exchanged by RM to keep thesession alive would count for this receive timeout and would keep myconnection alive, but that evidently wasn’t happening.

Wethen contacted Microsoft PSS and after a while they confirmed that thebehavior should be that the infrastructure messages keep the connectionalive, but they have changed something in the receive timeout behaviourclose to RTM and the end result was that this setting overrideseverything else (all other timeouts or sessions) in WCF. It isrecognised within Microsoft as a bug, which is good: they know aboutthe bug… but the bad news are that they don’t plan to fix it before WCFversion 2.0 as they believe there’s a viable workaround. The workaroundin this case is that you can set the receive timeout to an extremelylong time span (or System.TimeSpan.MaxValue) or the infinite keyword(that behind the scenes will use System.TimeSpan.MaxValue) and it willproduce the expected behaviour.

Moralof the story is: if you ever use WCF reliable messaging and need thesession to be kept alive indefinitely you already know: set the receivetimeout to something very, very big.

星辰.Net技术社区论坛