C# Driver fails to reconnect with the server in some situations when the MongoDb server is slow to respond and the connection times out or momentarily fails to connect to the server due to some temporary cluster unavailability.

We have a MongoDb 2.4.6 cluster running in a windows server on AWS with a normal (slow) EBS disk. In this scenario, we have noted several connectivity problems where the driver fails to reconnect after a brief (60 seconds or less) unavailability.

Note: this issue is related to the driver failling to reconnect to the MongoDb server after some kind of connectivity problem.

The error message in most cases is "Server instance

{0} is no longer connected.".

Exploring the driver code, I noted some possible issues:

On "MongoServerInstance.cs", on the method "MongoServerInstance.AcquireConnection" lines 382-394:
Whenever a ping fails ("MongoServerInstance.Ping", line 667 - 690), the connection is set to Disconnected by "SetState(MongoServerState.Disconnected);" (line 687).

So subsequent "AcquireConnection" calls fails with the message "Server instance {0}

is no longer connected." instead of trying to reconnect. So a brief connection problem can stop all future operations...

My suggestions is to change one line of code (line 386) on "MongoServerInstance.AcquireConnection" lines 382-394 code to:

internal MongoConnection AcquireConnection()
{
lock (_serverInstanceLock)
{
if (_permanentlyDisconnected)
{
var message = string.Format("Server instance

{0}

is no longer connected.", _address);
throw new InvalidOperationException(message);
}
}

return _connectionPool.AcquireConnection();
}

Server setup:
To ilustrate the current MongoDb cluster scenario, due to the low performance of the cluster setup, sometimes we face 3 kinds of connectivity problems related to:
1. sometimes we have a temporary (60 seconds or less) unavailability due to database file allocation (NTFS on a normal AWS EBS volume takes a long time to allocate a new file...)
2. sometimes there is an connectivity problem due to some application being located outside US and the MongoDb cluster being in US (something to be expected)...
3. once or twice the cluster had to reelect the primary member...