Re: Collapsing Sink and Pollable Sink into one

[Arvind Prabhakar <ar...@apache.org>]

Filed issue: https://issues.apache.org/jira/browse/FLUME-949

Thanks,
Arvind

On Mon, Jan 30, 2012 at 10:13 AM, Arvind Prabhakar <ar...@apache.org>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 <ja...@apache.org>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
>>
>
>