I have proposed this design by email several weeks ago. I received comment from Brock. I guess your guys are very busy, so I think I'd better create this JIRA, and put slides and patch here to explain it more clearly.
Following is the design from previous email, I will attach slides later.
From: "Wang, Yongkun" <email@example.com>
Date: Wed, 25 Jul 2012 10:32:31 GMT
To: "firstname.lastname@example.org" <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>
Subject: Transactional Multiplex (fan out) Sink
In our system, we need to fan out the aggregated flow to several destinations. Usually the flow to each destination is identical.
There is a nice feature of NG, the "multiplexing flow", which can satisfy our requirements. It is implemented by using separated channels, which is easy to do transaction control.
But in our case, the fan out is replicating in most cases. If using the current "Replicating to Channels" configuration, we will get several identical channels on the same host, which may consume a large amount resources (memory, disk, etc.). The performance may possibly drop. And the events to each destination may not be synchronized.
I read NG source, I think I could move the multiplex from Channel to Sink, that is, using single Channel, fan out to different Sinks, which may solve the problems (resource usage, performance, event synchronization) of multiple Channels.
I see that there are "LoadBalancingSinkProcessor" and "SinkSelector" classes, but they cannot be used to achieve the target of replicating events from one Channel to different Sinks.
The following is an optional implementation of the Transactional Multiplex (or fan out) Sink:
1. Add a Transactional Multiplex Sink Processor, which will group the operations of all fan out Sinks into one transaction, and use a certain policy to commit the transaction.
2. Add MultiplexSink, which simply processes the Events and report status, no transaction.
3. Add "peek()" and "remove()" to Channel and Transaction.
The policy of committing a transaction can be defined as follow (suppose we have N Sinks) :
1. When M(0=<M<=N) Sinks succeed;
e.g. value: ANY, ONE, QUARUM, ALL
2. When specified M(0<M<=N) Sinks (important sinks) succeed.
A selector can also be used by Transactional Multiplex Sink Processor to filter the events for some Sinks (Optional).
And this can be combined with the existing Multiplex Channel Flow: Multiplex events into different Channels, each Channel can replicate to different Sinks.
Would like to hear your suggestions firstly.
If it is reasonable, I will create a ticket in JIRA and provide the patch for review.
Yongkun Wang (Kun)