On Mon, 10 Nov 2025 10:26:43 GMT, Radim Vansa <rvansa at openjdk.org> wrote:
>> The current tests for listening socket reopen have two defects:
>> * there is no thread calling accept() during the checkpoint, while normally servers would be waiting for new connections
>> * non-blocking server sockets where `Selector.select()` is used for the blocking is not exercised at all
>>
>> As a result the scenario with Selector.select() fails to even close such server socket, due to FDs not in the `EpollSelectorImpl` not being processed after the selection keys are cancelled.
>>
>> Second problem is the reopen: servers can use long-lived key with `SelectionKey.OP_ACCEPT` interest. When the server socket is closed the key is cancelled; to handle this transparently we need to make the key valid again and register it with the channel and selector.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>
> Disable selector test on Linux
I wanted to share a thought on the current implementation.
The present design affects all SelectionKey cancel operations, not just CRaC scenarios.
An alternative worth considering would be to relocate the reopen callback registration logic into `ServerSocketChannelImpl.closeBeforeCheckpoint()`. This method lives squarely within the CRaC lifecycle, making it a more natural home for such operations. Just before the channel closes, we could iterate through its associated SelectionKeys and register the necessary restoration callbacks:
// In ServerSocketChannelImpl.closeBeforeCheckpoint()
@Override
protected void closeBeforeCheckpoint() throws IOException {
// Register reopen callbacks for all associated keys before closing
forEach(key -> {
if (key instanceof SelectionKeyImpl ski && ski.isValid()) {
Consumer<Runnable> enqueue = JDKSocketResourceBase.reopenQueue(this);
if (enqueue != null) {
enqueue.accept(() -> {
// Reopen logic: revalidate key, re-register with selector, etc.
});
}
}
});
close(); // Then proceed with normal close
}
The implementation requires adjust AbstractSelectableChannel.forEach visibility to protected.
-------------
PR Comment: https://git.openjdk.org/crac/pull/275#issuecomment-3521385404