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
