logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tara Czutno <javaworkingg...@gmail.com>
Subject Re: Differences between FlumeAppender options
Date Wed, 10 Feb 2016 16:56:32 GMT
Vanilla would work for my case.

On Tue, Feb 9, 2016 at 8:49 PM, Ralph Goers <ralph.goers@dslextreme.com>
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 <conorgriffin@gmail.com>
> 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: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message