[DRIVERS-2223] Update pool-checkout-returned-connection-maxConnecting.yml to work with different pool implementations. Created: 01/Mar/22 Updated: 27/Jun/22 |
|
| Status: | Backlog |
| Project: | Drivers |
| Component/s: | CMAP |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Unknown |
| Reporter: | Matt Dale | Assignee: | Matt Dale |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Epic Link: | DRIVERS-781 | ||||||||
| Driver Changes: | Not Needed | ||||||||
| Description |
SummaryDepending on the implementation details of the connection pool WaitQueue, it's possible for the sequence of operations described in pool-checkout-returned-connection-maxConnecting.yml to result in either 3 or 4 created connections. The sequence of events expected by the test appears to be:
Here's a timing diagram of that sequence. The "N" indicates a check-out causing a new connection to start establishment. The numbers are the connection IDs and indicate which new connection is delivered to which waiting check-out. Note that connection 1 is the connection created by the main thread in step #1 above.
However, the CMAP spec description of WaitQueue delegates specific implementation to the drivers as long as it satisfies the described behaviors. Specifically, the driver must deliver available connections to waiting check-out requests in the order that they came in:
This is where the Go driver behavior deviates from most other drivers. In the Go driver, all connections are established in background threads, so a check-out request can cause a new connection to start establishment, then have a connection delivered to it by a check-in. The connection establishment continues in the background, and the new connection is delivered to the first waiting check-out when it's ready. That can create the following sequence which is also valid, but fails the test:
Here's a timing diagram of that sequence. The "N" indicates a check-out causing a new connection to start establishment. The numbers are the connection IDs and indicate which new connection is delivered to which waiting check-out. Note that connection 1 is the connection created by the main thread in step #1 above.
MotivationWho is the affected end user?Drivers devs implementing maxConnecting and trying to run CMAP spec tests. How does this affect the end user?There is no known end user impact. How likely is it that this problem or use case will occur?The 2nd described behavior currently happens reliably in the Go driver. The impact to other drivers is unknown, but it seems like most other drivers' connection pool implementations work with the existing test. The impact may increase as other drivers make connection pool implementation changes as part of CSOT. If the problem does occur, what are the consequences and how severe are they?The CMAP spec tests may fail. There is no known end user impact. Is this issue urgent?No. Is this ticket required by a downstream team?No. Is this ticket only for tests?Yes. |