Scott Oaks wrote:
> 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.
:-) 1.9.15a contains the fix for that issue. Are you seeing it with 1.9.15a?
>
> 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.
Yes, this is what Tomcat does as well. The idea is we rely on the back
log now for storing connection.
If you are using 1.9.16, you can probably switch off the leader/follower
by setting Controler.setLeaderFolllower to false....that sucks :-) I
will add a property so you can use it to see if that help.
Thanks
-- Jeanfrancois
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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>