[CSHARP-406] Deadlock and TimeoutException when acquiring connection. Created: 03/Mar/12  Updated: 02/Apr/15  Resolved: 04/Mar/12

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 1.3.1
Fix Version/s: 1.4

Type: Bug Priority: Major - P3
Reporter: Pantyushin Roman Assignee: Robert Stam
Resolution: Done Votes: 0
Labels: connection, deadlock, driver, timeout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by CSHARP-333 1.2 Crashes our App Domain with a Exc... Closed
is duplicated by CSHARP-343 .Net Web App via C# driver reports co... Closed
is duplicated by CSHARP-344 Timeout waiting for a MongoConnection. Closed
Related
is related to CSHARP-340 Unable to connect when Primary switches Closed
is related to CSHARP-323 Timeout in background state managemen... Closed

 Description   

The following code sample causes a deadlock and then a TimeoutException with message "Timeout waiting for a MongoConnection.":

sample.cs

using System.Threading.Tasks;
using MongoDB.Bson;
using MongoDB.Driver;
 
namespace TestApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            var srv = MongoServer.Create("mongodb://localhost/?maxpoolsize=1&waitqueuetimeoutms=5000");
            var coll = srv["log"]["log"];
            Parallel.For(0, 2, i => coll.Insert(new BsonDocument("fld1", "val1")));
        }
    }
}

The core of problem is: "maxpoolsize" parameter (small value), number of iterations (more than "maxpoolsize") and the parallel execution.
I can reproduce this bug only with small values of "maxpoolsize", but I marked this bug as "Major" because I looked at the driver code and I think this deadlock can occur for any value of "maxpoolsize".



 Comments   
Comment by Robert Stam [ 04/Mar/12 ]

Made sure to release higher level locks before calling lower level methods and where possible moved time consuming operations outside of a lock.

The awesome thing about this bug report was the code that was provided to reproduce the issue. Thanks!!!

Comment by Robert Stam [ 04/Mar/12 ]

I have a solution that fixes this on my development machine but I'm going to look at it a lot more carefully before declaring it fixed. Basically the problem is that there are locks at three levels (server, serverInstance and connectionPool), and the locks at the first two levels are blocking access to the connection pool even if connections become available. The fix is to move some of the statements in the server and serverInstance level out of the corresponding lock, but I want to be really sure that doesn't create new problems.

Comment by Robert Stam [ 04/Mar/12 ]

Thanks for the sample code. I can reproduce this on my development machine as well. I am looking into it.

A safe (although perhaps not ideal) workaround for anyone encountering this issue would be to make sure that maxpoolsize is greater than or equal to the maximum number of threads that you expect to be accessing MongoDB in parallel.

Generated at Wed Feb 07 21:36:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.