how to close connection? (If use documentDB, it is necessary)

[justintien]

I use Azure DocumentDB,
and use php 7.1 + mongo-php-library

DocumentDB seems auto disconnect when some time...
and php use connection pool by default (mongodb driver),
and no close function,
resulting in many CLOSE_WAIT (bad connection pool),
so next user to connection will be db error,
I changed options serverSelectionTryOnce to false,
solved db error issue, but it slow to connection db (retry),

so I don't know best solution...

[jmikola]

I use Azure DocumentDB, and use php 7.1 + mongo-php-library

For starters, neither this library nor the extension officially support DocumentDB. All marketing claims aside, it looks like there are numerous incompatibilities being reported in the comments of this article.

php use connection pool by default (mongodb driver),

To clarify, the PHP driver does not implement connection pooling. It implements persistent sockets as described in this documentation.

I changed options serverSelectionTryOnce to false, solved db error issue, but it slow to connection db (retry),

The PHP driver provides two modes for server selection. The default behavior tries to select a server once and throws an exception immediately on an error (essentially "fail fast" behavior). By disabling serverSelectionTryOnce, the driver will instead block for up to serverSelectionTimeoutMS milliseconds while it attempts to find a suitable server. During this time, the driver may reestablish connections, wait for a replica set failover, etc. The default timeout is 30 seconds, although you can configure the driver to use a shorter timeout. I've linked to specific references above, but this is described in the cross-driver server selection specification. This blog post on the subject may be more approachable than the spec document.

If DocumentDB is terminating sockets on its own (and that cannot be changed), the driver must restablish those connections on its own. You can either use serverSelectionTryOnce=true to allow for fast failures and manually decide to retry operations or handle errors, or use serverSelectionTryOnce=false, configure serverSelectionTimeoutMS to your liking, and allow requests to wait for dropped connections to be restablished during server selection.

As a side note, the issue you're describing is related to recent issues opened by users running MongoDB on Amazon EC2 where a firewall service was dropping open sockets after some time.

[justintien]

@jmikola
I has tried the serverSelectionTryOnce: true, it will throw a db error (No suitable servers found),
Or serverSelectionTryOnce: false, it can solve db error, but the try selection server slow ... (maybe 4-6 second)
I also have add serverSelectionTimeoutMS: 1000,

So, can I how to solve the try server selection to fast?

This problem comes from too many CLOSE_WAIT.

I have trace the reason ....
When many request, and apache will ESTABLISHED (netstat -antp)
And no request for some time (guess documentDB to close connection),
Apache the netstat will change state to CLOSE_WAIT,
Too many CLOSE_WAIT (usually 10 number of count),
so next request, it can't found db server, and try selection (if serverSelectionTryOnce: false),
until find out server (need to a lot time)

[jmikola]

Or serverSelectionTryOnce: false, it can solve db error, but the try selection server slow ... (maybe 4-6 second)

If the driver encounters a network error while attempting to monitor servers in the topology, a delay could be introduced by cooldownMS, which is 5 seconds and not configurable. Note that this only applies for network errors encountered during internal monitoring (i.e. isMaster commands). If we encounter a network error on a user-initiation operation (e.g. query, write operation), you'll see an exception and the driver will mark the server's status as "Unknown", which will make it ineligible for selection until the next topology scan and update its status.

There are a few knobs available for configuration:

• heartbeatFrequencyMS is the period after which the driver considers its view of the topology stale and requires all known servers to be re-scanned before selecting a server for an operation. This defaults to 60 seconds in the PHP driver and can be tuned as low as 500ms (i.e. minHeartbeatFrequencyMS).
• socketCheckIntervalMS is the period after which the driver will require an isMaster command to be issued on a socket before it can be used for an operation, assuming it has not previously been used within that timeframe. This defaults to 5 seconds.

The algorithm used for selecting a server is documented under Single-threaded Server Selection in our server selection spec.

I also have add serverSelectionTimeoutMS: 1000,

What was the observed behavior of using a selection timeout of one second?

So, can I how to solve the try server selection to fast?

I don't understand this question as written. Please rephrase if possible.

I have trace the reason ....

Unfortunately, the behavior you're seeing is expected. In mongodb/mongo-php-driver#564, users encountered a similar issue where a firewall was responsible for closing active connections between the driver and server after a set time. Short of modifying the extension on their own to disable connection persistence (which I also discuss in mongodb/mongo-php-driver#593), CDRIVER-2075 may alleviate the problem by having libmongoc automatically retry isMaster commands once to allow immediate recovery of a dropped connection during monitoring.

[jmikola]

Closing this due to inactivity. The last comment concluded that there was no driver bug evident here. Feel free to follow up if there are new developments.

I'll note that CDRIVER-2075 (retrying isMaster commands) was resolved in libmongoc 1.7.0, which is included in ext-mongodb 1.3.0.