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 sufficiently 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.
