[
https://issues.apache.org/jira/browse/FLUME-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206981#comment-13206981
]
Arvind Prabhakar commented on FLUME-865:
----------------------------------------
@Jarcec - While making the SinkRunner.PollingRunner would also work, I am more
inclined towards modifying the SinkRunner to work with a SinkProcessor instead
of a single Sink. The SinkProcessor will be a new interface that will be
instantiated for every "group" of sinks and wired into the runner. This is
because regardless of failover or load-balancing policy that the SinkProcessor
embodies, the details of how the runner works will not change. It will still
have a runner thread that does a periodic poll of events and invokes the
SinkProcessor much like it invokes the Sink today.
@Juhani - I understand your concerns and thank you for being transparent about
these. Perhaps I did not understand your proposal very well. Can you please
illustrate how the configuration will look like for the example I used above
(agent1 with channel1, and sink1/sink2 in failover configuration)?
Regarding the runner effectively turning into an empty shell - that is
perfectly acceptable. The only purpose the runner serves is to implement the
running semantic for the sink - which is have a thread that periodically polls
and backs up if things are not getting processed very well. Having multiple
runners will complicate this logic and create significant difference in the way
this logic executes between different implementations. Hence my concern with
overloading the runner to do anything but run the sink threads.
> 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.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
