TransportFailure with .NET SDK



We are getting intermittent transport failures from the SDK which appear to only happen when there are periods of inactivity. This leads me to believe that we are missing a timeout in our configuration, but I’m not sure which values to set.

Here is the exception:

Save change marker result status: TransportFailure, message: An existing connection was forcibly closed by the remote host, should retry: False, exception: System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
   at Couchbase.IO.Connection.Send(Byte[] buffer)
   at Couchbase.IO.Services.PooledIOService.Execute[T](IOperation`1 operation, IConnection connection)
   at Couchbase.Authentication.SASL.ScramShaMechanism.Authenticate(IConnection connection, String username, String password)
   at Couchbase.Authentication.SASL.ScramShaMechanism.Authenticate(IConnection connection)
   at Couchbase.IO.Services.PooledIOService.Authenticate(IConnection connection)
   at Couchbase.IO.Services.PooledIOService.<ExecuteAsync>d__13`1.MoveNext()

Subsequent calls to the cluster are successful, so it’s like the first one wakes up the connection and fails with the transport failure, and then any requests after that succeed as expected.

Also, the IOperationResult.ShouldRetry() is returning false, even though the source indicates that it should be returning true for transport failures. Maybe I’m looking at the wrong implementation?


Hi @pkramer

We have just released version 2.5.0 of the SDK that includes a fix for a bug where the initial request to authenticate a connection can fail. Please can you try 2.5.0 and see this resolves your issue?

I’ll take a look into why the TransportFailure is not being caught in ShouldRetry.



Thanks, I’ll try upgrading. We are using 2.3.11 of the SDK because of a bug that was found in a more recent version, but that was a couple of months ago and I believe it was fixed in a 2.4+ version.