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:

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.

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:

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.

I will add up more definitions when I get more time. Please note all of the above may change a bit, as Grizzly continues to evolve to provide more functionality.

My next blog will have my experiences in designing protocol parser for IIOP using Grizzly.

--Harsha

Posted at 01:23PM Dec 20, 2007 by Harsha Godugu in Sun  |  Comments[5]