Thursday Dec 04, 2008

Grizzly 1.9: ExecutorService as common thread pool interface

Yesterday we've released Grizzly 1.9

One of the biggest releases we had so far. Here is the announce from Jean-Francois with the complete list, what was added to the new release.

Here I'll provide more details on new Grizzly1.9 thread pool API (actually there is nothing new for those, who uses java.util.concurrent objects). Since version 1.9 we stop to support Pipeline API and move to more standard and known ExecutorService.

So, now developer should not write thread pool wrapper, based on Pipeline, in order to use custom Thread pool implementation, but directly use own ExecutorService implementation, which will be responsible for worker threads lifecycle.

ExecutorService, as thread pool API, simplifies Grizzly integration process with existing platforms/frameworks, which may have own thread pools (based on ExecutorServices) and now are able to share the same thread pool with Grizzly.

Here is example how Grizzly thread pool could be configured and set:

Controller controller = new Controller();
ThreadPoolExecutor threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize,
                                                     keepAliveTime, unit, workQueue, new WorkerThreadFactory());
threadPool.setMaximumPoolSize(5);
controller.setThreadPool(threadPool);
........................................


private class DefaultWorkerThreadFactory implements ThreadFactory {
     public Thread newThread(Runnable r) {
            Thread thread = new WorkerThreadImpl(null, "WorkerThread", r, initialByteBufferSize);
            thread.setPriority(priority);
            return thread;
     }
}

About

oleksiys

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today