Hi Bongjae,
I agree with your observations on PipelineThreadPool.
Probably best fix here will be switching to the default thread pool,
autoconfigured by Controller.
What do you think?
WBR,
Alexey.
On May 19, 2009, at 17:02 , Bongjae Chang wrote:
> Hi,
>
> I received the following error when I ran SSLConnectionTest on 4 CPUs
>
> -------------------------------------------------------------------------------
> Test set: com.sun.grizzly.SSLConnectionTest
> -------------------------------------------------------------------------------
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 53.219 sec <<< FAILURE!
> testSeveralPackets(com.sun.grizzly.SSLConnectionTest) Time elapsed:
> 41 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Handshake is not completed!
> testString: Hello. Client#0 Packet#000 latchCounter: 1 isConnected:
> false
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> com
> .sun
> .grizzly.SSLConnectionTest.testSeveralPackets(SSLConnectionTest.java:
> 187)
>
> When I debugged, I could find that this case was also failed for
> lack of thread pool's capacity. :-(
>
> See the following code:
>
> In SSLConnectionTest.java
> ---
> ...
> public static final int CLIENTS_COUNT = 10;
> ...
> public void testSeveralPackets() throws IOException {
> ...
> controller.setThreadPool(new PipelineThreadPool("", 5,
> CLIENTS_COUNT * 2, Integer.MAX_VALUE, TimeUnit.MILLISECONDS));
> }
> ---
>
> It means that min is 5 and max is 20.
>
> At first, I thought that the max which had 20 was perhaps enough for
> testing this case, but this case was failed.
>
> So, I reviewed PipelineThreadPool in order to confirm whether it
> increased threads until max size or not.
>
> See the following code:
>
> In PipelineThreadPool.java
> ---
> public void execute(Runnable task) {
> if (task == null){
> throw new IllegalArgumentException("Runnable task is
> null");
> }
>
> int ac;
> while((ac=aliveworkerCount.get())<maxPoolSize &&
> queueSize.get()>0 && running){
> if (aliveworkerCount.compareAndSet(ac, ac+1)){
> startWorker(new Worker(task, false));
> return;
> }
> }
> if (running){
> workQueue.offer(task);
> queueSize.incrementAndGet();
> }
> }
> ---
>
> Unfortunately, PipelineThreadPool allows a thread to be increased
> when queue size is only above 0.
>
> Then the sixth task will be queued without thread's increment if
> five former tasks are still running, and it will not be executed
> until the seventh task will come.
>
> Of course, I think that PipelineThreadPool is better than JDK's
> ThreadPoolExecutor in point of thread-increment-policy, but it
> should also be improved at this point.
>
>
>
> Anyway... I proposed the following patch.
>
> In SSLConnectionTest.java
> ---
> ...
> public static final int CLIENTS_COUNT = 10;
> ...
> public void testSeveralPackets() throws IOException {
> ...
> // Use the default thread pool which is configued automatically
> //controller.setThreadPool(new PipelineThreadPool("", 5,
> CLIENTS_COUNT * 2, Integer.MAX_VALUE, TimeUnit.MILLISECONDS));
> }
> ---
>
> Thanks.
>
> PS) I tested this case with my proposed thread pool(https://grizzly.dev.java.net/issues/show_bug.cgi?id=587
> ) experimentally, it works well. :-)
>
> --
> Bongjae Chang