TransportFailure with .NET SDK

pkramer · September 7, 2017, 9:05pm

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?

github.com

couchbase/couchbase-net-client/blob/79298113dabd1465943b3e665878b1287629698b/Src/Couchbase/OperationResult.cs#L64




/// <summary>
/// If Success is false and an exception has been caught internally, this field will contain the exception.
/// </summary>
public System.Exception Exception { get; set; }


public bool ShouldRetry()
{
    switch (Status)
    {
        case ResponseStatus.TransportFailure:
        case ResponseStatus.VBucketBelongsToAnotherServer:
            return true;
        case ResponseStatus.ClientFailure:
            return IsClientFailureRetriable();
        case ResponseStatus.NodeUnavailable:
        case ResponseStatus.Success:
        case ResponseStatus.KeyNotFound:
        case ResponseStatus.KeyExists:
        case ResponseStatus.ValueTooLarge:
        case ResponseStatus.InvalidArguments:

MikeGoldsmith · September 8, 2017, 9:16am

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

pkramer · September 11, 2017, 3:22pm

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.