understanding netty questions

[Christian Migowski]

Hi Trustin,

thanks for your answers!

On Sat, May 9, 2009 at 6:44 AM, Trustin Lee <tlee at redhat.com> wrote:

>> I can understand that not always invoking
>> the sendUp/Downstream method enables handlers to "cut" the processing
>> in a pipeline, but is this really a useful feature (for what)?
>
> A user should have control over when his handler logic is executed.
> In most cases, handler logic will be executed before the event if
> handled by next/previous handlers, but it might need to be executed
> after the event is handled by next/previous handlers:
>
>    public void channelOpen(...) {
>        try {
>            ctx.sendUpstream(e);
>        } finally {
>            // Do something.
>        }
>    }

This is, IMHO, against the Handler in an ordered pipeline (addFirst,
addLast) approach.

> Also, the handlers related with security could swallow the events
> silently to protect other handlers (ddos prevention, firewall, ...).

OK, this is indeed a convincing argument.

>> Also, the various "event methods" invoked from handleUp/Downstream in
>> SimpleChannelHandler could be made abstract so most modern IDEs would
>> generate your Handler-class with all possible "extension methods" if
>> it extends SimpleChannelHandler and you wouldn't need to look in the
>> Javadoc to lookup the method name for an event because they are quite
>> obvious :)
>
> Then you should not forget to call ctx.sendUpstream/Downstream() for
> the event types that you are not interested in because IDE does not
> know about forwarding events.  It is true that there's risk of omitted
> ctx.sendUpstream/Downstream() call once a method is overridden, but
> this is unfortunately inevitable as long as it is mandatory to call
> ctx.sendUpstream/Downstream().

Yes, i was just elaborating about why it would be useful to always
call sendUp/Downstream, but now I see there are useful usecases for
"cutting" event processing. I am just wondering if it could not be
reversed, because forwarding the event should be more common (IMHO),
so instead of forcing the common path to do some actions (calling
sendUp/Downstream) it could also be made that if you don't want to
forward the event you have to do something (eg. by calling
ChannelEvent e.disregardThisEvent() which is honored in the
auto-forward section of handleUp/DownStream).


> Although API backward compatibility should be considered carefully,
> please let me know if you have some idea to improve the API usability.
>  I'd love to listen to your idea.

OK - you asked for it ;)
a little thing: if the SimpleChannelHandler is made abstract (i.e. the
methods called from handleUp/Downstream like messageReceived(),
exceptionCaught()) the "first contact" with Netty would be a little
bit (IMHO) more user-friendly.
When I started with Mina I was told in the documentation to implement
IoHandler, so I did and had this methods messageReceived,
sessionCreated and so on in my class. I could start code right away
(bec. the names are self-explanatory) and how cool was it to see that
this methods really got invoked when something was received, a new
connection was established and so on.
Of course, this also all happens with Netty now, but you first need to
read some documentation before you can get really started. OK, maybe
this just helps the impatient (which I belong to) and could also be
solved with having a quick start guide (like "extend
SimpleChannelHandler and implement messageReceived, channelOpen and
exceptionCaught; setup your bootstrap and you're ready to go, for
further details see the user guide/ javadoc") available.

regards,
christian!