Roger that! Thank you all for your comments. Flume with unique keys it is.
Gary
On Mon, Apr 3, 2017 at 10:15 PM, Ralph Goers
wrote:
> Again, if you use an async logger you will lose whatever is in the memory
> buffer when the server stops or crashes. If you log directly to Flume you
> are guara
Again, if you use an async logger you will lose whatever is in the memory
buffer when the server stops or crashes. If you log directly to Flume you are
guaranteed that the audit event is written when the logging call returns and
your application can count on that.
The only thing you really need
No. JMS does not guarantee delivery in the way your would want. Sure, if the
JMS service says it accepted the event then it is guaranteed, but if it doesn’t
what are you going to do with the event? It is stuck in the client. You would
have to invent some way to queue the events and then retry th
I'm pretty sure you do, yes, though the async loggers do have less
reliability in theory due to more log messages being buffered in memory
before being written, so more messages could be lost in case of failure.
That's configurable to whatever level of reliability you want, though.
On 3 April 2017
Thanks Matt. With the Flume appender, do I still need to use an async
logger to get the best perf?
Gary
On Mon, Apr 3, 2017 at 8:31 PM, Matt Sicker wrote:
> Clarifications: other than the file appenders, the flume appender is
> probably the most reliable appender.
>
> And for the direct appende
Clarifications: other than the file appenders, the flume appender is
probably the most reliable appender.
And for the direct appender config, that's also with fully async loggers.
I've been considering putting together a small blog post about the most
efficient log4j2.xml configurations.
On 3 Apr
The Flume appender can persist messages within the same process to files
before sending them to other agents. I don't think any other appender can
guarantee that.
Personally, I've been using direct console appenders lately and using
graylog to slurp stdout on docker containers, but I'm not the one
Wait a sec. A JMS provider can guarantee message delivery. How can events
be lost once they are in the provider? Are you saying that using an async
logger is 'unsafe' because the events in the ring buffer go away if the JVM
goes down?
Ideally I want to publish and forget, with the publish part asy
What’s the point though when all you have to do is specify the pattern layout
with “%m%ex{none}”?
How can you do auditing with the async logger? You may lose events with that.
Your use case is exactly why I wrote the FlumeAppender. It is very much like
JMS but a whole lot faster and guarantees
Right. I want to post to JMS message objects I've serialized to JSON. All I
care about is the message.
I log these events to a specially named logger with a specially named
marker. These are the only events that should be published to JMS (I use a
filter and the one marker). I am in charge of the
So, exceptions are swallowed and no newlines are rendered? Interesting.
What's the use case?
Sent from my iPhone
> On Apr 4, 2017, at 7:30, Gary Gregory wrote:
>
> Hi All,
>
> I am considering a new layout called "MessageLayout" which would be
> synonymous with:. Thoughts?
>
> Gary
>
> --
11 matches
Mail list logo
