[
https://issues.apache.org/jira/browse/FLUME-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Otto updated FLUME-1838:
-------------------------------
Attachment: 0001-Adding-new-Flume-UDP-Source-2.patch
This is the second patch I've uploaded. The difference between this and the
previous, is that this does not write the delimiter into the Event when it is
read. This also reverts the change to Context. I decided not to implement a
getCharacter method, as it was just making things more complicated with no real
gain.
> 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
> Attachments: 0001-Adding-new-Flume-UDP-Source-2.patch
>
> 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
