On 05/19/09 13:24, Jeanfrancois Arcand wrote:
> Salut,
>
> Scott Oaks wrote:
>> If I've been following closely enough, I believe that grizzly 1.9.1 is
>> using a leader/follower strategy for the thread pool (and when I look
>> at stack dumps, that seems to be what is happening too...)
>
> No, only 1.9.16 support Leader/follower. 1.9.0/1 we switched from
> Pipeline to ExecutorServices (ya, the more I look at it, the more I
> think it was a bug mistake).
I meant 1.9.16; my typing finger missed the 6. But also, I thought
1.9.16 is what is in V3 now? Maybe I'm wrong about that. [Also, I guess
I have whatever Justin built us with the grizzly-config module
yesterday, so maybe I am just in very unchartered territory.]
>> Is that configurable in any way (and configurable through glassfish)?
>> When I run certain tests that make a lot of connections, I get some
>> starvation of accept calls; it seems like no one becomes the leader if
>> there is too much other work? The end result is that some new
>> connections to the server time out.
>>
>> This is on fairly big hardware, and I would typically have 4 acceptor
>> threads in previous versions. Is there some other way I can get more
>> resources into an accept call?
>
> Can you grab a Thread dump stack when this happens? I suspect the number
> of threads needs to be bumped because we recently fixed an issue where
> we ran out of thread because of the user of ReaderController (aceptor
> threads > 0)
When it happens, I see 25 HTTP threads (the amount I configured), and
they all are busy executing requests. I took a few in a row, and they
are all always still busy, though with different requests (which is what
I'd normally expect; I'm stressing the system). And I don't see the
usual acceptor thread anymore, which is why I assumed I was using the
1.9.16 version.
I guess I can bump the number of threads, but I don't want to do that
because then we'll have too many threads executing requests the rest of
the time and we'll swamp the system.
-Scott
> Thanks
>
> - Jeanfrancois
>
>
>
>
>
>>
>> -Scott
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>