[jira] Deleted: (HARMONY-6326) Socket closure does not signal threads blocked in I/O operations.

["Josh Guilfoyle (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josh Guilfoyle deleted HARMONY-6326:
------------------------------------


> Socket closure does not signal threads blocked in I/O operations.
> -----------------------------------------------------------------
>
>                 Key: HARMONY-6326
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6326
>             Project: Harmony
>          Issue Type: Bug
>         Environment: Linux 2.6.28 x86_64, as packaged by Ubuntu 9.04.
>            Reporter: Josh Guilfoyle
>            Priority: Critical
>
> Neither PlainSocketImpl#close nor the underlying OSNetworkSystem call to socketClose attempt to signal threads that may be blocking in I/O operations on the underlying file descriptor.
> Contrasting the Harmony implementation with OpenJDK 6b14 (as packaged by Ubuntu), you can see that specific attempts are made to unblock threads during the platform's close implementation on Linux (linux_close.c:NET_SocketClose).
> In testing, I have discovered that shutting down the socket's channel which is being waited upon unblocks any threads.  For instance, if the thread is blocked in a read call then a call to Socket#shutdownInput will unblock the method.
> This bug was first discovered and tested on the Harmony release as packaged with Android 1.5r3 and can be observed on both the emulator and released phones.
> For testing, I created an application which spawns a connection thread to read from a public host, and also a timer to eventually attempt to close the socket and flag the thread as canceled.  Part of the way through the download, I issue an iptables command[1] on my local machine to DROP all packets heading to the host of the download which causes the read call to block up to the socket timeout.  When the thread cancellation is triggered, it is evident both in my logging and in the prerequisite Thread#join call that the downloading thread is still blocked in the read call.  If I add calls to Socket#shutdownInput and shutdownOutput in addition to Socket#close, the blocking thread is unblocked immediately.
> I used a similar technique with Sun's JRE 1.6.0_13 which demonstrated that Sun's implementation unblocks waiting threads without the need to call shutdownInput or shutdownOutput.
> My demonstration source code can be found here: 
> http://github.com/jasta/harmony-socket-bug/tree/master
> Though the source code does use Android, the bug can be demonstrated outside that context with (I believe) any Harmony release to date.
> [1] The iptables command I used during testing:
> iptables -I OUTPUT -d 204.152.191.37 -j DROP

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