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