Richard Corsale wrote:
> Ok just checking, when you said " I think it was a bug mistake" in referring to leader/follower patern , you meant to say a big mistake.
>
I means using the ^%**!@@)(*#!@! ExecutorServices ;-) I never liked it
and that's why Grizzly 1.0 do not use them :-) We got a lot of issue
since we changed to use those...
A+
-- Jeanfrancois
> Sent from my iPhone
>
> On May 19, 2009, at 2:09 PM, Scott Oaks <Scott.Oaks_at_Sun.COM> 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.
>
> 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
>
>
> ---------------------------------------------------------------------
> 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
>