Vanilla would work for my case. On Tue, Feb 9, 2016 at 8:49 PM, Ralph Goers <[email protected]> wrote:
> The 3 types are: > > Vanilla - it uses Flume’s RPC client to send events to a remote Flume > instance synchronously. If the remote Flume goes down you could lose > events. It requires a minimum of dependencies. > Embedded - it uses the Flume File Channel to write the events there first. > It then asynchronously sends the events to the remote Flume agent without > losing any events. This will give your application the best performance but > requires the most dependencies. > Persistent - It uses Berkely DB instead of the File channel. It also > asynchronously sends events to a remote Flume agent and shouldn’t lose > events. This has less dependencies but doesn’t perform as well as the > embedded appender. > > Your choice is purely based on which of these characteristics you want. > > Ralph > > > > > On Jan 10, 2016, at 5:29 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] > >
