On 05/19/09 13:43, Jeanfrancois Arcand wrote:
> Salut,
>
> Scott Oaks wrote:
>> 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?
>
> Not yet. 1.9.15a
Oh duh; do I have any medium-term memory left? To work around
https://grizzly.dev.java.net/issues/show_bug.cgi?id=596, I had to move
to a 1.9.16 snapshot a few days ago on my V3 configuration.
For my test, I can change the connection rate and get all the desired
clients connected, so maybe in the end that's okay if the machine is
overloaded and doesn't accept a new request, rather than accepting the
new request and putting it in a really long queue. I'm not sure which I
think is better...maybe you've already decided that rejection is okay.
-Scott
> 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.
>
> That's strange. If you can send me the stack dump that will be good.
>
>
>>
>> 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.
>
> Agree. Do you know for sure 4 acceptor threads were created?
>
> Thanks!
>
> -- Jeanfrancois
>
>
>>
>> -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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>