@@ -113,33 +113,32 @@ is on the other side of the planet and has a latency of 10000
113
113
milliseconds, setting the ``connectTimeoutMS`` to anything lower will
114
114
prevent the driver from ever connecting to that member.
115
115
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
+ -------------------------------------------------------------
118
118
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.
122
124
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 .
127
129
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
+ ----------------------------------------------------------
131
132
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.
134
136
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.
143
142
144
143
How Can I Prevent Sockets From Timing out Before They Become Active?
145
144
--------------------------------------------------------------------
@@ -156,18 +155,19 @@ avoid closing.
156
155
157
156
One message every 3000 milliseconds is not enough to keep the sockets
158
157
active, 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.
160
161
161
- To specify the optional ``poolSize `` setting for your ``MongoClient``, declare
162
+ To specify the optional ``maxPoolSize `` setting for your ``MongoClient``, declare
162
163
it in the ``options`` object of the constructor as follows:
163
164
164
165
.. code-block:: javascript
165
166
166
167
const client = new MongoClient(uri, {
167
- poolSize : <integer value>,
168
+ maxPoolSize : <integer value>,
168
169
});
169
170
170
-
171
171
What Does a Value of "0" mean for "connectTimeoutMS" and "socketTimeoutMS"?
172
172
---------------------------------------------------------------------------
173
173
@@ -245,7 +245,7 @@ How Can I Prevent a Slow Operation From Delaying Other Operations?
245
245
------------------------------------------------------------------
246
246
247
247
A 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
249
249
:ref:`connection options <node-connection-options>`.
250
250
MongoDB is synchronous and uses a single execution thread per socket,
251
251
meaning 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
256
256
other, faster operations.
257
257
258
258
.. 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.
262
262
263
263
To create a separate connection pool, instantiate another ``MongoClient``
264
264
call the ``connect()`` method on it. See the following example for the
0 commit comments