Chained/Nested Pipeline?

[gjwiley]

JoelPM wrote:
> 
> I'm migrating an existing service that uses HTTP to Netty and have a
> question about the best way to achieve the following scenario. In my
> current service I have a router that inspects the path and dispatches to a
> different container based on path attributes. So far I have a simple
> ChannelPipelineFactory that looks like this:
> [...]
> But I'm not sure if that's the right way to go about doing this. I saw in
> another post that it's possible to use the same pipeline for everything
> and do an 'instanceof' check on the message object to decide whether or
> not a ChannelHandler acts on the message, but that seems inefficient and
> needlessly complex when I can create a custom pipeline up front for the
> given path. Any advice on creating custom pipeline definitions for a given
> HTTP path would be greatly appreciated.
> 

I have a similar situation and started down the road to a general solution
until pragmatism intervened and I implemented more of a
magic-cookie-listener approach on a single pipeline. It works for now but I
would like to get back to a more general approach as I expect this
requirement to surface repeatedly in our environment.

Here is a straw-man design vision:

1) Instead of implementing a special pipeline type, a suitable level to
implement might be channel instead. That way, all of the infrastructure
supporting channels remains as-is.

2) So, a handler at the upstream end of a master channel (call it the
"transport channel") pipeline makes a routing decision based on some
protocol-specific criteria. At that time, it determines if it has an open
route and, if not, opens a sub-channel and connects it to a virtual endpoint
described by a protocol- or application-defined socket address type. A
pipeline factory provisions a route-specific pipeline based on properties of
the address. If the handler already has an open sub-channel for the route,
it simply forwards to the sub-channel.

3) The sink on a sub-channel is responsible for interaction with the
transport channel handler.

4) This idea can be extended to the remote end of a connection to enable
mux/demux operation. So, for instance, the "client" side of a transport
connection might provide a kind of server sub-channel that accepts
connection requests to addresses of protocol-defined type locally and
converts them into sub-channel open/connect requests down the transport
connection.

Now, Netty has the concept of a local channel and I think that could be used
either as-is or as a prototype for a general sub-channel solution. Our
protocols are Protocol Buffer-based but I think this could work for most any
protocol (even distinct protocols on each sub-channel).

I am a Netty neophile so I realize that this might be infeasible or even
downright bad Netty design. Comments?

  -=greg



-- 
View this message in context: http://n2.nabble.com/Chained-Nested-Pipeline-tp4662922p4703738.html
Sent from the Netty User Group mailing list archive at Nabble.com.