[ 
https://issues.apache.org/jira/browse/FLUME-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877462#comment-13877462
 ] 

Ted Malaska commented on FLUME-2298:
------------------------------------

1. I will update the sink to source problem.  That was a cut and paste error.
2.1. About the Avro Source/Sink.  The reason I hesitate on this is it needs to 
support the ordering correctly.  That is why in the doc I say something like 
the Avro Source and Sink.  I need to flush this part out more.
2.2. Master/Slave is just a state.  I disagree here.  Masters in this design, 
will only have one state.  Slave can have three states WAITING_FOR_MASTER, 
ORPHANED, or SERVING_MASTER.
3. Ordering is important because messages can be added to the Master through 
asynch processes.  And the takes from the master and the slave have to be in 
synch.  Let me know if this is not documented well in the document I can try to 
give it more attention.  This is also the point Hari brought up a while ago.  
4. Slave Channel needs to have Sink settings from master.  I disagree here.  
The idea is that sink from the master could be dead because the master is dead. 
 The local sink in the slave's agent will take the events.
5. Replicated Channel.  I don't know if we should change the name just yet.  
Also Replication I believe may be too limiting of a name.  I've figuring this 
is behind a lot of the points made.  There is a difference from this design and 
just replication.  Lets get approval for the design first.  


> Distributed Channel
> -------------------
>
>                 Key: FLUME-2298
>                 URL: https://issues.apache.org/jira/browse/FLUME-2298
>             Project: Flume
>          Issue Type: New Feature
>          Components: Channel
>            Reporter: Ted Malaska
>            Assignee: Ted Malaska
>         Attachments: FlumeDistributedChannelDesign.0.1.pdf, 
> FlumeDistributedChannelDesign.0.2.1.pdf, FlumeDistributedChannelDesign.0.2.pdf
>
>
> This channel will allow for events to be persisted with a plugable method on 
> more then one agent or node.  
> The goal is to gain the following benefits:
> 1. Events will continue to flow to sinks with out loss or with out large 
> delay even in the case of node failure.
> 2. Protect against loss in the case of a complete single node failure



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to