Filed issue: https://issues.apache.org/jira/browse/FLUME-949
Thanks, Arvind On Mon, Jan 30, 2012 at 10:13 AM, Arvind Prabhakar <[email protected]>wrote: > Thanks for stepping up Jarcec. If we do not see other ideas offered to > address this, we can timeout after a couple of days and file the necessary > JIRA to do follow-up work on this. > > Thanks, > Arvind > > > On Mon, Jan 30, 2012 at 10:09 AM, Jarek Jarcec Cecho <[email protected]>wrote: > >> +1. >> >> I would like to help if needed. >> >> Jarcec >> >> On Mon, Jan 30, 2012 at 09:54:59AM -0800, Arvind Prabhakar wrote: >> > So far we have the following sinks in Flume (ng): >> > >> > - AvroSink >> > - HDFSEventSink >> > - IRCSink >> > - LoggerSink >> > - NullSink >> > - RollingFileSink >> > >> > All of these sinks are of type PollableSink - where the contract is >> that an >> > active runner polls the sink to pick the next event based on a set >> policy. >> > This runner is great since it offers us the ability to decouple thread >> > lifecycle details from the sink implementation. It also offers the >> ability >> > to implement failover/load-balancing and other complex sink routing >> > policies as necessary. Flume-865 is taking this approach. >> > >> > Since all Sinks are PollableSink types, I am suggesting that we collapse >> > the PollableSink into the Sink interface itself (promote process() into >> > Sink). This will ensure that our infrastructure is built to deal with >> such >> > sink types only and therefore will be easier to implement and support. >> > >> > If you feel this is not a valid assumption, please chime in to discuss >> your >> > viewpoint. >> > >> > Thanks, >> > Arvind >> > >
