understanding netty questions

[Trustin Lee]

Hi Christian,

On Wed, Apr 29, 2009 at 11:13 PM, Christian Migowski
<chrismfwrd at gmail.com> wrote:
> is it correct that if I want to write a fully "Netty-compliant"
> Handler that can be inserted at any position in a ChannelPipeline I do
> have to have a ctx.sendUpstream(e) or ctx.sendDownstream(e) as last
> instruction in my methods that are overriden from
> SimpleChannelHandler (e.g. messageReceived or channelClosed) ?

Yes.

> If so, why isn't SimpleChannelHandler (and the single
> Up/DownstreamHandler variants) implemented so it always calls
> sendUp/Downstream after its long if/else decisions in the
> handleUp/Downstream methods?

It does call sendUpstream/Downstream at the last else block.  If a
specific event handler method is called, then it's up to the
overriding method to call sendUpstream/Downstream or not.

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

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

Plus, some handlers like SslHandler generates more than one events for
a received event.

To handle all these use cases, ctx.sendUpstream/Downstram() needs to
be called by an implementer explicitly IMHO.  I could have introduced
various variables and interfaces on a case-by-case basis (e.g.
PreprocessingHandler, PostprocessingHandler), but it is not very
scalable and the resulting API tends to look complicated.

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

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.

Thanks,

— Trustin Lee, http://gleamynode.net/