Re: http keep-alive

I think is the continuousExecution feature I've ported from Grizzly 1.0
that is causing problem. I did test it (and ran several perf benchmark)
but it seems there is still a bug . Mainly, there is no longer bytes
availables and the ProtocolChain needs to abort it execution, which is
clear it is not working right now.

Re: http keep-alive

I have now tried the fix when the server was under load, but the
problem remains.

After a few minutes, I have lots of threads waiting in
sun.nio.ch.KQueueArrayWrapper.kevent0, the server feels very sluggish
and then runs out of memory (java.lang.OutOfMemoryError). There is
approx. 170 keep-alive connections at this time of the day.

Re: http keep-alive

Hi Peter,

sorry forgot to reply. I've fixed it on the trunk and ported the fix to
the 1.6.0 branch as well. Can you try it and let us know?

Thanks

-- Jeanfrancois

Peter Speck wrote:

> On 03/09/2007, at 17:23, Oleksiy Stashok wrote:
>
>> please try latest Grizzly 1.6.0 sources, I've fixed one possible
>> problem, hope it will help.
>
>
> I have now tried the fix when the server was under load, but the problem
> remains.
>
> After a few minutes, I have lots of threads waiting in
> sun.nio.ch.KQueueArrayWrapper.kevent0, the server feels very sluggish
> and then runs out of memory (java.lang.OutOfMemoryError). There is
> approx. 170 keep-alive connections at this time of the day.
>
> When I test the server using Apache Bench, the problem doesn't occur.
>
> ----
> - Peter Speck
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>

Re: http keep-alive

Peter Speck wrote:
> On 05/09/2007, at 16:58, Jeanfrancois Arcand wrote:
>
>> sorry forgot to reply. I've fixed it on the trunk and ported the fix
>> to the 1.6.0 branch as well. Can you try it and let us know?
>
> I've checked out tip-of-trunk and tested it, but I still get tons of
> threads waiting in sun.nio.ch.KQueueArrayWrapper.kevent0
> Is there any kind of debug log I could enable to pinpoint it?

This is the same stack trace as before, right? DO you have an idea of
what the http request looks like? I've tested with telnet and browser
and wasn't able to reproduce the problem after my changes.