-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: Connection Management
-
None
-
None
-
Java Drivers
-
Not Needed
-
None
-
None
-
None
-
None
-
None
-
None
In TlsChannelStreamFactoryFactory.TlsChannelStream.openAsync, if any step fails after SocketChannel.open() but before selectorMonitor.register() succeeds, the opened SocketChannel is never closed.
Failure points that leak the channel:
- socketChannel.configureBlocking(false)
- socketChannel.setOption(...)
- operationContext.getTimeoutContext().getConnectTimeoutMs()
- socketChannel.connect(...)
The exception is correctly delivered to the async handler via the existing catch blocks, but the file descriptor leaks because the channel is not yet tracked by the stream or selector monitor.
Contrast with other implementations:
- AsynchronousSocketChannelStream resolves addresses before opening the channel, and the AsynchronousSocketChannel.connect() completion handler owns cleanup.
- NettyStream resolves addresses before calling bootstrap.connect(), and Netty manages the channel lifecycle.
Suggested fix:
Ensure openAsync closes the SocketChannel in catch blocks if it was opened but not yet registered. A try/finally pattern around handler.failed() should guarantee the handler is always called even if cleanup throws.
- is related to
-
JAVA-5855 TlsChannelStream use of getSocketAddresses can leak an unhandled exception
-
- In Code Review
-