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 >
