Choosing which one to use is purely based on your needs. The remote client operates synchronously and does not store the event on disk. The other two are asynchronous and guarantee delivery by storing to disk. The embedded agent embeds a Flume agent with a file channel. This is extremely reliable but Flume requires a lot of dependencies that then must be included in your app. The persistent version uses Berkeley DB instead of the file channel. It has less dependencies but isn't quite as fast as the embedded agent. The data does clean up. You just have to let it run until it creates 3 or 4 data files, at which time files will start disappearing. That is just how Berkley DB works.
Ralph > On Jan 10, 2016, at 5:23 AM, Conor Griffin <[email protected]> wrote: > > I’ve been trying out the FlumeAppender in log4j2 over the last couple of days > and it seems to work. However, I’m not clear on the situations you should be > using the three types; remote client, embedded agent and persistent. The > documentation isn’t particularly clear on this either and doesn’t list > typical drawbacks/advantages of each approach. I tried out the persistent > one (which seems to perform better than the remote client) and it generates > data in the dataDir directory supplied in the configuration. But this data > doesn’t seem to get cleaned up. Does this persist forever unless manually > deleted? > > I guess I’m looking for some more in depth documentation or help with the > FlumeAppender specifically. If someone can either point me to some further > existing documentation or help me understand it a little better I’d > appreciate it. > > Thanks, Conor > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
