Multi Selector threads in Grizzly 1.5

Default Grizzly Controller configuration uses single Selector thread for handling Channel events, it means OP_ACCEPT and OP_READ events are handled by a single Selector. For sure to process bigger number of concurrent requests - it's not enough, and we may need to spread Channels among several Selector threads.
It's very easy to do in Grizzly - Controller.setReadThreadsCount(threadNum);
It let's main (Controller) Selector thread to process only OP_ACCEPT events, and each accepted Channel will be registered for reading on a different Selector thread, taken from queue. Default Multi Selector threads implementation is working in RoundRobin manner.

Here is example, how to start Grizzly Controller with several Selector threads.
/////////////////////////////////////////////////////////////////////////////////////////////////////////////
        final ProtocolFilter readFilter = new ReadFilter();
        final ProtocolFilter echoFilter = new EchoFilter();
       
        TCPSelectorHandler selectorHandler = new TCPSelectorHandler();
        selectorHandler.setPort(PORT);
        final Controller controller = new Controller();     
        controller.setReadThreadsCount(SELECTOR_THREADS_NUM);
        controller.setSelectorHandler(selectorHandler);
       
        controller.setProtocolChainInstanceHandler(
                new DefaultProtocolChainInstanceHandler(){
            public ProtocolChain poll() {
                ProtocolChain protocolChain = protocolChains.poll();
                if (protocolChain == null){
                    protocolChain = new DefaultProtocolChain();
                    protocolChain.addFilter(readFilter);
                    protocolChain.addFilter(echoFilter);
                }
                return protocolChain;
            }
        });

        controller.start();
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

Comments:

[Trackback] A couple of blogs on Grizzly 1.5 written by the community are now starting to pop.

Posted by Jean-Francois Arcand's Blog on June 20, 2007 at 12:24 PM CEST #

[Trackback] A couple of blogs on Grizzly 1.5 written by the community are now starting to pop.

Posted by Jean-Francois Arcand's Blog on June 20, 2007 at 07:10 PM CEST #

[Trackback] A couple of blogs on Grizzly 1.5 written by the community are now starting to pop.

Posted by Jean-Francois Arcand's Blog on June 20, 2007 at 07:11 PM CEST #

I am using Grizzly 1.4 and a single selector thread in my application. Actual read is delegated to a worker thread, but still use the main selector to listen for read_interest. What I noticed is that client connection starts timeout when server is heavy loaded (> 2000 persistent connections). Then I changed the selector timeout to 500 msecs which seems to stop the connection timeout problem, but CPU is running at more than 75%. Would it help if I use controller.setReadThreadsCount( SELECTOR_THREADS_NUM); to spread Channels among several Selector threads? Will this appraoch cool down the CPU usage?

Posted by Fay on August 02, 2007 at 03:35 PM CEST #

Was the intent to construct a new ProtocolChain for every read or should poll() be modified to offer the new DefaultProtocolChain after construction? i.e. if (protocolChain == null) { ... offer(protocolChain); }

Posted by Mark on August 03, 2007 at 01:18 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
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