Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 321484 - Buffer.startGetting does not always handle remote socket closure gracefully
Summary: Buffer.startGetting does not always handle remote socket closure gracefully
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: Caspar D. CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-02 05:30 EDT by Caspar D. CLA
Modified: 2011-06-23 03:39 EDT (History)
2 users (show)

See Also:
stepper: review+


Attachments
Patch (1.54 KB, patch)
2010-08-04 00:35 EDT, Caspar D. CLA
no flags Details | Diff
Patch v2 - ready to be committed (2.31 KB, patch)
2010-08-07 04:24 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 Caspar D. CLA 2010-08-02 05:30:51 EDT
When the remote end of a socket is closed, on the home end of the
connection that may either cause a -1 to be returned from
SocketChannel.read(ByteBuffer), or it may cause an IOException to be
thrown from that call, with the following trace:

java.io.IOException: An existing connection was forcibly closed by the remote host
  at sun.nio.ch.SocketDispatcher.read0(Native Method)
  at sun.nio.ch.SocketDispatcher.read(Unknown Source)
  at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
  at sun.nio.ch.IOUtil.read(Unknown Source)
  at sun.nio.ch.SocketChannelImpl.read(Unknown Source)...

The former situation (-1) we handle gracefully, while in the latter
case we dump the stacktrace. See net4j.buffer.Buffer.java, line 154.

It seems there is no clear specification of when the method will
exhibit the one or the other behavior; it seems to rather depend on
how the process owning the socket was terminated, and whether or not
that process ran on a different host or not. See for example:

  http://www.coderanch.com/t/207367/sockets/java/Detecting-client-disconnection-events

As far as I can tell, the -1 and the exception signal the same
situation, i.e. remote socket closure. So we should handle both in the
same way.
Comment 1 Caspar D. CLA 2010-08-04 00:35:47 EDT
Created attachment 175813 [details]
Patch
Comment 2 Eike Stepper CLA 2010-08-07 04:24:31 EDT
Created attachment 176082 [details]
Patch v2 - ready to be committed

Caspar, please clone this bug to maintenance and commit without review.

(I've added a minor change in the tests)
Comment 3 Caspar D. CLA 2010-08-08 23:36:42 EDT
Committed to HEAD
Comment 4 Eike Stepper CLA 2011-06-23 03:39:04 EDT
Available in R20110608-1407