Grizzly 1.7.0

Source : http://blogs.sun.com/harshag/entry/grizzly_1_7_0_terminology

Grizzly 1.7.0 - Transport layer Details.

I've been working on integrating Grizzly transport into Glassfish ORB for quite some time now. Long since we were looking for ways and means to improve performance of CORBA request processing at the transport level in both Glassfish and JDK. That included connection management, parsing the messages, encoding and decoding messages etc. When we looked at current implementations in the open sourced field, we could not retrofit our requirements (from IIOP) into the existing frameworks. On top of this, we wanted a performance centric I/O framework. That brought up a new project called Grizzly with submodule framework using java.nio.

Here is a brief definition of Grizzly terminology:

Filter:

A filter is a component when placed in stream filters the stream. The interface tied to this is ProtocolFilter which has 2 methods execute() and postExecute() The filter can also be transformed into various forms based on the needs of the Grizzly framework user. For example, ParserProtocolFilter is designated to read certain number of available bytes from a given stream and then use a given parser implementation object to parse the read byte buffers.

Context:

A context is a place holder object to tell about the current state of event processing in Grizzly framework. Context gets to life at the beginning of selection cycle and ends in the callback handlers. Context has something called recycle() to recycle the state full information. All this happens in another interesting and important class called Controller.

Controller and Event Handling:

Controller is the one which does the very important event handling in Grizzly. Controller takes 2 approaches in handling NIO events. One is, through the callback handlers. And the other is, through filter chain. The filter chain gets executed sequentially until all the filters in the chain are (Chain of responsibility pattern) exhausted or until the current filter says to break the chain at the current instant. After this, all the filters' postExecute() method gets called in a reverse order to take certain appropriate actions while exiting the filter. Please remember that, the controller uses only one approach not both at any given time.

Callbackhandlers are very obvious from the code. The events it can handle are OP_READ, OP_WRITE, OP_CONNECT. Every time there is an event, the particular onRead(0 /onWrite() /onConnect() gets executed based on the type of the event. In order to accomplish this, one needs to first define a connector handler and callback handler. Controller uses something called SelectorHandlers and ConnectorHandlers to process events on the server side and the client side. Take a look at Controller code in Grizzly workspace for better understanding.

ConnectorHandler:

The Connector handler is the one that falls on the client side. It uses callback handlers to do the callback action based on the event types. That means, say, we are writing a client side implementation... in that we know where to contact server (host:port info.) once call to connect(..) is made, a connection is established. ConnectorHandler has specific methods to do reading and writing in both blocking and nonblocking modes.

SelectorHandler:

SelectorHandler basically runs in a separate thread. (can be configured according to onesneeds) and is a listener for a given channel. It handles / accepts events to handler new connection requests. The Controller is the guy which kicks in selector handler's selection cycle. Each selector handler upon selection,delegates the event handling like read, or write or connect with ContextTask (a thing to do) object and places the context task on a queue. Note that, ContextTask is a callable and hence gets called by a next available grizzly worker thread to do the task (callable). This is how each event is processed in Grizzly.

Pipeline (a thread pool):

Grizzly defines a default pool of threads and calls it a pipeline. Users can configure this pool implementation and it's very obvious from the code.

ProtocolChain:

ProtocolChain is a chain of filters. Can be used to read, write and parsingof a given stream from a channel.

--Harsha

-- Copied

Sharing is Caring