Jean-Francois Arcand's Blog

Understanding Grizzly part II: Adding your own thread pool

When embedding Grizzly, being able to replace the default thread pool with an external one is important. Fortunately, this is simple to do. Before going into the details,in Grizzly a thread pool is named a Pipeline. A pipeline is just a wrapper around a thread pool, with some extra methods to collect statistics. The most important methods are execute and waitForIoTask.

The default Grizzly framework ship with two thread pool, one based on a synchronized LinkedList (LinkedListPipeline), one based on Java 5 concurrent API(ThreadPoolExecutorPipeline). By default,Grizzly uses the LinkedListPipeline because this very simple thread pool perform much better than any Java 5 concurrent based API. I know it sound strange, but all the benchmarks we did demonstrated that a simple synchronize/wait/notify thread pool always gives better result. Doesn't agree? I will change the default Pipeline the day I will see a Java 5 concurrent based performing better than the LinkedListPipeline :-) :-)

Back to work, configuring the Pipeline is very simple. To demonstrate it, I will re-use the example I've used in part I:

     63         SelectorThread selectorThread = new SelectorThread();
     64         selectorThread.setPort(port);
     65         selectorThread.setAdapter(new StaticResourcesAdapter());
    66        selectorThread.setProcessorPipeline(new LinkedListPipeline());
     67         selectorThread.initEndpoint();
     68         selectorThread.startEndpoint();

By default, Grizzly uses the processor pipeline for processing the request(reading bytes) and the response(writing bytes). For synchronous requests, executing the read and the write operations on the same thread proved to be the best configuration. What about asynchronous requests? Depending on what you are doing with Grizzly, you might want to use a thread for read operations, and a different one for write operations. You may want to use the same thread pool or use two separate one. This is simple to do:

     63         SelectorThread selectorThread = new SelectorThread();
     64         selectorThread.setPort(port);
     65         selectorThread.setAdapter(new StaticResourcesAdapter());
     66         selectorThread.setProcessorPipeline(new LinkedListPipeline());
     67        selectorThread.setReadPipeline(new LinkedListPipeline());
     68         selectorThread.initEndpoint();
     69         selectorThread.startEndpoint();

With the above configuration, the read operations will be executed using one thread pool, and write operations using a different thread pool.

OK next time I will describe how to extends Grizzly to implement any tcp protocol via the StreamAlgorithm interface.

technorati: grizzly web server embedded

Comments

• Salut JF,

  Encore des articles fort interessants :-)

  Une question hors sujet pour toi:

  Je cherche solution pour mettre des nouveaux connecteurs à glassfish ... par exemple, un connecteur UDP (DNS&DHCP) qui réceptione des infos et dialogue avec du JMS, quel est le moyen d'intégration que tu conseillerais ? Aurais-tu un exemple en ligne qqe part ?

  J'ai débuté avec un composant JMX, je suis pas persuadé que ce soit la meilleure façon (difficulté de persistence de son état entre deux démarages, initialisation hors Java EE de JMS, portabilité ...). Et JCA me semble surdimensioné et "indigeste" ...

  Toute suggestion est la bien venue.

  A++
  JB

  Posted by: bjb on December 11, 2006 at 03:25 PM

• Salut :-) Si JMX ne fonction pas comme tu le veux, Grizzly est probablement une bonne solution. Grizzly ne supporte pas encore UPD mais je suis tres interesse a toute collaboration. Tout ce qui manque est un UDPSelectorThread qui va implementer le DatagramChannel.open() et enregistre le DatagramSocket au Selector. Ca ne devrait pas etre trop complique :-) Envois moi plus de details par courriels si ca t'interesse. -- Jeanfrancois

  Posted by: jfarcand on December 11, 2006 at 06:33 PM

This work is licensed under a Creative Commons License.