Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 326021 - Deadlock potential in TCPSelector
Summary: Deadlock potential in TCPSelector
Status: CLOSED FIXED
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.net4j (show other bugs)
Version: 4.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eike Stepper CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-23 02:06 EDT by Eike Stepper CLA
Modified: 2011-06-23 03:38 EDT (History)
1 user (show)

See Also:


Attachments
Patch v1 - for future reference (6.07 KB, patch)
2010-09-23 02:10 EDT, Eike Stepper CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eike Stepper CLA 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 CLA 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 CLA 2010-09-23 02:10:46 EDT
Committed to HEAD
Comment 3 Eike Stepper CLA 2011-06-23 03:38:10 EDT
Available in R20110608-1407