Driver Pool Design
The 2.0 series of the mongodb-core module introduces a newly re-designed pool that will grow and contract based on the usage pattern. This reference outlines how the growing/shrinking of the pool works, how authentication is handled and how operations are executed.
Operations are executed using a work-queue. That means the Pool is responsible for scheduling the execution of operations on connections. The benefit of this is that one avoids slow operations holding up fast operations as long as the following holds true.
numberOfSlowOps < numberOfConnectionsInPool
This covers the basics of how the pool grows and shrinks.
Initial Pool connection
- Single connection is created and put in the
- On Successful connect, reapply any existing authentication credentials on the connection.
- If the user passed in credentials through the
Pool.connectmethod these are then applied to the connection and stored in the credentials store if successful.
- Finally the connection is moved from the
connectevent is emitted.
If the initial connection fails the server returns the associated failure event (close, error, timeout, parseError). The
Pool.connect method will also fail if the authentication fails for any existing or given credentials.
Growing the Pool
- A new operation is scheduled to be executed.
- Pool checks if there are any connections in
- No connections available in
- If we have not reached the max pool
size, the Pool creates a new connection and puts it in the
- Any credentials are applied to the new connection and if the connection process is successful, the connection is then moved to
availableConnectionsand the operation is re-scheduled for execution.
Shrinking the Pool
The pool shrinks when a connection is idle for longer than the specified socket timeout. When the connection closes it gets removed from the pool.
The Life-cycle of an operation is as follows.
- User calls the
- The operation is put at the end of the internal operations
- The internal
_executemethod is called which picks the first operation of the queue and attempts to execute it against an available connection.
- The operation is associated with a specific connection for the duration of the operation.
Pool.write options provide for a special
monitoring options that will schedule the operation at the start of the
queue array to give it priority over any other operations currently queued up. This is used to execute the
ismaster commands for things like
When a single connection fails (closes, times out) and there is an operation in flight on that connection the pool will flush out that operation as an error to the end user by calling its associated callback.
Pool.destroy method is called the pool will go into the
destroying state and will drain the reminder of the operation queue before moving to the