users@glassfish.java.net

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

From: Harshad Vilekar <harshad.vilekar_at_oracle.com>
Date: Wed, 12 Dec 2012 16:04:19 -0800

This looks related to the issue with
com.sun.corba.ee.impl.oa.poa.POAImpl.acquireLock(). The issue reported
in http://java.net/jira/browse/GLASSFISH-16217 is fixed.

Harshad

On 12/12/2012 02:51 PM, forums_at_java.net wrote:
> I've run into the same problem, but with HTTP (non-SSL) requests:
> "http-thread-pool-8000(3)" daemon prio=6 tid=0x0000000013bfd000
> nid=0x16f4
> runnable [0x000000001544b000] java.lang.Thread.State: RUNNABLE at
> http://java.net/jira/browse/GLASSFISH-16217
> 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
> xxxx.__XXXX_Remote_DynamicStub.entityAdded(xxxx__XXXX_Remote_DynamicStub.java)
>
> GlassFish/Grizzly interrupts the request processing thread after a
> timeout
> expires. The interrupt should not cause fillInStackTrace to get stuck.
> This
> looks like a JRE bug, but I have not yet been able to reproduce this
> outside
> of GlassFish. The interrupts are not sent when running in debug mode
> which
> make this problem more difficult to reproduce/test. You can avoid this
> bug by
> increasing the request timeout or disable it 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
>
>