I know there are quite some questions about this issue already, but no reply solved my problem.
I have a NetTcpBinding on a server running, and from time to time (not always, like 1 out of 20 to 60 calls, completely random) I receive this exception on the client side:
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 '00:01:00'.
I noticed that this exceptions occurs much more frequently when the client's connection is slow.
Also, the timeout stated is 1 minute, but the exception already occurs after 1 second or so.
What I do:
var client = GetClient();
client.Open();
bool success = client.Call(); // Exception occurs here (the return value is a bool)
I sometimes also get this exception on the server side:
A TCP error (995: The I/O operation has been aborted because of either a thread exit or an application request) occurred while transmitting data.
I have server tracing enabled but I get the same exceptions, and it doesn't provide me with any additional insight.
My GetClient:
NetTcpBinding netTcpBinding = new NetTcpBinding
{
CloseTimeout = new TimeSpan(0, 0, 30),
OpenTimeout = new TimeSpan(0, 0, 30),
TransferMode = TransferMode.Buffered,
ListenBacklog = 2,
MaxConnections = 2,
MaxReceivedMessageSize = 10485600,
ReaderQuotas = { MaxStringContentLength = 1048576 },
ReliableSession = { Enabled = false },
Security =
{
Mode = SecurityMode.Transport,
Transport = { ClientCredentialType = TcpClientCredentialType.None, ProtectionLevel = ProtectionLevel.EncryptAndSign },
Message = { ClientCredentialType = MessageCredentialType.Windows }
}
};
Important config from service:
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" httpHelpPageEnabled="true" httpsHelpPageEnabled="true" />
<serviceAuthorization principalPermissionMode="Custom" serviceAuthorizationManagerType="My.Service.WCF.Tools.CustomAuthorizationManager, My.Service.WCF">
<authorizationPolicies>
<clear/>
<add policyType="My.Service.WCF.Tools.CustomAuthorizationPolicy, My.Service.WCF" />
</authorizationPolicies>
</serviceAuthorization>
<serviceCredentials>
<serviceCertificate findValue="MyService" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" />
</serviceCredentials>
<serviceThrottling maxConcurrentCalls="65536" maxConcurrentSessions="65536" maxConcurrentInstances="65536" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<customBinding>
<binding name="ServiceBinding" receiveTimeout="00:05:00" maxConnections="65536" listenBacklog="65536">
<transactionFlow />
<sslStreamSecurity requireClientCertificate="false" />
<binaryMessageEncoding />
<tcpTransport transferMode="Buffered" portSharingEnabled="true" maxReceivedMessageSize="1048576" maxPendingConnections="65536" maxPendingAccepts="10">
<connectionPoolSettings leaseTimeout="00:05:00" idleTimeout="00:05:00" maxOutboundConnectionsPerEndpoint="65536" />
</tcpTransport>
</binding>
<binding name="MexBinding" receiveTimeout="00:05:00" maxConnections="65536" listenBacklog="65536">
<tcpTransport transferMode="Buffered" portSharingEnabled="true" maxReceivedMessageSize="1048576" maxPendingConnections="65536" maxPendingAccepts="10">
<connectionPoolSettings leaseTimeout="00:05:00" idleTimeout="00:05:00" maxOutboundConnectionsPerEndpoint="65536" />
</tcpTransport>
</binding>
</customBinding>
</bindings>
I have already updated service reference and tried to change some of the buffer and sizes, but it didn't work (not that I'd expect an issue there as only a bool is returned).
Fixed using:
OperationContext.Current.OperationCompleted += Test;
private void Test(object sender, EventArgs e)
{
OperationContext.Current.Channel.Close();
}
Do not use the Abort but the Close method!
I found the problem: I aborted the channel on server side with
OperationContext.Current.OperationCompleted
which called:
OperationContext.Current.Channel.Abort();
This seems to work fine in 99% of the cases, but not all, using:
OperationContext.Current.Channel.Close();
resolved my problem completely.