Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <2125911492.1251786212819.JavaMail.jira@brutus>
Date: Mon, 31 Aug 2009 23:23:32 -0700 (PDT)
From: "Josh Guilfoyle (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-6326) Socket closure does not signal
 threads blocked in I/O operations.
In-Reply-To: <413264511.1251710372732.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Guilfoyle commented on HARMONY-6326:
-----------------------------------------

I am aware of the contribution policy and the conflict with OpenJDK's licensing.  My full statement was that I copied bits of their implementation into my test program -- solely to verify that I understood which pieces of their solution were relevant to the problem.  In this case, their usage of pthread_kill to trigger recv and other calls to return -1 with errno set to EINTR.

Regardless, I later arrived at the conclusion that in fact shutdown might be the easier solution anyway, free of licensing conflict, but formal validation is required before such a change could be introduced.

> 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
>          Components: Classlib
>    Affects Versions: 5.0M10
>         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.