Salut,
Bongjae Chang wrote:
> Hi.
>
> When I tested TCP layer recently in grizzly, I met some problems of
> Cotroller's initialization which had been not occurred before.
>
> Here is some examples
> - ControllerStateListener's onReady() was not invoked in main Controller.
> - When I tried to connect a tcp connection, maybe timeout was occurred
> and I failed to send the packet to the remote server.
> - etc...
>
> When I debugged this problem, I could know that this was the
> side-effect of "Auto-configure the number of ReaderController based on
> OS/Core or the machine" issue(svn rev.3088, issue #566).
>
> I could know that 4 ReaderControllers was initialized when I had tested
> this on 4 CPUs. Before issue #566 was committed, ReaderController was
> not used because default read-thread-count was 0.
>
> As you know, default thread pool is shared between main Controller and
> ReaderController and default thread pool's core size and max size are 5.
>
> Then if gizzly is used on 3~4 more CPUs, I think that many tasks of
> grizzly can not be executing but queueing in thread pool executor.
>
> So, I think that default thread pool size is not enough and default
> size should also be configured automatically or at least warning message
> should be logged if the minimum thread's number for initialization was
> not guaranteed.
>
> When I tested this on my thread pool which had 11 core size and 11 max
> size, I could confim no problems.
Completely agree. I think the number of threads in that case should be
core * default value. What do you think?
Thanks!
-- Jeanfrancois
>
> Thanks.
>
> --
> Bongjae Chang
>
>