harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Regis Xu (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6431) BufferedReader.read() doesn't throw an IOException when an underlying socket is closed
Date Wed, 20 Jan 2010 05:11:55 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802673#action_12802673
] 

Regis Xu commented on HARMONY-6431:
-----------------------------------

It seems duplicate of HARMONY-6014. Some patches try to fix it, but not yet completely fixed.

> BufferedReader.read() doesn't throw an IOException when an underlying socket is closed
> --------------------------------------------------------------------------------------
>
>                 Key: HARMONY-6431
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6431
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>    Affects Versions: 5.0M12
>         Environment: linux
>            Reporter: Catherine Hope
>
> Calling BufferedReader.read() on a socket input stream will block indefinitely if the
socket is closed after the read has been called.  In this situation the RI behaviour is to
throw a java.net.SocketException (subclass of IOException).  
> The problem causes the Eclipse junit runner org.eclipse.jdt.internal.junit.runner.RemoteTestRunner
to hang on termination, as it's using a socket.close() to cause a reader thread to shutdown.
> The problem can be recreated by opening a socket, creating a BufferedReader from the
socket input stream, performing a read in another thread and then closing the socket.  The
problem is caused by the native code doing a blocking read using the system call recv.  I
can fix the problem easily using the selectRead call which (on linux) using poll to wait on
data being available or an exception occurring before calling recv.  A better performance
solution would be to use the close() to send a signal to any blocked reads on the socket,
which is what the RI does.
> This issue has been discussed previously on a deleted JIRA so I'm raising this one to
flag as a known problem.
> Testcase (don't add as it hangs):
> 	/**
>      * @tests java.io.BufferedReader#read() when the underlying socket is closed
>      * during the read
>      */
> 	public void test_read_closed_socket() throws IOException, InterruptedException {
> 	    ServerSocket ss = new ServerSocket(0);
>         Socket socket = new Socket("", ss.getLocalPort());
>         br = new BufferedReader(new InputStreamReader(socket.getInputStream()));
>         Thread rt = new Thread(){
>             public void run() {
>                 try {
>                     br.read();
>                 } catch (IOException e) {
>                     // expected behaviour
>                 }
>             }
>         };
>         rt.start();
>         // sleep isn't essential but increases likelihood of hang
>         Thread.sleep(100);
>         socket.close();
>         br.close();
>         rt.join();
>     }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message