-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
Refer to the notes in the design doc.
AC:
- CMAP test runner updates:
- unskip tests
- add handling for appName,
- implement ready test operation,
- implement timeout parameter in waitForEvent
- Note that a minPoolSize frequency check requirement was added then later removed in the spec, refer to the latest spec for the current wording
- CMAP implementation updates:
- new “state” property on the pool: “paused”, “ready”, “closed”
- closed is a final state
- ready can be set via the ready() method if the pool is paused
- paused is the initial state as well as the state after clear() is called; while the pool is paused, connections cannot be checked out or established
- API changes:
- new PoolReadyEvent interface
- has an address property
- new PoolClearedError interface
- the pool paused error, which must be a non-timeout network error when it occurs during checkout
- new ready() method that transitions pool into “ready” state and emits PoolReadyEvent
- update the checkOut() method to throw an error if the pool is paused (in addition to when it’s closed): PoolClearedError
- emit ConnectionCheckOutFailedEvent with reason=“connectionError”
- update the clear() method to clear the waitqueue and mark the pool as paused (in addition to marking all current connections as stale)
- if a pool is already paused when it is cleared, it must NOT emit a PoolClearedEvent, but the generation should still be incremented
- requests in the WaitQueue must proactively fail with errors indicating that the pool was cleared while checkout was being performed
- Per
NODE-3657, the clear method modifications described above must NOT apply in LB mode; in LB mode, clearing the pool does NOT transition the pool to paused and does NOT clear the waitqueue - In LB mode, the pool MUST still emit a PoolClearedEvent after incrementing the generation
- update the close() method to transition the pool to "closed" state
- new PoolReadyEvent interface
- Behavioral changes:
- pool must be initialized in paused state and cannot start populating minPoolSize until it is marked ready
- pool will be marked ready by SDAM after successful server checks, at which point the minpoolsize population can start and the new PoolReadyEvent should be emitted
- errors during pool population must be handled via SDAM machinery (see Application Errors section and cross reference SDAM spec); if not possible, the pool MUST be cleared
- see updated algorithm for populating connection
- new “state” property on the pool: “paused”, “ready”, “closed”
- SDAM implementation updates:
- authentication errors should result in the pool being cleared in addition to marking the server unknown (the latter is already implemented)
- when server transitions from unknown to data bearing or direct connection (see
NODE-3349), driver must ensure connection pool is set up and marked “ready”- refer to the updated algorithm onServerDescriptionChanged for marking pool ready
- clearing the connection pool for a server must be synchronized with the update to ServerDescription
- refer to the updated handleStateChangeError algorithm
- Server monitoring implementation updates:
- successful check against a server should mark pool as ready (the server should not be able to be selected if its pool is still paused)
- on error during server check, clearing the pool must be synchronized with marking the server Unknown
- see updated monitor run() command
- SDAM Testing updates:
- new SDAM CMAP prose test
- SDAM automated test updates and new test already synced but need to be unskipped (specifically, integration/minPoolSize-error)
- once everything is done, close
NODE-3657andNODE-3258
- depends on
-
NODE-4316 Sync CMAP tests for Pool Pausing
- Closed
-
NODE-3135 Provide explicit guidance on handling command errors that occur before the handshake completes during operation execution
- Closed
-
NODE-4325 Convert SDAM integration spec tests to the unified test format
- Closed
- has to be finished together with
-
NODE-3258 [CMAP] A pool must emit PoolReadyEvent before resuming the background thread
- Closed
-
NODE-3349 Connection pools must be created and eventually marked ready for any server if a direct connection is used
- Closed
-
NODE-3657 Clarify clearing behavior for load balanced pools
- Closed