[
https://issues.apache.org/jira/browse/FLUME-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151773#comment-16151773
]
Will Zhang commented on FLUME-3149:
-----------------------------------
Hi [~fszabo],
A PollableSourceChannel sounds like a good idea but I got some confusions about
it.
Do you mean a channel which implements both the PollableSource and
BasicChannelSemantics interfaces?
If so, how does the PollableSource process() method work? For now, it puts
events into the channel. As you mentioned, this PollableSourceChannel has no
buffer so I suppose it doesn't need a put method and only reads events and
keeps track of them when taken in a transaction?
And [~bessbd], could you clarify the idea about "a new Event implementation
which has a "persisted" flag or callback"? I suppose a event with callback is
something you can callback to the source when events are consumed and committed
in the channel so that we can have a actual position record. If so, this seems
to be a clean way to go.
Also, what does the "persisted" flag mean?
Please correct me if I got anything wrong.
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)
