I have a self hosted .Net 4.0 WCF service that I'm trying to convert from WsHttpBinding to NetTcpBinding for performance reasons. The service works just fine with the WsHttpBinding.
Strangely enough, The service seems to work after switching to NetTcpBinding. (The service posts messages to a enterprise messaging system, and the message is posted and the client receives no error) however the following error is written to the server log:
Error: Service: MessageSenderService, Details: System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused
by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue.
Local socket timeout was '10675199.02:48:05.4775807'. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.ServiceModel.Channels.SocketConnection.HandleReceiveAsyncCompleted()
at System.ServiceModel.Channels.SocketConnection.BeginReadCore(Int32 offset,Int32 size, TimeSpan timeout, WaitCallback callback, Object state)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.SocketConnection.BeginReadCore(Int32 offset,Int32 size, TimeSpan timeout, WaitCallback callback, Object state)
at System.ServiceModel.Channels.TracingConnection.BeginRead(Int32 offset, Int32 size, TimeSpan timeout, WaitCallback callback, Object state)
at System.ServiceModel.Channels.SessionConnectionReader.BeginReceive(TimeSpan timeout, WaitCallback callback, Object state)
at System.ServiceModel.Channels.SynchronizedMessageSource.ReceiveAsyncResult.PerformOperation(TimeSpan timeout)
at System.ServiceModel.Channels.SynchronizedMessageSource.SynchronizedAsyncResult`1..ctor(SynchronizedMessageSource syncSource, TimeSpan timeout, AsyncCallback callback, Object state)
at System.ServiceModel.Channels.TransportDuplexSessionChannel.BeginReceive(TimeSpan timeout, AsyncCallback callback, Object state)
at System.ServiceModel.Channels.TransportDuplexSessionChannel.TryReceiveAsyncResult..ctor(TransportDuplexSessionChannel channel, TimeSpan timeout, AsyncCallback callback, Object state)
at System.ServiceModel.Channels.TransportDuplexSessionChannel.BeginTryReceive(TimeSpan timeout, AsyncCallback callback, Object state)
at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.BeginTryReceive(TimeSpan timeout, AsyncCallback callback, Object state)
Again, no error occurs on the server log when using the WsHttpBinding.
Server Config:
<service behaviorConfiguration="debugEnabled" name="My.Service">
<endpoint address="" binding="netTcpBinding" bindingConfiguration="netTcpBindingConfig"
contract="My.Service.Contract" />
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />
</service>
....
<behaviors>
<serviceBehaviors>
<behavior name="debugEnabled">
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceThrottling maxConcurrentSessions="200" maxConcurrentCalls="500" maxConcurrentInstances="200"/>
<serviceMetadata httpGetEnabled="true" />
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
</behavior>
</serviceBehaviors>
</behaviors>
....
<bindings>
<netTcpBinding>
<binding name="netTcpBindingConfig" maxReceivedMessageSize="5242880" closeTimeout="00:01:00" receiveTimeout="00:01:00" sendTimeout="00:01:00" openTimeout="00:01:00">
<readerQuotas maxArrayLength="5242880" />
<security mode="None" />
</binding>
</netTcpBinding>
</bindings>
We build the client binding in code, not config. That looks like this:
return new NetTcpBinding(SecurityMode.None, reliableSessionEnabled)
{
MaxBufferPoolSize = Int32.MaxValue,
MaxReceivedMessageSize = Int32.MaxValue,
ReaderQuotas = new XmlDictionaryReaderQuotas
{
MaxArrayLength = Int32.MaxValue,
MaxDepth = Int32.MaxValue,
MaxStringContentLength = Int32.MaxValue
},
ReceiveTimeout = TimeSpan.FromMinutes(1.0),
CloseTimeout = TimeSpan.FromMinutes(1.0),
OpenTimeout = TimeSpan.FromMinutes(1.0),
SendTimeout = TimeSpan.FromMinutes(1.0)
};
Any ideas out there?
EDIT: I would like to add that I see the error on every call to the service, not only under load. The request and response messages are very small so it likely not related to message size. The error is written almost instantaneously, so it it not a timeout problem.