[
https://issues.apache.org/jira/browse/FLUME-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474404#comment-13474404
]
Hari Shreedharan commented on FLUME-1630:
-----------------------------------------
Brock,
I agree that we need not worry about 2 or 3. 2 is ok even if the source/sink
buffers data, since there is no guarantee that the data is preserved unless it
is committed into a channel. So if a source/sink returns success without
commit, that is just a violation of the semantics and we should not bother
about it.
I know people who have written proprietary custom components and have been
using Flume in production since v1.1.0 (since many/most components were not
available or were not stable at that time). They may have upgraded to newer
versions, but I am not sure if they actually moved off the components they
wrote at the time. If we make "Reusablity" explicit, we risk breaking these
components in a minor release - which should not be the case (or we could move
to hbase-style releases, which means maintaining multiple code lines).
> Flume configuration code could be improved
> ------------------------------------------
>
> Key: FLUME-1630
> URL: https://issues.apache.org/jira/browse/FLUME-1630
> Project: Flume
> Issue Type: Sub-task
> Components: Configuration
> Affects Versions: v1.3.0
> Reporter: Brock Noland
> Assignee: Brock Noland
> Attachments: FLUME-1630-0.patch, FLUME-1630-1.patch
>
>
> 1) It's not currently possible to provide your own configuration source
> 2) All sinks/sources/channels are reused, even across re-configurations which
> they are not used
> 3) The flume-ng-node module is very complex and starts many threads which are
> not required. That is there are multiple life cycle supervisors.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira