Salut,
Alan Williamson wrote:
> Jeanfrancois, here is the output of the SNAPSHOT jar file you gave me,
> including the netstat -an output.
>
> http://clients.aw20.net/whiteboard/?b=36267
>
> JStack thread dump:
>
> http://clients.aw20.net/whiteboard/?b=72819
which JDK are you using? The following stack trace looks quite strange:
> "httpWorkerThread-80-32" daemon prio=10 tid=0x095d8400 nid=0x3fa2 runnable [0xb5009000..0xb500a030]
> 89 java.lang.Thread.State: RUNNABLE
> 90 at sun.nio.ch.FileDispatcher.preClose0(Native Method)
> 91 at sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:41)
> 92 at sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:684)
> 93 - locked <0x3a614c68> (a java.lang.Object)
> 94 at java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:201)
> 95 at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
> 96 - locked <0x3a614cd8> (a java.lang.Object)
> 97 at sun.nio.ch.SocketAdaptor.close(SocketAdaptor.java:352)
> 98 at com.sun.grizzly.TCPSelectorHandler.closeChannel(TCPSelectorHandler.java:1107)
> 99 at com.sun.grizzly.BaseSelectionKeyHandler.closeChannel(BaseSelectionKeyHandler.java:265)
> 100 at com.sun.grizzly.BaseSelectionKeyHandler.cancel(BaseSelectionKeyHandler.java:213)
> 101 at com.sun.grizzly.http.SelectorThreadKeyHandler.cancel(SelectorThreadKeyHandler.java:115)
> 102 at com.sun.grizzly.filter.ReadFilter.postExecute(ReadFilter.java:229)
> 103 at com.sun.grizzly.DefaultProtocolChain.postExecuteProtocolFilter(DefaultProtocolChain.java:165)
> 104 at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
> 105 at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
> 106 at com.sun.grizzly.http.SelectorThread$1.execute(SelectorThread.java:649)
> 107 at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
> 108 at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
> 109 at com.sun.grizzly.util.WorkerThreadImpl.processTask(WorkerThreadImpl.java:309)
> 110 at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:168)
I will ping the NIO guy as it seems we have dead lock inside the VM.
>
>
> It dies very quickly, within minutes. Its not getting a huge amount of
> traffic YET, it is merely processing 1x1.gif of 49bytes each! So lots
> of small requests.
Do you know how many? Let me send you a patch that output how many
connections has been accepted and queued. Gives me 10 minutes....
A+
-- Jeanfrancois
>
>
>
> Alan Williamson wrote:
>> This morning we moved one of the Grizzly servers out from behind nginx
>> into its own world, and it died on its ass very quickly.
>>
>> A quick look around and we see we've run up against this:
>>
>> http://forums.java.net/jive/thread.jspa?messageID=273693
>>
>> Which i see is still left unresolved. This was reported in the
>> Glassfish forums but applies to us as well.
>>
>>
>> So it would appear that nginx is managing the network connections
>> infinitely better than Grizzly is on its own, because as soon as we
>> put it back behind nginx, all is well again.
>>
>> I don't want to have to put nginx in this path
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>