Initialize frame handler's connection reference before sending header - #2017
Merged
Conversation
_frameHandler.sendHeader() can trigger an immediate reply from the broker, which the I/O thread processes as soon as it arrives. If that happens before _frameHandler.initialize(this) has run, the I/O thread dereferences a still-null AMQConnection reference (e.g. in AmqpHandler.channelRead for the Netty transport) and the connection fails with a NullPointerException wrapped as an IOException. This mostly surfaces under CI-style thread scheduling on fast/local round-trips, where the reply can outrace initialize().
acogoluegnes
force-pushed
the
init-amq-connection-earlier
branch
from
July 9, 2026 07:12
208e854 to
79fee03
Compare
acogoluegnes
marked this pull request as ready for review
July 9, 2026 08:53
Contributor
Author
|
@Mergifyio backport v5.x |
✅ Backports have been createdDetails
|
acogoluegnes
added a commit
that referenced
this pull request
Jul 9, 2026
Initialize frame handler's connection reference before sending header (backport #2017)
pull Bot
pushed a commit
to boost-mw-poc/rabbitmq_rabbitmq-java-client
that referenced
this pull request
Jul 9, 2026
A previous commit moved _frameHandler.initialize(this) before
sendHeader() in AMQConnection.start() to fix a race where the I/O
thread could dereference a still-null connection reference on a fast
broker reply. For SocketFrameHandler, though, initialize() also
starts the MainLoop thread, which begins blocking-reading the socket
right away.
That reader thread now runs concurrently with the header write. For
TLS sockets the handshake is lazy and triggered by whichever
operation touches the socket first, read or write. When the peer
certificate is rejected, the thread that loses the race can see a
generic SocketException ("Connection or outbound has closed") instead
of the real SSLHandshakeException, since the other thread already
tore down the connection. This showed up as a flaky
SslContextFactoryTest failure on CI.
Split the two concerns: FrameHandler.initialize() still runs before
sendHeader(), so the connection reference is set in time for an
early reply, but a new FrameHandler.startProcessing() hook - called
only after sendHeader() succeeds - is now responsible for actually
starting a dedicated reader thread. SocketFrameHandler moves its
connection.startMainLoop() call there. Netty ignores the new
hook, since it already read asynchronously and is not affected by
this race.
References rabbitmq#2017
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
_frameHandler.sendHeader() can trigger an immediate reply from the broker, which the I/O thread processes as soon as it arrives. If that happens before _frameHandler.initialize(this) has run, the I/O thread dereferences a still-null AMQConnection reference (e.g. in AmqpHandler.channelRead for the Netty transport) and the connection fails with a NullPointerException wrapped as an IOException. This mostly surfaces under CI-style thread scheduling on fast/local round-trips, where the reply can outrace initialize().