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
