MixinPipeline, or more generally ideas for structuring pipelines.

rzo rzo at gmx.de
Mon Jan 25 15:25:24 EST 2010


Hi,

concerning handling of downstream events coming from multiple pipelines:
I suppose we should forward all of them in incoming order.

changing bootstrap is just an idea. this could also be done on the pipeline.
that is pipeline or maybe pipeline factory could implement the composite 
pattern.
(http://en.wikipedia.org/wiki/Composite_pattern)
Currently the problem that I have with pipeline is that the only  
pipeline implementation is
attached to a channel and a sink. For composite pattern to work I must 
be able to create a pipeline
which is independent of a channel and then add it to a 
DefaultChannelPipeline. I must be able to remove it from
a "channeled" pipeline and add it to another pipeline.

My idea is to have a class:

class ChannelLessPipeline implements  ChannelPipeline

That is a pipline where getChannel returns null.

and the methods:

ChannelPipeline.addxxx(ChannelPipeline)

xxx == First, Last, Before, ....

ChannelPipeline.remove(ChannelPipeline)

ChannelPipeline.getPipeline(String pipelineName)
ChannelPipeline.removePipeline(String pipelineName)

ChannelPipeline.set/getName(String)

ChannelPipeline.get("channelName/handlerName")


Using the composite will make it easier to use building blocks.
For example we could have an HttpPipeline which contains the http 
encoder/decoder/chunck... implemented within a web server project.
We could use this within a webdav pipeline. or within a jaxta pipeline.


Concerning parallel pipelines. what I mean is not parallel in the sense 
of threading but in the sense of event flow.
For this one could foresee a pipline implementation:

ParallelChannelPipeline

where the add method adds in parallel and not in sequence.

Thus a handler could always get the original ChannelBuffer by sending it 
on a parallel pipeline which has a handler which just stores it. 
(similar to a rail holding track)
If a handler requires the buffer it could access this holding track.
This could be used not just for the incoming buffer but for any message 
sent through the pipeline.

Be aware that this are just preliminary ideas.

I have implemented something similar to composite pattern within my 
async hessian patch.

org.rzo.netty.ahessian.session.MixinPipeline

take a look at and its usage. This may make things clearer.

The current implementation avoids changing the netty implementation.
However it would be "nicer" if netty provided built-in pipeline composition.

The idea, in async hessian is that whenever a client joins his session 
the client's previous pipeline is added to the pipeline of the channel.
The client can thus disconnect and reconnect multiple times and will 
always find the same "partial" pipeline (therefore state) on the server.
When the sub-pipeline is removed it is "detached" from the channel. When 
it is added to a new pipeline it is "attached" to its channel.

Concerning your proposal to subversion the hessian implementation: That 
would be great. I hope to find someone to review the code.
Do you have a proposal for the package name ?

-- Ron



On 25.01.2010 10:17, "Trustin Lee (이희승)" wrote:
> Hello Ron,
>
> If a pipeline is parallelized, how do we determine which event from
> multiple sub-pipelines should be forwarded to the next joined pipeline?
>
> What about implementing it as a separate ChannelPipeline implementation
> instead of modifying Bootstrap?
>
> Thanks for a cool idea!
> Trustin
>
> rzo wrote:
>    
>> Hello,
>>
>> with this post I would like to initiate a discussion on enhancements for
>> pipeline.
>>
>> Within my asynch hessian patch I have implemented a "MixinPipeline".
>> That is an implementation of a Pipeline, which allows to insert a
>> pipeline or remove a pipeline
>> to/from an existing pipeline.
>>
>> Another idea I had for the "WAF" example which I posted was to implement
>> "parallel" pipelines.
>> eg the ability to send an incoming buffer along multiple parallel
>> pipelines, synchronize their processing, etc.
>>
>> I think that implementing generic methods/classes for this kind of
>> operations would be great and will enable
>> to use building blocks within netty. It will also enable to use existing
>> pipeline factories from other applications by
>> just combining them. Something in the line of:
>>
>> bootstrap.addLastPipelineFactory("httpTunnelServerPipeline", ...)
>> bootstrap.addParallelPipelineFactory("httpTunnelServerPipeline",
>> "wafPipeline", ...)
>> bootstrap.addLastPipelineFactory("asycHessianServerPipeline", ...)
>>
>> What do you think ?
>>
>> -- Ron
>>
>>
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>      
>    
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20100125/9dedea21/attachment.html 


More information about the netty-users mailing list