users@grizzly.java.net

Re: Thread pool peculiar behavior

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Tue, 20 May 2014 16:50:54 -0700

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. Thank You."