Sorry, forgot to give you the link on how to patch GF.
Here it is:
http://blogs.sun.com/oleksiys/entry/patching_glassfish_2_1_x
On May 17, 2010, at 10:54 , Oleksiy Stashok wrote:
> Dump looks fine, but one thread is suspicious [1].
> Can you pls. try to patch your GF with the latest Grizzly 1.0.33-b
> and specify additional jvm-option in the GF domain.xml [2]?
>
> WBR,
> Alexey.
>
> [1]
> "SelectorReaderThread-8080" prio=10 tid=0x00002aac1cd49800
> nid=0x6c03 runnable [0x00000000452de000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcher.preClose0(Native Method)
> at sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:41)
> at
> sun
> .nio
> .ch
> .SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:
> 684)
> - locked <0x00002aaaaeb3dfc8> (a java.lang.Object)
> at
> java
> .nio
> .channels
> .spi
> .AbstractSelectableChannel
> .implCloseChannel(AbstractSelectableChannel.java:201)
> at
> java
> .nio
> .channels
> .spi
> .AbstractInterruptibleChannel
> .close(AbstractInterruptibleChannel.java:97)
> - locked <0x00002aaaaeb3df78> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.close(SocketAdaptor.java:352)
> at
> com
> .sun
> .enterprise
> .web.connector.grizzly.SelectorThread.cancelKey(SelectorThread.java:
> 1632)
> at com.sun.enterprise.web.connector.grizzly.SelectorThread.expireIdleKeys
> (SelectorThread.java:1491)
> at
> com
> .sun
> .enterprise
> .web.connector.grizzly.SelectorThread.doSelect(SelectorThread.java:
> 1426)
> at com.sun.enterprise.web.connector.grizzly.SelectorReadThread.startEndpoint
> (SelectorReadThread.java:121)
> at
> com
> .sun
> .enterprise
> .web.connector.grizzly.SelectorThread.run(SelectorThread.java:1250)
> [2] <jvm-options>-
> Dcom.sun.enterprise.web.connector.grizzly.linger=-1</jvm-options>
>
> On May 16, 2010, at 16:41 , glassfish_at_javadesktop.org wrote:
>
>> We have a Glassfish 2.1.1 running on Java 1.6 u19 64 bit on CentOS
>> 5.4.
>> Several times a day we experience following issue: the request is
>> sent to server but no response is received. This continues usually
>> for no more than 2 minutes, then everything works as usual.
>>
>> I've used Wireshark sniffer on the client side to check what is
>> sent on the network: after the connection is established, request
>> headers are sent, then after connection timeout on client hits,
>> connection is gracefully closed.
>>
>> Also I've monitored server with VisualVM during these times and it
>> showed that request threads were idling at that moment.
>>
>> This happens even when static content (i.e. index.html) is requested.
>>
>> I've made a script that requests index.html twice a minute and
>> creates a JVM stack dump with jstack if request fails. One of these
>> dumps is attached.
>>
>> If anyone have ideas on what's causing it, please tell me.
>> [Message sent by forum member 'n0rd']
>>
>> http://forums.java.net/jive/thread.jspa?messageID=470041
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>