@@ -113,33 +113,32 @@ is on the other side of the planet and has a latency of 10000
113113milliseconds, setting the ``connectTimeoutMS`` to anything lower will
114114prevent the driver from ever connecting to that member.
115115
116- Should I Use "socketTimeoutMS" as a Way of Preventing Long- Running Operations From Slowing Down the Server ?
117- -------------------------------------------------------------------------------------------------------------
116+ What Happens to Running Operations If the Client Disconnects ?
117+ -------------------------------------------------------------
118118
119- No, you should **not** use ``socketTimeoutMS`` to end operations that
120- may run for too long and slow down the application. Attempting to do so
121- may not achieve the intended result.
119+ Starting in {+mdb-server+} version 4.2, the server terminates
120+ running operations such as aggregations and find operations if the
121+ client disconnects. To see a full list of operations affected by this
122+ behavior, see the :manual:`Server version 4.2 release notes
123+ </release-notes/4.2/#client-disconnection>` in the Server manual.
122124
123- Closing the socket causes a reconnect of the driver's connection pool,
124- introducing latency to any other queued up operations. Chronically slow
125- operations will, therefore, cause a large number of reconnect requests,
126- negatively impacting throughput and performance .
125+ Other operations, such as write operations, continue to run on the
126+ {+mdb-server+} even if the client disconnects. This behavior can cause data
127+ inconsistencies if your application retries the operation after the
128+ client disconnects .
127129
128- Also, closing the socket does not terminate the operation; it will
129- continue to run on the MongoDB server, which could cause data
130- inconsistencies if the application retries the operation on failure.
130+ How Can I Confirm That the Driver Closed Unusable Sockets?
131+ ----------------------------------------------------------
131132
132- However, there are important use cases for ``socketTimeoutMS`` -
133- consider the following cases:
133+ If you experience unexpected network behavior or if a MongoDB process
134+ fails with an error, you may not receive confirmation that the
135+ driver correctly closed the corresponding socket.
134136
135- - A MongoDB process erroring out
136- - A misconfigured firewall causing a socket connection without sending a ``FIN`` packet
137-
138- In those cases, there is no way to detect that the connection has died.
139- Setting the ``socketTimeoutMS`` is essential to ensure that the sockets
140- are closed correctly. A good rule of thumb is to set ``socketTimeoutMS``
141- to two to three times the length of the slowest operation that runs
142- through the driver.
137+ To make sure that the driver correctly closes the socket in these cases,
138+ set the ``socketTimeoutMS`` option. When a MongoDB process times out, the driver
139+ will close the socket. We recommend that you select a value
140+ for ``socketTimeoutMS`` that is two to three times as long as the
141+ expected duration of the slowest operation that your application executes.
143142
144143How Can I Prevent Sockets From Timing out Before They Become Active?
145144--------------------------------------------------------------------
@@ -156,18 +155,19 @@ avoid closing.
156155
157156One message every 3000 milliseconds is not enough to keep the sockets
158157active, so several of the sockets will time out after 5000 milliseconds.
159- Reduce the ``poolSize`` in the connection settings to fix the problem.
158+ To avoid excessive socket timeouts, reduce the number of connections
159+ that the driver can maintain in the connection pool by specifying the
160+ ``maxPoolSize`` option.
160161
161- To specify the optional ``poolSize `` setting for your ``MongoClient``, declare
162+ To specify the optional ``maxPoolSize `` setting for your ``MongoClient``, declare
162163it in the ``options`` object of the constructor as follows:
163164
164165.. code-block:: javascript
165166
166167 const client = new MongoClient(uri, {
167- poolSize : <integer value>,
168+ maxPoolSize : <integer value>,
168169 });
169170
170-
171171What Does a Value of "0" mean for "connectTimeoutMS" and "socketTimeoutMS"?
172172---------------------------------------------------------------------------
173173
@@ -245,7 +245,7 @@ How Can I Prevent a Slow Operation From Delaying Other Operations?
245245------------------------------------------------------------------
246246
247247A slow operation may delay your other operations that occur after it, if
248- the ``poolSize `` has not been set in the
248+ the ``maxPoolSize `` has not been set in the
249249:ref:`connection options <node-connection-options>`.
250250MongoDB is synchronous and uses a single execution thread per socket,
251251meaning that MongoDB will execute one single operation per socket at any
@@ -256,9 +256,9 @@ a separate connection pool for the slow operation, isolating it from
256256other, faster operations.
257257
258258.. note::
259- If the number of operations is greater than the set ``poolSize`` and
260- a slow operation occurs, subsequent operations will be delayed.
261-
259+ If the number of operations is greater than the value of the
260+ ``maxPoolSize`` option and a slow operation occurs, subsequent
261+ operations will be delayed.
262262
263263To create a separate connection pool, instantiate another ``MongoClient``
264264call the ``connect()`` method on it. See the following example for the
0 commit comments