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

[email protected] commented on FLUME-865:
-----------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3750/#review5216
-----------------------------------------------------------


Thanks for the patch Juhani. The change is good for checkin. I have some 
feedback below, feel free to push back and create follow-up issues to address 
those if you would so prefer.

* Javadocs for new interfaces and default implementation would be great.
* Since the javadoc on PropertiesFileConfigurationProvider are comprehensive, a 
brief mention of the group semantics in that would help keep it up-to-date.
* In a few places the lines are over 80 character limit. I typically set the 
"show print margine" on my eclipse workbench and it helps identify those 
violations.

Some more feedback follows:


flume-ng-core/src/main/java/org/apache/flume/SinkProcessor.java
<https://reviews.apache.org/r/3750/#comment11411>

    Since the sinks are named components anyway, the passing of Map<> keyed on 
the names is not necessary. Using a Map here makes ambiguous the order of 
declaration which may be of some consequence to the sink processor. Hence I 
suggest using a List instead.
    
    We can have an AbstractSinkProcessor which implements this method and 
internally constructs a map for quick lookups by the child classes.



flume-ng-core/src/main/java/org/apache/flume/sink/FailoverSinkProcessor.java
<https://reviews.apache.org/r/3750/#comment11410>

    In the current implementation it seems that the priority of the sink is 
proportional to the priority value specified. Usually its the other way around 
- where lower priority value means higher priority.
    
    



flume-ng-core/src/main/java/org/apache/flume/sink/SinkGroup.java
<https://reviews.apache.org/r/3750/#comment11412>

    <nit> Perhaps this can be folded into Context implementation much like 
context.getSubProperties() does. 



flume-ng-core/src/main/java/org/apache/flume/sink/SinkProcessorFactory.java
<https://reviews.apache.org/r/3750/#comment11413>

    Following the convention for other named component types - it will be 
better to have an Enum for SinkProcessorType which defines the short name and 
implementation class name.



flume-ng-node/src/main/java/org/apache/flume/conf/properties/PropertiesFileConfigurationProvider.java
<https://reviews.apache.org/r/3750/#comment11408>

    Suggest you use a LinkedHashMap here to preserve the order of declaration 
of sinks. Otherwise, this order of declaration will be lost when SinkGroup is 
instantiated.
    
    While not every group/processor would need to know the order, we should 
preserve it nevertheless.


- Arvind


On 2012-02-20 01:46:41, Juhani Connolly wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/3750/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2012-02-20 01:46:41)
bq.  
bq.  
bq.  Review request for Flume.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  This includes the changes from FLUME-945 and is thus subject to change 
with it. I have a separate patch for the diff from 945->865 if someone wants it.
bq.  
bq.  A failover sink runner is added, along with a SinkRunnerFactory. The 
configuration reading is modified so as to read the runner configuration and 
pass it to the SinkRunnerFactory.
bq.  A failover sink is used by setting the runner type to failover for every 
participating sink. In addition each sink assigned to a runner must set the 
same runner.name and a unique runner.priority
bq.  The runner will poll only the highest priority live sink. Should it fail 
by throwing EventDeliveryException, it will throw it into a pile of dead sinks. 
Only once all sinks are exhausted are the dead sinks revived.
bq.  
bq.  Some issues that are outstanding
bq.  - Not all sinks throw EventDeliveryException, or have a clear time when 
they should be considered "dead". Coupling such sinks with the failover runner 
will not result in failover
bq.  - Sinks do not have a clear mechanism to test for their liveliness, other 
than perhaps polling LifecycleState. However for most sinks lifecyclestate 
tends to remain in START even if the sink is unable to do anything(e.g. avro 
sink failing to connect)
bq.  
bq.  
bq.  This addresses bug FLUME-865.
bq.      https://issues.apache.org/jira/browse/FLUME-865
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    flume-ng-core/src/main/java/org/apache/flume/SinkProcessor.java 
PRE-CREATION 
bq.    flume-ng-core/src/main/java/org/apache/flume/SinkRunner.java 074aab3 
bq.    
flume-ng-core/src/main/java/org/apache/flume/sink/DefaultSinkProcessor.java 
PRE-CREATION 
bq.    
flume-ng-core/src/main/java/org/apache/flume/sink/FailoverSinkProcessor.java 
PRE-CREATION 
bq.    flume-ng-core/src/main/java/org/apache/flume/sink/SinkGroup.java 
PRE-CREATION 
bq.    
flume-ng-core/src/main/java/org/apache/flume/sink/SinkProcessorFactory.java 
PRE-CREATION 
bq.    
flume-ng-core/src/test/java/org/apache/flume/sink/TestFailoverSinkProcessor.java
 PRE-CREATION 
bq.    
flume-ng-node/src/main/java/org/apache/flume/conf/properties/FlumeConfiguration.java
 1ee1f8e 
bq.    
flume-ng-node/src/main/java/org/apache/flume/conf/properties/PropertiesFileConfigurationProvider.java
 3d0e366 
bq.    
flume-ng-node/src/test/java/org/apache/flume/node/TestAbstractLogicalNodeManager.java
 34d6010 
bq.    flume-ng-node/src/test/resources/flume-conf.properties eebf03d 
bq.  
bq.  Diff: https://reviews.apache.org/r/3750/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  All unit tests pass.
bq.  A new unit test was added. It creates a memory channel and a failover 
runner with 3 sinks that consume a preset number of events then send 
EventDeliveryException. Events are fed to the channel and assertions are made 
that the runner is failing over to the correct sinks. This test also passes.
bq.  
bq.  I also tried to run this on a real cluster, with one master source using a 
failover runner to three avro sinks which would each fed into separate agents 
which I would kill off to test the failover. Unfortunately because of AvroSink 
not throwing EventDeliveryException, this test could not be completed 
succesfully, and I felt it was beyond the scope of this ticket to modify 
AvroSink
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Juhani
bq.  
bq.


                
> Implement failover sink 
> ------------------------
>
>                 Key: FLUME-865
>                 URL: https://issues.apache.org/jira/browse/FLUME-865
>             Project: Flume
>          Issue Type: New Feature
>          Components: Sinks+Sources
>    Affects Versions: NG alpha 2
>            Reporter: Jarek Jarcec Cecho
>            Assignee: Juhani Connolly
>             Fix For: v1.1.0
>
>         Attachments: FLUME-865.4.patch
>
>
> It would be nice if the flume-ng would have ability to failover to different 
> sink in case that the active one is not responding (e.g. before failing the 
> transaction).

--
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

        

Reply via email to