-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
None
-
Affects Version/s: repo-crac
-
Component/s: core-libs
-
None
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 excercised 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.
* 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 excercised 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.
- links to
-
Review(crac)
openjdk/crac/275