FAQ
On this page
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:
The server selection timeout (30000 ms).
The server selectors considered (
CompositeServerSelector
containingAreSessionsSupportedServerSelector
,LatencyLimitingServerSelector
, andOperationsCountServerSelector
).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 theHeartbeatException
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 likeopenssl 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:
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.
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.
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.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:
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.
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:
Try configuring the new LINQ3 provider. The LINQ3 provider contains many fixes and new features over the LINQ2 provider.
Use the MongoDB Analyzer to analyze your expressions.
Try to simplify your query where possible.
Provide a query as a
BsonDocument
or JSON string. All driver definition classes such asFilterDefinition
,ProjectionDefinition
, andPipelineDefinition
support implicit conversion fromBsonDocument
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 }";
Note
If you use BsonDocument
or JSON string, then BsonClassMap,
BSON serialization attributes, and serialization conventions are not
taken into account in the Query API. Field names must match the
names and casing as stored by the server. For example, when referencing
the _id
field, you must refer to it using _id
in
BsonDocument
or JSON string definitions. Similarly, if a document
has a field FirstName
annotated with [BsonElement("first_name")]
, you
must refer to it as first_name
in BsonDocument
or JSON string
definitions.
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 }"));