« Return to Thread: [Community Feedback] Grizzly 2.0

[Community Feedback] Grizzly 2.0

by Oleksiy Stashok :: Rate this Message:

Hi,

finally I have some time to start talking about Grizzly 2.0, and gather community feedback :)

Main target for Grizzly 2.0 is improving Grizzly low level API, mostly it's grizzly-framework module.

Grizzly 1.5+ was our first attempt to move HTTP oriented Grizzly framework, which was embedded to GlassFishV2, to separate project, remove HTTP dependancy, implement client side support and finally have good performed, extensible NIO framework. IMHO we did good work, which is confirmed by number of projects Grizzly is used in. However quite often we got feedback, that our API is not clear, difficult to use (because of following backwards compatibility with existing HTTP API, our mistakes... etc), especially for smaller projects, where people don't want to spend much time on performance optimization etc, but mostly interested in getting nice, simple high level API, which will hide all the NIO complexity.

So with Grizzly 2.0, we want provide new framework API, which will count with Grizzly 1.5+ experience we got, plus we will not be limited with backwards compatibility anymore.

Here is high level class diagram of Grizzly 2.0 [1] , which I propose, but for sure all of you are more than welcome to propose changes, improvements, etc.

For those, who used Grizzly 1.5+ API, this first Grizzly 2.0 propose looks similar, however there are several changes:

1) No Controller, Transport comes

From Grizzly 1.5+ API I came to opinion, that attempts to unify protocol logic (for ex. TCP & UDP) didn't simplify things, but made them more difficult and less effective.

Controller was the part of that unification, but in practice, Controller mostly was used just to start/stop Grizzly, other Controller's API become redundant.

So instead of Controller API, which tried to unify transport logic, I propose Transport API, which is implementation of one single transport like TCP, UDP; and will have logic just for one specific transport.

2) Transport <-> SelectorHandler, SelectionKeyHandler

Transport <-> SelectorHandler have 1:1 relationship

Transport <-> SelectionKeyHandler have 1:1 relationship

In Grizzly 1.5+ SelectorHandler <-> SelectionKeyHandler has many-to-many relationship, which caused a lot of issues, we tried to fix that advising to use just 1:1 relationship without API change... in Grizzly 2.0 I propose to implement just possibility of 1:1 relationship to avoid problems we had before.

3) Multiple Selectors read threads

In Grizzly 1.5+ we implemented multiple Selectors read threads by using ReadControllers, which in its case were copies of main Controller.

ReadControllers implementation, IMHO, had several drawbacks:

a) Making Controller clones and their control.

Cloning Controller means cloning controller's artifacts like SelectorHandlers, SelectionKeyHandlers, state attributes etc. But cloning itself is not big problem, bigger problem is to keep

copies and original synchronized, which caused a lot of issues.

b) UDP?

As we talked before, Controller was an envelope over protocols, which tried to unify their usage. But "multiple Selectors read thread" implementation can work just for TCP. So,

there is no reason to have it in a Controller and perform redundant clone/copy operation with UDP artifacts, which could be there also.

For Grizzly 2.0 I propose to move "multiple read threads" logic under transport, to let them implement their own logic, how they can distribute processing Channels among several Selectors (Threads) (see NIOConnectionDistributor, SelectorHandlerRunner).

4) Improve SelectionKey events processing

In Grizzly 2.0 each transport will have EventProcessorSelector, which will be able to add/modify EventProcessor(s) chain, which will process event occurred on a channel.

For example EventProcessorSelector could decide to let FilterChain to process all incoming SelectionKey events, regardless of channel type: client or server.

Currently in Grizzly 2.0 there are 2 EventProcessor implementations: FilterChain, CallbackHandler.

These are original 2.0 changes I can propose.

Will appreciate your feedback and contributions!

Thanks.

WBR,

Alexey.

[1] https://grizzly.dev.java.net/source/browse/grizzly/trunk/www/images/diagrams/GrizzlyV2-HL-class-diagram.png?view=auto&rev=1177

« Return to Thread: [Community Feedback] Grizzly 2.0