FAQ

Why Does the Driver Throw a Timeout During Server Selection?

Each driver operation requires that you choose a healthy server satisfying the server selection criteria. If you do not select an appropriate server within the server selection timeout, the driver throws a server selection timeout exception. The exception looks similar to the following:

A timeout occurred after 30000ms selecting a server using CompositeServerSelector{ Selectors = MongoDB.Driver.MongoClient+AreSessionsSupportedServerSelector, LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 }, OperationsCountServerSelector }.
Client view of cluster state is
{
    ClusterId : "1",
    Type : "Unknown",
    State : "Disconnected",
    Servers :
    [{
        ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/localhost:27017" }",
        EndPoint: "Unspecified/localhost:27017",
        ReasonChanged: "Heartbeat",
        State: "Disconnected",
        ServerVersion: ,
        TopologyVersion: ,
        Type: "Unknown",
        HeartbeatException: "<exception details>"
    }]
}.

The error message consists of multiple parts:

1. The server selection timeout (30000 ms).

2. The server selectors considered (CompositeServerSelector containing AreSessionsSupportedServerSelector, LatencyLimitingServerSelector, and OperationsCountServerSelector).

3. The driver’s current view of the cluster topology. The list of servers that the driver is aware of is a key part of this view. Each server description contains an exhaustive description of its current state including information about an endpoint, a server version, a server type, and its current health state. If the server is not heathy, HeartbeatException contains the exception from the last failed heartbeat. Analyzing the HeartbeatException on each cluster node can assist in diagnosing most server selection issues. The following heartbeat exceptions are common:

   • No connection could be made because the target machine actively refused it: The driver cannot see this cluster node. This can be because the cluster node has crashed, a firewall is preventing network traffic from reaching the cluster node or port, or some other network error is preventing traffic from being successfully routed to the cluster node.

   • Attempted to read past the end of the stream: This error happens when the driver cannot connect to the cluster nodes due to a network error, misconfigured firewall, or other network issue. To address this exception, ensure that all cluster nodes are reachable. This error commonly occurs when the client machine’s IP address is not configured in the Atlas IPs Access List, which can be found under the Network Access tab for your Atlas Project.

   • The remote certificate is invalid according to the validation procedure: This error typically indicates a TLS/SSL-related problem such as an expired/invalid certificate or an untrusted root CA. You can use tools like openssl s_client to debug TLS/SSL-related certificate problems.

Why is the Wait Queue for Acquiring a Connection to the Server Full?

This exception usually indicates a threading or concurrency problem in your application. The driver checks out a connection from the selected server’s connection pool for every read or write operation. If the connection pool is already at maxPoolSize - 100 by default - then the requesting thread blocks in a wait queue. The wait queue's default size is 5 times maxPoolSize, or 500. If the wait queue is also full, the driver throws a MongoWaitQueueFullException. The exception looks similar to the following:

MongoDB.Driver.MongoWaitQueueFullException: The wait queue for
acquiring a connection to server myServer is full.

To resolve this issue, try the following steps:

1. Tune your indexes. By improving the performance of your queries, you can reduce the time that operations take and reduce the number of concurrent connections needed for your workload.

2. If you have long-running analytical queries, you may wish to isolate them to dedicated analytics nodes using read preference tags or a hidden secondary.

3. Increase maxPoolSize to allow more simultaneous operations to a given cluster node. If your MongoDB cluster does not have sufficient resources to handle the additional connections and simultaneous workload, performance can decrease due to resource contention on the cluster nodes. Adjust this setting only with careful consideration and testing.

4. Increase waitQueueMultiple to allow more threads/tasks to block waiting for a connection. This is rarely the appropriate solution and can severely affect your application performance. Before considering changes to this setting, address the concurrency problems in your application.

Why are Certain LINQ or Builder Expressions Unsupported?

Each LINQ or Builder expression must be available in the Query API. This is not always possible for the following reasons:

1. You are attempting to use a .NET/C# feature that does not have an equivalent MongoDB representation. For example, .NET/C# and MongoDB have different semantics around collations.

2. The driver does not support a particular transformation from LINQ or Builder expression into MQL (MongoDB Query Language). This may happen because the provided query has no MQL translation or because a feature has not been implemented yet in the driver.

If you receive an Unsupported filter ... or Expression not supported ... exception message, try the following steps:

1. Try configuring the new LINQ3 provider. The LINQ3 provider contains many fixes and new features over the LINQ2 provider.

2. Use the MongoDB Analyzer to analyze your expressions.

3. Try to simplify your query where possible.

4. Provide a query as a BsonDocument or JSON string. All driver definition classes such as FilterDefinition, ProjectionDefinition, and PipelineDefinition support implicit conversion from BsonDocument or JSON string. For example, the following filters are equivalent when used in a query or aggregation:

FilterDefinition<Entity> typedFilter = Builders<Entity>.Filter.Eq(e => e.A, 1);
FilterDefinition<Entity> bsonFilter = new BsonDocument {{ "a", 1 }};
FilterDefinition<Entity> jsonFilter = "{ a : 1 }";

You can combine the raw and typed forms in the same query, as the following code demonstrates:

FilterDefinition<Entity> filter = Builders<Entity>.Filter
    .And(Builders<Entity>.Filter
        .Eq(e => e.A, 1), BsonDocument
        .Parse("{ b : 2 }"));