Reconnecting a client automatically *without losing state*

[tsuna]

On Mon, Aug 2, 2010 at 3:19 PM, Bruno de Carvalho <kindernade at gmail.com> wrote:
> This is one of those cases where I'd ditch the PipelineFactory and
> create the pipeline manually.

Oh, yeah, didn't think about that either.  I'll do that.  Netty could
make it easier to handle disconnections.

I'm actually considering to stop using Netty's pipeline stuff
altogether and just use Netty as an async NIO library.

ChannelPipeline seems only good for simple things but it's not
suitable for anything non-trivial such as RPC servers (IMO).  Let me
take a couple of specific examples: a ChannelPipeline is mostly
static, you can change it, but it's not really designed to change
dynamically all the time.  For instance if you write an HTTP server,
you need to handle routing of requests (e.g. GET /foo should trigger
one piece of code whereas POST /bar should trigger another piece of
code).  This routing is dynamic by nature: every request needs a
different "processing pipeline".  But you can't (and actually
shouldn't) adjust the last handler of your ChannelPipeline to do this
routing.  Instead you have to do the routing manually, outside of
Netty (unless I'm seriously missing something).

Another example is: if your server is serving an RPC, and to serve
this RPC it may or may not need to send a few other RPCs to other
servers, handle their responses asynchronously and then respond to the
original RPC.  The ChannelPipeline doesn't help you at all deal with
this kind of situation, it's actually the opposite, and once again
it's something you have to do manually yourself outside of Netty.

Most of the Netty examples are too trivial to hit those problems.
They all handle every request in pretty much the same way, which is
why the static ChannelPipeline approach works well.  A lot of the
Netty-using code I've read handles the life cycle of the requests
outside of Netty, manually, everyone has their own home grown
approach.

Although I've never used Apache MINA, my understanding of it is that
with MINA you have to create an FSM (Finite State Machine) to handle
the lifecycle of a requests.  FSMs are better at doing this kind of
dynamic processing but they're cumbersome to write and manage, so
people tend to dislike them (in my experience).

I implemented Twisted's Deferred API in Java and I've been using it
with much success inside Netty to handle the dynamic lifecycle of my
requests.  Deferred allows you to easily build an FSM dynamically and
*implicitly*, meaning you don't have to explicitly define, implement,
and manage an FSM.  I'm going to open-source this code in a couple of
weeks or so.  I think an API like Deferred is good enough to entirely
replace the notion of ChannelPipeline.  It provides the same basic
features with many more advantages.
</offtopic>

-- 
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com