Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 326021

Summary:

Deadlock potential in TCPSelector

Product:

[Modeling] EMF

Reporter:

Eike Stepper <stepper>

Component:

cdo.net4j

Assignee:

Eike Stepper <stepper>

Status:

CLOSED FIXED

QA Contact:

Eike Stepper <stepper>

Severity:

normal

Priority:

CC:

martin.fluegge

Version:

4.0

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Patch v1 - for future reference	none

Description Eike Stepper

2010-09-23 02:06:51 EDT

When a SocketChannel is closed by the network the TCPSelector calls TCPConnector.handleRead(). There a ClosedChannelException is caught and the connector is deactivated. This deactivation causes all channels of the connector being deactivated, as well as the protocols of the channels. All these deactivations can additionally cause various listeners being called.

If any of these calls involve blocking I/O, e.g. new RequestWithConfirmation().send(), a deadlock will occur because this IO would need the TCPSelector to serve the I/O request. This can never happen because the TCPSelector is already blocked on the request.

Comment 1 Eike Stepper

2010-09-23 02:10:17 EDT

Created attachment 179431 [details]
Patch v1 - for future reference

The fix involves asynchronous deactivation of TCPConnectors and TCPAcceptors when the SocketChannel has been closed by the network.

Note: It's important to cancel the selection key immediately before scheduling the final deactivation!

Comment 2 Eike Stepper

2010-09-23 02:10:46 EDT

Committed to HEAD

Comment 3 Eike Stepper

2011-06-23 03:38:10 EDT

Available in R20110608-1407