From owner-freebsd-java@FreeBSD.ORG Thu Jun 26 23:29:06 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 3FAD1D58; Thu, 26 Jun 2014 23:29:06 +0000 (UTC) Message-ID: <53ACACC1.4020102@FreeBSD.org> Date: Thu, 26 Jun 2014 19:29:05 -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: In-Reply-To: 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: Thu, 26 Jun 2014 23:29:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJTrKzBAAoJEHyflib82/FG98oIAIkRA57tLr+sXC/eNgIzJHDX Dvsn+5f0+JcjRLml6epK1zvCVZIU7SEVdJOMMZucxASlGD87fVPP2Ic4rcJN0EXE acNtS9nhodDaHFHyzJG6ur1IQdQoMcvtUVvWLbB5hMVO80hbRL8ZltFVfTB+m/Q+ cTZ0Sdmz7DXWbOXTbky7ff03HLULIMjdzf4RgdFH0aPaaC3WiXGiP8hVCx0mM3la li+jcKESQDMNnsthjNtgrBCICPZW76fzGlnJAH79DLVAqpZWfE0Bdj/c/GF10/Wv zB8T58o5xNVCE/Xxzz9y9j/vm64odcbDMvaETozxQJW9RZH+EDAtRRz2MtJRE9g= =Rb/b -----END PGP SIGNATURE-----