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 <[email protected]> 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 <[email protected]> > 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. >
