users@grizzly.java.net

Thread pool peculiar behavior

From: Meltser Tiran <Tiran.Meltser_at_comverse.com>
Date: Tue, 20 May 2014 14:17:02 +0300

Good day,
As I'm new to the mailing list, I would to commend the Gizzly as a great framework!

Having said that, after working with it for 2 months I come to realize a strange behavior which I'm not able to change nor to understand...

Here are the details:

1) I'm working on a 64 bit Windows workstation, 1 CPU with 4 cores and 8GB memory, running Gizzly 2.3.12 with Java 7 VM (development machine).

2) I have observed the threads on load runs (heavy and light loads - it doesn't matter) and found out that Grizzly keeps replacing (creating new) threads for both the Selector/Kernel "pool" (grizzly-nio-kernel(1) SelectorRunner to grizzly-nio-kernel(5) SelectorRunner) and the Workers "pool" (Grizzly-worker(1) to Grizzly-worker(8))!

3) When I try and define a Workers thread pool, I see the threads group (Grizzly(1) to Grizzly(100) if the pool is targeted for 100 threads) created and put on Waiting state forever!

4) The IO strategy used is the default one (org.glassfish.grizzly.strategies.WorkerThreadIOStrategy).

The questions:

1) How can I cause Gizzly to operate its pools (Selectors/Kernel and Workers) as pools and not as factory (meaning don't create new threads and if pool and or queue are exhausted refuse new events/requests)?

2) After question 1 is solved, how can I configure Grizzly's pools and getting them to work (and not put the pool's threads on a Waiting status)?

Any help will be greatly appreciated!

P.S.
The code snippet I use for controlling the Workers thread pool is as follows:

NIOTransportBuilder transportBuilder = TCPNIOTransportBuilder.newInstance();

// Configure workers pool
ThreadPoolConfig workerPoolConfig = transportBuilder.getWorkerThreadPoolConfig();
// We shouldn't be here according to Grizzly examples, but still it turns out we do...
if (workerPoolConfig == null)
{
                workerPoolConfig = ThreadPoolConfig.defaultConfig();
                transportBuilder.setWorkerThreadPoolConfig(workerPoolConfig);
}

workerPoolConfig.setCorePoolSize(100);
workerPoolConfig.setMaxPoolSize(100);
workerPoolConfig.setQueueLimit(1000);
workerPoolConfig.setKeepAliveTime(-1,TimeUnit.HOURS);

NIOTransport transport = transportBuilder.build();

Tiran Meltser
System Architect
Global Products & Operations
Comverse - Making Your Network Smarter

T +972-3-7678381
M +972-54-5639381
Tiran.Meltser_at_comverse.com <mailto:Tiran.Meltser_at_comverse.com>
www.comverse.com<http://www.comverse.com/>
P Please think of the environment before printing this email


________________________________
"This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Inc. or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: security_at_comverse.com. Thank You."