So the scenarii are as follow, in the closeAction, when shutDownReads is called, we have 2 cases:

If write is already closed (can occur synchronously during sendCloseMessage or in an IO event) || an IO event is in the pipe that will shutdown the writes || reads are already shutdown (IO Event), then we are fine.

If !write is closed && !event in the pipe, then we have can a hang by calling this shutdown at the wrong time, we can make IO events to not be treated/received.

The exit handling in 6.4.17 was not expecting the reads to be shutdown before IO events are received/treated, so calling it is unsafe (as we can see).

The good news is that by shutting down the writes AFTER the read (the patch I sent you), that has no impact except in the context of the hang, we escape the hang.

How? The writeshutdown logic takes into account the fact that reads are already closed and initiate (if not already initiated) the full close sequence. So this call replaces part of the logic that the unreceived/treated IO event would have done.

The networking issue (JMX hang) is also resolved by this fix. When a network is down, what is really required is shutingdown the reads, whatever the location in the sequence.