[jira] [Comment Edited] (FLUME-3149) reduce cpu cost for file source transfer while still maintaining reliability

["Will Zhang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLUME-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158975#comment-16158975 ] 

Will Zhang edited comment on FLUME-3149 at 9/8/17 5:29 PM:
-----------------------------------------------------------

Hi [~bessbd],

I didn't quite get how the "persisted" flag could be implemented. In this file transfer scenario, the source won't know about how to "safely" committed unless the channel told the source at the exact moment when the events are taken and committed from the channel. In my understanding, the event is only "safely commited" when sink consumes it. And as far as I know, a callback to the source is necessary in the commit() method of channel transaction. 

So as you mentioned, we could implement a new event.

I came up with an idea that we can create a new Event class like "NotificationEvent" which extends the SimpleEvent and contains a callback function. Generally, in the commit method of the memory channel, it will check whether the takeList is not null and whether the event is Instance of NotificationEvent.class. If so, it will call the callback function of every event which is defined in the event and going to use the header info to update pos info in Taildir. At last of the commit method, it will call perhaps another callback method in the event which is just going to write the updated pos info in taildir to disk. 

This way, changes are mainly on the taildir side and changes on the channel side is small which only adds a branch of checking takeList and call back in the commit method. I had a simple test and it works but I'm not sure whether it meets the requirement of "separate the channel and source".

What do you think?
Thank you.



was (Author: zyfo2):
Hi [~bessbd],

I didn't quite get how the "persisted" flag could be implemented. In this file transfer scenario, the source won't know about how to "safely" committed unless the channel told the source at the exact moment when the events are taken and committed from the channel. In my understanding, the event is only "safely commited" when sink consumes it. And as far as I know, a callback to the source is necessary in the commit() method of channel transaction. 

So as you mentioned, we could implement a new event.

I came up with an idea that we can create a new Event class like "NotificationEvent" which extends the SimpleEvent and contains a callback function. Generally, in the commit method of the memory channel, it will check whether the takeList is not null and whether the event is Instance of NotificationEvent.class. If so, it will call the callback function of every event which is defined in the event and going to use the header info to update pos info in Taildir. At last of the commit method, it will call perhaps another callback method in the event which is just going to write the updated pos info to disk. 

This way, changes are mainly on the taildir side and changes on the channel side is small which only adds a branch of checking takeList and call back in the commit method. I had a simple test and it works but I'm not sure whether it meets the requirement of "separate the channel and source".

What do you think?
Thank you.


> reduce cpu cost for file source transfer while still maintaining reliability
> ----------------------------------------------------------------------------
>
>                 Key: FLUME-3149
>                 URL: https://issues.apache.org/jira/browse/FLUME-3149
>             Project: Flume
>          Issue Type: Improvement
>          Components: File Channel
>            Reporter: Will Zhang
>
> File channel tracks transferred events and use transnational mechanism to make transfer recoverable. However, it increases CPU cost due to frequent system calls like write, read, etc. The Cpu cost could be very high if the transfer rate is high. In contrast, Memory channel  has no such issue which requires only about 10% of CPU cost  in the same environment but it's not recovered if the system is down accidentally.
> For sources like taildir/spooldir, I propose we could track offsets of file and store them locally to achieve reliability while still using memory channel to reduce CPU cost. Actually, I have already implemented this feature by storing the offsets in event headers and passing it to my own "offsetMemoryChannel" and store theses offsets in local disk in our production which reduces CPU cost by about 90 percent.
> Please let me know if it's worthwhile to have this feature in community version. Thank you.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)