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.
Thanks.
--
Bongjae Chang