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
> <https://grizzly.dev.java.net/source/browse/grizzly/trunk/www/images/diagrams/GrizzlyV2-HL-class-diagram.png?view=auto&rev=1177>
