Hi,
I have a problem when I run Grizzly's test cases with 4 CPU.
Many test cases was failed and here is sample.
----
-------------------------------------------------------------------------------
Test set: com.sun.grizzly.DefaultControllerTest
-------------------------------------------------------------------------------
Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 14.047 sec <<< FAILURE!
testSimplePacket(com.sun.grizzly.DefaultControllerTest) Time elapsed: 5.016 sec <<< ERROR!
java.nio.channels.NotYetConnectedException
at com.sun.grizzly.TCPConnectorHandler.write(TCPConnectorHandler.java:403)
at com.sun.grizzly.utils.NonBlockingTCPIOClient.send(NonBlockingTCPIOClient.java:74)
at com.sun.grizzly.utils.NonBlockingTCPIOClient.send(NonBlockingTCPIOClient.java:70)
at com.sun.grizzly.DefaultControllerTest.testSimplePacket(DefaultControllerTest.java:83)
testSeveralPackets(com.sun.grizzly.DefaultControllerTest) Time elapsed: 8.031 sec <<< ERROR!
java.nio.channels.NotYetConnectedException
at com.sun.grizzly.TCPConnectorHandler.write(TCPConnectorHandler.java:403)
at com.sun.grizzly.utils.NonBlockingTCPIOClient.send(NonBlockingTCPIOClient.java:74)
at com.sun.grizzly.utils.NonBlockingTCPIOClient.send(NonBlockingTCPIOClient.java:70)
at com.sun.grizzly.DefaultControllerTest.testSeveralPackets(DefaultControllerTest.java:108)
----
When I reviewed it, I could know that failed test cases used NonBlockingTCPIOClient.
At first, NonBlockingTCPIOClient didn't initialize the Controller, then TCPConnectorHandler initialized the Controller lazily like this when TCPIOClient#connect() was called.
In TCPConnectorHandler.java
----
public void connect(SocketAddress remoteAddress, SocketAddress localAddress) throws IOException {
...
if( controller == null ) {
isStandalone = true;
controller = new Controller();
...
ExecutorService threadPool = new DefaultThreadPool();
controller.setThreadPool(threadPool);
...
}
...
}
----
Above, TCPConnectorHandler overwrites the thread pool, so controller becomes to have new thread pool which has only default core and pool size.
Then, tasks of standalone controller will be waited in ThreadPoolExecutor's queue. It is similar to
http://www.nabble.com/Default-thread-pool-size-issue-td23419849.html which I said.
So I think that the following is enough because the controller already creates the thread pool by autoconfigure.
In TCPConnectorHandler.java
----
public void connect(SocketAddress remoteAddress, SocketAddress localAddress) throws IOException {
...
if( controller == null ) {
isStandalone = true;
controller = new Controller();
...
//ExecutorService threadPool = new DefaultThreadPool();
//controller.setThreadPool(threadPool);
...
}
...
}
----
And I think all XXXConnectorHandlers should be modified.
Thanks.
--
Bongjae Chang