[
https://issues.apache.org/jira/browse/FLUME-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552945#comment-13552945
]
Brock Noland commented on FLUME-1838:
-------------------------------------
What in the world?! SyslogUDPSource has a class starting with a lower name
character! (syslogHandler)
It looks like you could take SyslogUDPSource, rename it GenericUDPSource and
then have a single method the UDPSource could override:
protected Event convert(MessageEvent)
As part of this JIRA I don't think it's a requirement to re-factor
SyslogUDPSource. That can be done in a later JIRA.
> Generic UDP & Multicast Source
> ------------------------------
>
> Key: FLUME-1838
> URL: https://issues.apache.org/jira/browse/FLUME-1838
> Project: Flume
> Issue Type: New Feature
> Components: Sinks+Sources
> Reporter: Andrew Otto
> Priority: Minor
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> There are existent TCP (NetcatSource) and UDP Syslog (SyslogUDPSource)
> sources for Flume, but nothing that is able to easily consume plain ol' UDP
> streams. My use case includes unicast UDP, as well as multicast streams.
> I'm working on coding up a generic UDPSource for the Wikimedia Foundation,
> and was wondering if this would be useful to the Flume community at large.
> If so, here are some questions:
> If I made a generic UDPSource, a lot could be DRYed and abstracted out of
> SyslogUDPSource, with SyslogUDPSource becomfing a subclass. Should I bother
> doing this? I'd almost rather not, as I won't personally be using
> SyslogUDPSource, so I'd rather not have to test changes there.
> Should UDPSource code live in flume-ng-sources, or in
> flume-ng-core/src/main/.../sources?
--
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
