dev@grizzly.java.net

Re: some test on 1.9.16 def threadpool :)

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Wed, 24 Jun 2009 15:29:34 +0200

Hi Rama (threadpool lover) :))

which Grizzly version are you using?

I've just tried Grizzly 1.9.17-SNAPSHOT, seems it's working fine, can
you pls. give it a try?

Just want to note, that we've added thread-pool autoconfiguration
logic to avoid unexpected locks during execution, which could mean,
that original threadpool configuration could be overwritten by
Grizzly. You can disable autoconfiguration by calling
Controller.setAutoConfigure(false);

Why locks may occur?
Originally we used 2 types of threads: Selector threads and Worker
threads. Selector threads were used for polling java.nio.Selector for
I/O events, and Worker threads were responsible for processing single
I/O event, which occurred on concrete channel.
Recently we moved to Leader/Follower strategy in processing I/O
events, because of performance advantages. Using Leader/Follower
strategy means that Worker threads (Worker thread pool) will be used
not just for processing I/O event on concrete channels, but also for
polling java.nio.Selector. So, if we will not provide big enough
Worker thread pool, it could lead us to situation, where we can not
even start required number of "java.nio.Selector polling threads",
which will block the entire framework.

Current autoconfiguration checks the thread pool minimum threads
number to be more than:
cpuNumber * bindingsNumber (number of SelectorHandlers) * 2


Hope this info will help.

WBR,
Alexey.

On Jun 24, 2009, at 11:28 , rama.rama_at_tiscali.it wrote:

> yes, i know, everyone is tired by my consideration on threadpool :)
>
>
>
> let's see this example
>
> ----------
> public class Suspend {
>
> public
> Suspend() {
> GrizzlyWebServer gws = new GrizzlyWebServer();
>
>
> gws.addGrizzlyAdapter(new GrizzlyAdapter() {
>
> public void service(final GrizzlyRequest grizzlyRequest, final
> GrizzlyResponse grizzlyResponse) {
> System.out.
> println("I AM "+Thread.currentThread().getName()+" HELLO");
>
> try {
>
> grizzlyResponse.getWriter().println("hi");
> }
> catch (Exception e) {
>
> }
> }
>
> },new String[]{"/"});
> gws.setMaxThreads(64);
>
> gws.getSelectorThread().setDisplayConfiguration(true);
>
> try {
>
> gws.start();
> } catch (IOException e) {
>
> e.printStackTrace();
> }
> }
>
> public static void main
> (String args[]) {
> new Suspend();
> }
> }
> ----------
> On start up
> i get
> Thread Pool: StatsThreadPool[name=http, min-threads=5, max-
> threads=64, max-queue-size=2147483647, is-shutdown=false, port=8080]
>
>
> Cool :)
>
> Then, i do some refresh on browser, and i get
>
> -------------------------------------------------------------------------------------
>
> I AM http8080-WorkerThread(2) HELLO
> I AM http8080-WorkerThread(5) HELLO
>
> I AM http8080-WorkerThread(2) HELLO
> I AM http8080-WorkerThread(5) HELLO
>
> I AM http8080-WorkerThread(2) HELLO
> I AM http8080-WorkerThread(5) HELLO
>
> I AM http8080-WorkerThread(2) HELLO
>
> Perfect
>
>
> Now, lest' try with
> something of different...
>
> -------------------------------------------------------------------------------------
>
> sudo ab -n 100 -c 10 http://192.168.2.143:8080/
>
> Server Software:
>
> Server Hostname: 192.168.2.143
> Server Port: 8080
>
>
> Document Path: /
> Document Length: 4 bytes
>
> Concurrency
> Level: 10
> Time taken for tests: 0.032 seconds
> Complete
> requests: 100
> Failed requests: 0
> Write errors: 0
>
> Total transferred: 7900 bytes
> HTML transferred: 400 bytes
>
> Requests per second: 3108.39 [#/sec] (mean)
> Time per request:
> 3.217 [ms] (mean)
> Time per request: 0.322 [ms] (mean, across all
> concurrent requests)
> Transfer rate: 239.81 [Kbytes/sec]
> received
>
> -------------------------------------------------------------------------------------
>
>
> The request are issued perfecty.
>
> The issue is that i expect to have
> 10 threads running (concurrency 10) maybe a couple more...
> but gws
> spawn 64 thread.
> If i put gws.setMaxThreads(64); to 100 it will spawn
> 100 :)
> This is quite strange, someone can give to me some
> clarification?
> At this point using the new threadpool doesn't have any
> advantage rather than using fixedthreadpool (that was even a bit
> faster)
> since even under a relative low concurrency level, it's unable
> to spawn a limited number of threads.
>
>
> best regards
> Rama (the lover of
> threadpool)
>
>
>
>
>
>
>
>
> Con Tutto Incluso chiami e navighi senza limiti a soli 14,95 euro al
> mese. Gratis la Sim Tiscali Mobile con 50 euro di traffico!
> L’offerta è valida solo se attivi entro il 25/06/09
>
> http://abbonati.tiscali.it/promo/tuttoincluso/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>