flume-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Malouf <malouf.g...@gmail.com>
Subject Re: Embedded Agent vs Client SDK
Date Fri, 14 Feb 2014 04:59:11 GMT
Google searching and the wiki did not pick that up, thanks for the help!  I
think it would be good to have these use cases directly on Flume's website.


On Thu, Feb 13, 2014 at 11:33 PM, Jeff Lord <jlord@cloudera.com> wrote:

> Gary,
>
> I'm going to just quote the design doc here:
>
>
> https://issues.apache.org/jira/secure/attachment/12560587/embedded-agent-3.pdf
>
> 1. A Flume Embedded agent would be useful to applications which send
> data to a Flume agent acting as a "collector". Currently using the
> RPCClient or HTTPSource, if there is a burst of events or the
> collector is unavailable the application is responsible for queueing
> the events. By embedding a Flume agent the application would be
> configured with a Flume channel alleviating the need to buff er in the
> client application.
>
> 2. A similar but su fficiently diff erent use case would be to replace
> a Flume agent deployed on the source system. In some environments
> Flume agents maybe deployed on the source systems simply to have a
> buff er crossing the network boundry. In these scenarios the amount of
> work on the operations team could be reduced by simply embedding a
> simple agent in the source application. In a similar vane,there are
> environments where deploying anything but a J2EE application on
> application servers is troublesome.
>
> They are both should be relatively simple to implement.
> Hope this helps.
>
> Best,
>
> Jeff
>
>
>
>
>
>
> On Thu, Feb 13, 2014 at 8:14 PM, Gary Malouf <malouf.gary@gmail.com>
> wrote:
> > Can someone list out when you would choose to use one over the other?
>  If I
> > am not mistaken, the client sdk is the simpler of the two to use.
>

Mime
View raw message