Re: [Community Feedback] Grizzly 2.0

Oleksiy Stashok wrote:

Hi,

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

Hi Alexey, 

Thanks for the write up and the class diagrams.  The new that got my attention are: Memory manager,  ExceptionHandler, and the eventProcessor. They seem to be a good start for Grizzly 2.0

 Here is my input inlined based on the context  :-)

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.

I specifically tend to give very meaningful & intuitive names for any new classes or interfaces. I agree with you on the existing controller and it's removal.  The new "Transport" seems a good candidate. But, could the name be 'GrizzlyTransportManager' ?  A typical transport is just a vehicle to provide a mode of transportation (of bits). So, the abstraction 'Transport' here with start, stop, pause does not really click with other developers when they encounter this class or it's api.

I think, you meant,  an UDPTransport,  HTTPTransport, TCPTransport  etc... based on the protocol.   If thats the case, we need reconsider the name of the transport class here.
I know about the SelectorHanlderRunner  in Grizzly currently. I think this is the class that should have start, stop, pause ..calls basically to control the listening / selection activity on a per thread basis. 

I also think that,  the proposed transport needs a split with a another level of abstraction for Socket side settings/operations like host, port and bind etc. Basically, the proposed transport  (to me)  looks like... a configurator, context holder, socket binder.

Question: What's the relation b/w this transport to SelectorHandler (nio.Selector) Who creates it and who owns it. 

2) Transport <-> SelectorHandler, SelectionKeyHandler

Transport <-> SelectorHandler have 1:1 relationship

Transport <-> SelectionKeyHandler have 1:1 relationship

Agree. No comments.  :-)

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.

I agree with drawbacks. I didn't like the cloning in the first place. :-)

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).

What does a NIOConnectionDistributor do ?  The name tells me that, it would help in registering and deregistering a channel with a given selector. But, then it's relation should be with a Selector/SelectorRunner than with the transport here. Basically, I think, I'm missing some relationships in the class diagram here.

4) Improve SelectionKey events processing

We need to discuss this (=how we process events) at length; since we are starting afresh, in this area for Grizzly 2.0  

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.

The challenge to me was, the way controller was executing the filter chain in the current Grizzly.   The new proposal looks good to me.  (lines: regardless of channel type: client or server).  Does that mean, say if my app. is interested in a particular event, and uses a callbackhandler; can it still executes filters too? Is the otherway possible too?
Can we also unify the callbackHandler mechanism that is used now only on the client-side.  ?  

I note the  exceptionHandlers in the transport. Looks like a very good idea. But, they should be in the SelectorHandler  / or in the Context itself. Isn't it?

that's all I've for now.

thanks,
Harsha

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