From owner-freebsd-java@FreeBSD.ORG Fri Jun 27 18:45:00 2014 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 80BA3F05; Fri, 27 Jun 2014 18:45:00 +0000 (UTC) Message-ID: <53ADBBAC.6060207@FreeBSD.org> Date: Fri, 27 Jun 2014 14:45:00 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dawid Weiss , freebsd-java@freebsd.org Subject: Re: A call to ServerSocketChannel.accept() cannot be interrupted. References: <53ACACC1.4020102@FreeBSD.org> In-Reply-To: <53ACACC1.4020102@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 18:45:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-26 19:29:05 -0400, Jung-uk Kim wrote: 2014? 6? 26? 19:29, Jung-uk Kim ? ?:> On 2014-06-26 17:07:13 - -0400, Dawid Weiss wrote: >> Hi there, > >> I am an Apache Lucene committer. We've encountered a problem on >> one of our test machines and I wondered if it's something known. > >> The machine is: > >> FreeBSD 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0 r250118: Tue >> Apr 30 22:06:26 UTC 2013 > >> running: > >> openjdk version "1.7.0_60" OpenJDK Runtime Environment (build >> 1.7.0_60-b19) OpenJDK 64-Bit Server VM (build 24.60-b09, mixed >> mode) > >> The problem is actually with Jetty; it creates a connector with a >> thread pool, where each thread calls a blocking >> ServerSocketChannel#accept(). Once you close the pool it >> attempts to terminate those threads and fails to do so -- and >> indeed, you can't break out from accept, not via interrupt(), not >> via closing the acquired ServerSocketChannel. The documentation >> of accept() states ClosedByInterruptException should be thrown if >> the thread is interrupted and indeed, this is the behavior on >> Linux and Windows. > >> A test case and more verbose problem description is here: >> https://issues.apache.org/jira/browse/SOLR-6204 > >>> From what I've diagnosed so far this seems to be an incomplete >> implementation problem. ServerSocketChannel attempts to signal >> the thread waiting on the socket (on Linux) via >> NativeThread.java, but in the native code (the only one I could >> find in ports) it's defined as: > >> JNIEXPORT jlong JNICALL >> Java_sun_nio_ch_NativeThread_current(JNIEnv *env, jclass cl) { >> #ifdef __linux__ return (long)pthread_self(); #else return -1; >> #endif } > >> JNIEXPORT void JNICALL >> Java_sun_nio_ch_NativeThread_signal(JNIEnv *env, jclass cl, jlong >> thread) { #ifdef __linux__ if (pthread_kill((pthread_t)thread, >> INTERRUPT_SIGNAL)) JNU_ThrowIOExceptionWithLastError(env, "Thread >> signal failed"); #endif > >> Which would indicate a no-op call. And indeed, I recompiled >> ServerSocketChannel with some debugging sysouts and the >> NativeThread.current() call returns -1. > >> Thoughts? > > Can you please try this patch? > > https://svn.redports.org/jkim/java/openjdk7/files/patch-src-solaris-native-sun-nio-ch-NativeThread.c I > just committed it. http://svnweb.freebsd.org/changeset/ports/359595 At least, it passed your test case in the PR. ;-) Thanks! Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJTrburAAoJEHyflib82/FGok8H/3Q4uTaQD76zQct7cQSkL6xH me42dXU4SgM6sH+VWBPqyi0ZMxvcYPyf4lx3tZSgM6CO9EeC8GEVBUq7w8X8ciQw xyIRwOyO3YcaQYJ3b4E6kO55ybRGbfIH+/ZTHwQ8nRVya3s1ZF6jnUKdWypz19h8 9EqqARhIf2g5LqzFR73QibhdMtDlwRe6+pXxv6WaHVijhVmy4wbVC6f8aAyxPycs cmGeVnRQa+0pqZGFsbh62HS/7yEW8PrqNC2D0OunwA/hWQwopFOc7QbW0gzTYPv/ 74j1krlSpbgxo1LATVUsvpLbVQcIwcFtj0eMfslVmCg9FtZUl52Q2sVA68FAGyU= =amiL -----END PGP SIGNATURE-----