> 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.
There is property already:
com.sun.grizzly.disableLeaderFollower
WBR,
Alexey.
>
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>