Hi Alexey,
First, thanks for the prompt response.
Second, let me focus on the problem as it seems I wasn't clear enough:
Assume for a moment I don't want to touch the thread pool (we'll deal with that later on), and we agree on the size of the Kernel and Workers default pools (as you wrote below),
Why does Grizzly keep creating/renewing the threads of these 2 pools constantly and rapidly (I can see in the JConsole the "Total threads started" keeps growing although live threads remains steady) and doesn't operate them as pools (it can also be seen very easily by using the VisualVM profiling tool, even with light/moderate load runs)?
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
From: Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Sent: Wednesday, May 21, 2014 3:28 AM
To: users_at_grizzly.java.net
Subject: Re: Thread pool peculiar behavior
Oh, just realized you don't use HTTP framework... please disregard my HttpHandler-related comments.
Please try to simulate long-lasting tasks in FilterChain (one of your Filters can call Thread.sleep(N)) and you have to see worker threads to be busy.
If you're concerned about too many threads created - set the core thread pool size like:
workerPoolConfig.setCorePoolSize(0);
WBR,
Alexey.
On 20.05.14 16:50, Oleksiy Stashok wrote:
Hi Tiran,
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)
It's expected, number of kernel threads by default is number-of-cores + 1;
and the Workers "pool" (Grizzly-worker(1) to Grizzly-worker(8))!
also expected, the default number of worker threads is number-of-cores * 2;
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!
Hmm, why do you think they put on wait forever? Pls. try to implement HttpHandler, which does Thread.sleep(N) inside, this way you'll be able to make a threads snapshot and you have to see the worker thread stacktraces leading to Thread.sleep(N);
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)?
It's possible to set ExecutorService as worker or kernel thread-pool to a Transport instance directly (not via builder), but I don't really understand what is the problem with the Builder.
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)?
As I suggested, let's try to create a simple Thread.sleep(N) HttpHandler and see the thread (thread group), which will handle the request.
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...
It's expected in 2.3.12.
Thanks.
WBR,
Alexey.
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<mailto:security_at_comverse.com>. Thank You."
________________________________
"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."