AsyncCommandCursor.getMoreLoop() holds a connection across multiple empty getMore responses without releasing it back to the pool. When a tailable cursor (e.g., change stream) receives empty batches (no new data), the method loops internally, re-issuing getMore on the same connection without ever calling connection.release().

This means each idle change stream permanently occupies a pool connection while doing no useful work. If the number of open change streams equals or exceeds maxPoolSize, the pool is fully exhausted and all other operations fail with:

MongoTimeoutException: Timed out after N ms while waiting for a connection to server

Sync cursor does not have this issue: CommandCursor.getMore() is called inside executeWithConnection, which releases the connection after each call. The loop that retries on empty batches is in doHasNext(), outside the connection scope.

Suggested Fix

Move the loop logic one above executeWithConnection.

• Remove the internal loop from getMoreLoop.
• Make it always return the result (including empty batches) to the caller.
• Move the loop logic to next(), which calls getMore() again on empty batches in a callback. This goes through executeWithConnection which releases the connection before the next checkout.

Spec Compliance: 

The find/getMore/killCursors spec does not prescribe connection management between getMores. Connection pinning is only required in load balancer mode, and the fix respects this (pinned connections are reused via executeWithConnection's pinned connection check).