[
https://issues.apache.org/jira/browse/FLUME-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
E. Sammer updated FLUME-1176:
-----------------------------
Description:
I'd like to propose that ChannelProcessor and ChannelSelector go away in favor
of a simplified composite channel based implementation.
Today, fan out and content based routing (CBR, or technically header based
routing) is implemented via the ChannelProcessor and ChannelSelector. While
this works, it special cases these ideas. I propose we:
* Create a Channel implementation called FanOutChannel that takes a list of
Channels.
* Its Transaction implementation simply delegates to the inner channel's
transactions.
* The semantics remain the same.
In other words:
{code}
class FanOutChannel:
List<Channels> channels;
getTx:
tx = new FanOutTransaction()
for ch in channels:
txns.add(ch.getTx())
return tx
class FanOutTransaction implements Transaction:
List<Transaction> txns;
begin:
for tx in txns:
tx.begin()
commit:
for tx in txns:
tx.commit()
...
{code}
This preserves the semantics and drastically simplifies the code. The notion of
required and optional channels are just conditions in the catch blocks within
the composite Transaction impl (i.e. to rethrow or not to rethrow).
This works for CBR and other composite cases.
was:
I'd like to propose that ChannelProcessor and ChannelSelector go away in favor
of a simplified composite channel based implementation.
Today, fan out and content based routing (CBR, or technically header based
routing) is implemented via the ChannelProcessor and ChannelSelector. While
this works, it special cases these ideas. I propose we:
* Create a Channel implementation called FanOutChannel that takes a list of
Channels.
* Its Transaction implementation simply delegates to the inner channel's
transactions.
* The semantics remain the same.
In other words:
class FanOutChannel:
List<Channels> channels;
getTx:
tx = new FanOutTransaction()
for ch in channels:
txns.add(ch.getTx())
return tx
class FanOutTransaction implements Transaction:
List<Transaction> txns;
begin:
for tx in txns:
tx.begin()
commit:
for tx in txns:
tx.commit()
...
This preserves the semantics and drastically simplifies the code. The notion of
required and optional channels are just conditions in the catch blocks within
the composite Transaction impl (i.e. to rethrow or not to rethrow).
This works for CBR and other composite cases.
> Fan out and CBR should be refactored to be composite channels
> -------------------------------------------------------------
>
> Key: FLUME-1176
> URL: https://issues.apache.org/jira/browse/FLUME-1176
> Project: Flume
> Issue Type: Improvement
> Components: Channel, Technical Debt
> Affects Versions: v1.1.0
> Reporter: E. Sammer
>
> I'd like to propose that ChannelProcessor and ChannelSelector go away in
> favor of a simplified composite channel based implementation.
> Today, fan out and content based routing (CBR, or technically header based
> routing) is implemented via the ChannelProcessor and ChannelSelector. While
> this works, it special cases these ideas. I propose we:
> * Create a Channel implementation called FanOutChannel that takes a list of
> Channels.
> * Its Transaction implementation simply delegates to the inner channel's
> transactions.
> * The semantics remain the same.
> In other words:
> {code}
> class FanOutChannel:
> List<Channels> channels;
> getTx:
> tx = new FanOutTransaction()
> for ch in channels:
> txns.add(ch.getTx())
> return tx
> class FanOutTransaction implements Transaction:
> List<Transaction> txns;
> begin:
> for tx in txns:
> tx.begin()
> commit:
> for tx in txns:
> tx.commit()
> ...
> {code}
> This preserves the semantics and drastically simplifies the code. The notion
> of required and optional channels are just conditions in the catch blocks
> within the composite Transaction impl (i.e. to rethrow or not to rethrow).
> This works for CBR and other composite cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
