users@glassfish.java.net

Re: glassfish 3.1.2 - GRIZZLY0023: Interrupting idle Thread: ...

From: <forums_at_java.net>
Date: Wed, 12 Dec 2012 15:59:39 -0600 (CST)

I've found the same problem, but on HTTP (non-SSL) requests.
"http-thread-pool-8000(3)" daemon prio=6 tid=0x0000000013bfd000 nid=0x16f4
runnable [0x000000001544b000] java.lang.Thread.State: RUNNABLE at
java.lang.Throwable.fillInStackTrace(Native Method) - locked
<0x00000000ecb333b8> (a java.lang.InterruptedException) at
java.lang.Throwable.(Throwable.java:181) at
java.lang.Exception.(Exception.java:29) at
java.lang.InterruptedException.(InterruptedException.java:38) at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1302)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:735)
at com.sun.corba.ee.impl.oa.poa.POAImpl.acquireLock(POAImpl.java:390) at
com.sun.corba.ee.impl.oa.poa.POAImpl.readLock(POAImpl.java:422) at
com.sun.corba.ee.impl.oa.poa.POAImpl.exit(POAImpl.java:1788) at
com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.servant_postinvoke(FullServantCacheLocalCRDImpl.java:83)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_postinvoke(CorbaClientDelegateImpl.java:582)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:261)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at
xxxpackage.__XXXClass_Remote_DynamicStub.entityAdded(xxxpackage/__XXXClass_Remote_DynamicStub.java)
GlassFish/Grizzly interrupts the request processing thread after the request
timeout expires. The interrupt should not cause fillInStackTrace to get
stuck. This looks like a JRE bug. I have not been able to reproduce this
outside of GlassFish. The timeout never happens when running GlassFish in
debug mode which made the problem difficult to reproduce. You should be able
to avoid the bug by increasing the request timeout or disabling the timeout
using -1. <network-config> <protocols> <protocol name="http-listener-1">
<http request-timeout-seconds="-1"

--
[Message sent by forum member 'dlaudams']
View Post: http://forums.java.net/node/889225