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).
>
> 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)
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
>