Re: MessageLayout

[Ralph Goers]

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 to be aware of is that in an HA configuration it 
is possible to end up with multiple instances of the event in the final 
repository so you need to make sure your events include a unique key that can 
be used to remove duplicates.

Ralph

> On Apr 3, 2017, at 8:40 PM, Gary Gregory  wrote:
> 
> 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 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 April 2017 at 22:01, Matt Sicker  > wrote:
> 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 who set all that 
> up. Either way, the most reliable way to log things outside of files is Flume.
> 
> On 3 April 2017 at 19:45, Gary Gregory  > wrote:
> 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 asynchronous, 
> call the API, and it returns right away.
> 
> Is there no way to do that with our JMS Appender?
> 
> Gary
> 
> On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers  > wrote:
> 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 events aren’t lost.
> 
> Ralph
> 
>> On Apr 3, 2017, at 5:03 PM, Gary Gregory > > wrote:
>> 
>> 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 message format and it is 
>> consumed on the other JMS side by a specialized agent which I also control.
>> 
>> IOW, I am using the Log4j infrastructure as the simplest way to send custom 
>> messages over to JMS. These are not traditional logging events, rather a 
>> kind of auditing system. I leverage the Log4j async logger as well. No need 
>> to deal with the JMS API.
>> 
>> Gary
>> 
>> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma > > wrote:
>> 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
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com  | 
>>> ggreg...@apache.org  
>>> Java Persistence with Hibernate, Second Edition 
>>> 
>>>   
>>> 
>>> JUnit in Action, Second Edition 
>>> 
>>>   
>>> 
>>> Spring Batch in Action 
>>> 
>>>   
>>> 
>>> Blog: 

Re: MessageLayout

[Ralph Goers]

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 them later.

The Flume Appender writes the event into a channel in the client and then gives 
control back to you. From that point on delivery is guaranteed downstream. It 
uses a separate thread to pull from the channel and write to a downstream flume 
agent. That agent can use any of the sinks that Flume provides to write the 
data to Kafka, Hadoop, ElasticSearch, etc. or you can write a custom Sink to do 
whatever you want. I used Flume at my previous employer and am using it 
currently and I can tell you that it is extremely reliable and the throughput 
is pretty good.

Yes, logging asynchronously is unsafe because all in-flight events will be 
lost. That is fine for normal debug logs but is unacceptable for auditing. 
Again, because Flume writes to the file channel that won’t happen unless you 
disk is full.

If you use JMS then you have to handle the case where event delivery fails for 
whatever reason, or you have to require that your JMS service is 100% reliable.

Ralph

> On Apr 3, 2017, at 5:45 PM, Gary Gregory  wrote:
> 
> 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 asynchronous, 
> call the API, and it returns right away.
> 
> Is there no way to do that with our JMS Appender?
> 
> Gary
> 
> On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers  > wrote:
> 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 events aren’t lost.
> 
> Ralph
> 
>> On Apr 3, 2017, at 5:03 PM, Gary Gregory > > wrote:
>> 
>> 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 message format and it is 
>> consumed on the other JMS side by a specialized agent which I also control.
>> 
>> IOW, I am using the Log4j infrastructure as the simplest way to send custom 
>> messages over to JMS. These are not traditional logging events, rather a 
>> kind of auditing system. I leverage the Log4j async logger as well. No need 
>> to deal with the JMS API.
>> 
>> Gary
>> 
>> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma > > wrote:
>> 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
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com  | 
>>> ggreg...@apache.org  
>>> Java Persistence with Hibernate, Second Edition 
>>> 
>>>   
>>> 
>>> JUnit in Action, Second Edition 
>>> 
>>>   
>>> 
>>> Spring Batch in Action 
>>> 
>>>   
>>> 
>>> Blog: http://garygregory.wordpress.com  
>>> Home: http://garygregory.com/ 
>>> Tweet! http://twitter.com/GaryGregory 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 

Re: MessageLayout

[Matt Sicker]

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 at 22:40, Gary Gregory  wrote:

> 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 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 April 2017 at 22:01, Matt Sicker  wrote:
>>
>>> 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 who set
>>> all that up. Either way, the most reliable way to log things outside of
>>> files is Flume.
>>>
>>> On 3 April 2017 at 19:45, Gary Gregory  wrote:
>>>
 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
 asynchronous, call the API, and it returns right away.

 Is there no way to do that with our JMS Appender?

 Gary

 On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers  wrote:

> 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 events aren’t lost.
>
> Ralph
>
> On Apr 3, 2017, at 5:03 PM, Gary Gregory 
> wrote:
>
> 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 message format and it is
> consumed on the other JMS side by a specialized agent which I also 
> control.
>
> IOW, I am using the Log4j infrastructure as the simplest way to send
> custom messages over to JMS. These are not traditional logging events,
> rather a kind of auditing system. I leverage the Log4j async logger as
> well. No need to deal with the JMS API.
>
> Gary
>
> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma 
> wrote:
>
>> 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
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 

Re: MessageLayout

[Gary Gregory]

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 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 April 2017 at 22:01, Matt Sicker  wrote:
>
>> 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 who set
>> all that up. Either way, the most reliable way to log things outside of
>> files is Flume.
>>
>> On 3 April 2017 at 19:45, Gary Gregory  wrote:
>>
>>> 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
>>> asynchronous, call the API, and it returns right away.
>>>
>>> Is there no way to do that with our JMS Appender?
>>>
>>> Gary
>>>
>>> On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers 
>>> wrote:
>>>
 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 events aren’t lost.

 Ralph

 On Apr 3, 2017, at 5:03 PM, Gary Gregory 
 wrote:

 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 message format and it is
 consumed on the other JMS side by a specialized agent which I also control.

 IOW, I am using the Log4j infrastructure as the simplest way to send
 custom messages over to JMS. These are not traditional logging events,
 rather a kind of auditing system. I leverage the Log4j async logger as
 well. No need to deal with the JMS API.

 Gary

 On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma 
 wrote:

> 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
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 

 
 JUnit in Action, Second Edition
 

 
 Spring Batch in Action
 

Re: MessageLayout

[Matt Sicker]

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 April 2017 at 22:01, Matt Sicker  wrote:

> 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 who set
> all that up. Either way, the most reliable way to log things outside of
> files is Flume.
>
> On 3 April 2017 at 19:45, Gary Gregory  wrote:
>
>> 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 asynchronous,
>> call the API, and it returns right away.
>>
>> Is there no way to do that with our JMS Appender?
>>
>> Gary
>>
>> On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers 
>> wrote:
>>
>>> 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 events aren’t lost.
>>>
>>> Ralph
>>>
>>> On Apr 3, 2017, at 5:03 PM, Gary Gregory  wrote:
>>>
>>> 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 message format and it is
>>> consumed on the other JMS side by a specialized agent which I also control.
>>>
>>> IOW, I am using the Log4j infrastructure as the simplest way to send
>>> custom messages over to JMS. These are not traditional logging events,
>>> rather a kind of auditing system. I leverage the Log4j async logger as
>>> well. No need to deal with the JMS API.
>>>
>>> Gary
>>>
>>> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma 
>>> wrote:
>>>
 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

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 

 
 JUnit in Action, Second Edition
 

 
 Spring Batch in Action
 
 
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory


>>>
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>>
>>> 
>>> JUnit in Action, Second Edition
>>> 
>>>
>>> 
>>> Spring Batch in Action
>>> 
>>> 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/

Re: MessageLayout

[Matt Sicker]

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 who set
all that up. Either way, the most reliable way to log things outside of
files is Flume.

On 3 April 2017 at 19:45, Gary Gregory  wrote:

> 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 asynchronous,
> call the API, and it returns right away.
>
> Is there no way to do that with our JMS Appender?
>
> Gary
>
> On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers 
> wrote:
>
>> 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 events aren’t lost.
>>
>> Ralph
>>
>> On Apr 3, 2017, at 5:03 PM, Gary Gregory  wrote:
>>
>> 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 message format and it is
>> consumed on the other JMS side by a specialized agent which I also control.
>>
>> IOW, I am using the Log4j infrastructure as the simplest way to send
>> custom messages over to JMS. These are not traditional logging events,
>> rather a kind of auditing system. I leverage the Log4j async logger as
>> well. No need to deal with the JMS API.
>>
>> Gary
>>
>> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma 
>> wrote:
>>
>>> 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
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>>
>>> 
>>> JUnit in Action, Second Edition
>>> 
>>>
>>> 
>>> Spring Batch in Action
>>> 
>>> 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 

Re: MessageLayout

[Gary Gregory]

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 asynchronous,
call the API, and it returns right away.

Is there no way to do that with our JMS Appender?

Gary

On Mon, Apr 3, 2017 at 5:38 PM, Ralph Goers 
wrote:

> 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 events aren’t lost.
>
> Ralph
>
> On Apr 3, 2017, at 5:03 PM, Gary Gregory  wrote:
>
> 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 message format and it is
> consumed on the other JMS side by a specialized agent which I also control.
>
> IOW, I am using the Log4j infrastructure as the simplest way to send
> custom messages over to JMS. These are not traditional logging events,
> rather a kind of auditing system. I leverage the Log4j async logger as
> well. No need to deal with the JMS API.
>
> Gary
>
> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma  wrote:
>
>> 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
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: MessageLayout

[Ralph Goers]

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 events aren’t lost.

Ralph

> On Apr 3, 2017, at 5:03 PM, Gary Gregory  wrote:
> 
> 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 message format and it is consumed on 
> the other JMS side by a specialized agent which I also control.
> 
> IOW, I am using the Log4j infrastructure as the simplest way to send custom 
> messages over to JMS. These are not traditional logging events, rather a kind 
> of auditing system. I leverage the Log4j async logger as well. No need to 
> deal with the JMS API.
> 
> Gary
> 
> On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma  > wrote:
> 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
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>>   
>> 
>> JUnit in Action, Second Edition 
>> 
>>   
>> 
>> Spring Batch in Action 
>> 
>>   
>> 
>> Blog: http://garygregory.wordpress.com  
>> Home: http://garygregory.com/ 
>> Tweet! http://twitter.com/GaryGregory 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
>   
> 
> JUnit in Action, Second Edition 
> 
>   
> 
> Spring Batch in Action 
> 
>   
> 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 

Re: MessageLayout

[Gary Gregory]

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 message format and it is
consumed on the other JMS side by a specialized agent which I also control.

IOW, I am using the Log4j infrastructure as the simplest way to send custom
messages over to JMS. These are not traditional logging events, rather a
kind of auditing system. I leverage the Log4j async logger as well. No need
to deal with the JMS API.

Gary

On Mon, Apr 3, 2017 at 4:07 PM, Remko Popma  wrote:

> 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
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: MessageLayout

[Remko Popma]

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
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

MessageLayout

[Gary Gregory]

Hi All,

I am considering a new layout called "MessageLayout" which would be
synonymous with:. Thoughts?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Created] (LOG4J2-1865) Many Issues with SyslogAppender: Unable to Send Stack Traces Over SyslogAppender using TCP, AppenderComponentBuilder lacks LoggerFields

[aaaaaaaa (JIRA)]

 created LOG4J2-1865:


 Summary: Many Issues with SyslogAppender: Unable to Send Stack 
Traces Over SyslogAppender using TCP, AppenderComponentBuilder lacks 
LoggerFields
 Key: LOG4J2-1865
 URL: https://issues.apache.org/jira/browse/LOG4J2-1865
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.8.1
 Environment: SLF4J, java8
Reporter: 


-Not enough documentation on the appenders page. What is a LoggerField? Where 
are the keys used?
-Unable to add LoggerFields to AppenderComponentBuilder
-LoggerFields added to SyslogAppender.Builder result in any logged messages w/ 
throwables to turn into a single letter logged message such as "e" or "n"
-Unable to receive in rsyslog using BSD format (only using RFC)
-Using config file with TCP, same result as SyslogAppender.Builder, with 
loggerfields the message is replaced fully by "e" or "n"
-Using config file with UDP, throwables are logged but new lines are printed 
instead of pre-processed: test#012java.lang.Throwable#012#011at 
main(main.java:5) [main.jar:?]#012

http://stackoverflow.com/questions/43173816/doesnt-seem-to-be-a-way-to-send-full-stack-traces-over-syslogappender-in-log4j2

I will have to find an alternative logging until this is fixed in log4j2. 
Remote logging is very important in my application as a stand-alone feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Deep Dive into Java 9’s Stack-Walking API

[Gary Gregory]

On a biz trip to the NL for a week, then a vacation to the UK and France
for two weeks ;-)

G

On Apr 2, 2017 10:35 PM, "Ralph Goers"  wrote:

> Where have you been?  I posted performance benchmarks based on that a week
> or two ago. See all my updates to LOG4J2-1359.
>
> I have already implemented StackWalker support on branch java9NoMultiRelease.
> I started on a branch for LOG4J2-1359 but trouble with the Multi-Release
> jar made me rethink it so I reimplemented it on the new branch. Once I have
> support for modules I will be merging it back into the LOG4J2-1359 branch
> and looking for a code review. In the meantime you are free to look at the
> java9NoMultiRelease branch.
>
> Ralph
>
>
> On Apr 2, 2017, at 10:03 PM, Gary Gregory  wrote:
>
> FYI: https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>

Re: Scala

[Ralph Goers]

I believe Flume is using Sphinx, but I think that is still driving from Maven. 
I would look at some other Apache sites, find one you like and then figure out 
how they did it.

Ralph

> On Apr 3, 2017, at 7:11 AM, Matt Sicker  wrote:
> 
> We don't have to use maven-site-plugin to generate the Scala site. That's 
> just the easy way to do it in theory, though I find it cumbersome. If you 
> know of any better documentation generator that we could use there (or even 
> in log4j-core), please let us know!
> 
> On 3 April 2017 at 04:06, Mikael Ståldal  > wrote:
> Using SBT would help to avoid having to duplicate the source code for each 
> Scala version. However, I'm not sure about how to do the Maven site stuff 
> with SBT.
> 
> On Sun, Apr 2, 2017 at 10:41 PM, Matt Sicker  > wrote:
> I'm not too experienced with it, but now that the Scala APIs are in their own 
> repo, it might be easier to use SBT instead of Maven for it. Just a thought 
> for a future release.
> 
> On 2 April 2017 at 15:27, Matt Sicker  > wrote:
> And don't mind the site commit I made earlier. That was from a snapshot, so I 
> have to commit it again anyways.
> 
> On 2 April 2017 at 15:25, Matt Sicker  > wrote:
> No, I figured I'd do log4j-core first. Still working on that right now, had 
> to restart the build from the tag because a test randomly decided to fail at 
> the worst possible time.
> 
> On 2 April 2017 at 15:11, Ralph Goers  > wrote:
> Has a Scala release been performed? The site needs to be deployed before I 
> can modify the log4j page(s) to point to it.
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
> 
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
> 
> 
> 
> 
> 
> -- 
> Matt Sicker >
> 
> 
> 
> -- 
> Matt Sicker >
> 
> 
> 
> -- 
> Matt Sicker >
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior software developer 
> 
> Magine TV
> mikael.stal...@magine.com 
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com  
> 
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  
> 
> 
> 
> -- 
> Matt Sicker >

[jira] [Commented] (LOG4J2-1855) Add an optional random delay in TimeBasedTriggeringPolicy

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953640#comment-15953640
 ] 

ASF GitHub Bot commented on LOG4J2-1855:


Github user m-anthony commented on a diff in the pull request:

https://github.com/apache/logging-log4j2/pull/68#discussion_r109441172
  
--- Diff: 
log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/TimeBasedTriggeringPolicy.java
 ---
@@ -84,15 +91,18 @@ public boolean isTriggeringEvent(final LogEvent event) {
  * Creates a TimeBasedTriggeringPolicy.
  * @param interval The interval between rollovers.
  * @param modulate If true the time will be rounded to occur on a 
boundary aligned with the increment.
+ * @param maxRandomDelay If non-zero the rolling will be delayed by a 
random amount of time, up to the specified value (in seconds)  
  * @return a TimeBasedTriggeringPolicy.
  */
 @PluginFactory
 public static TimeBasedTriggeringPolicy createPolicy(
 @PluginAttribute("interval") final String interval,
-@PluginAttribute("modulate") final String modulate) {
+@PluginAttribute("modulate") final String modulate,
+@PluginAttribute("maxRandomDelay") final int maxRandomDelay) {
--- End diff --

Done


> Add an optional random delay in TimeBasedTriggeringPolicy
> -
>
> Key: LOG4J2-1855
> URL: https://issues.apache.org/jira/browse/LOG4J2-1855
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Affects Versions: 2.8.1
>Reporter: Anthony Maire
>
> When there are lots of JVM on the same physical host configured to rolling 
> their log file with a TimeBasedTriggeringPolicy, it will create a temporary 
> load that can impact the behavior of the applications since all JVM will roll 
> and compress the old file at the same time
> The purpose of this enhancement is to add an additional property on 
> TimeBasedTriggeringPolicy to delay the rolling by a random amount of time to 
> avoid that massive simultaneous rolling.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Scala

[Matt Sicker]

We don't have to use maven-site-plugin to generate the Scala site. That's
just the easy way to do it in theory, though I find it cumbersome. If you
know of any better documentation generator that we could use there (or even
in log4j-core), please let us know!

On 3 April 2017 at 04:06, Mikael Ståldal  wrote:

> Using SBT would help to avoid having to duplicate the source code for each
> Scala version. However, I'm not sure about how to do the Maven site stuff
> with SBT.
>
> On Sun, Apr 2, 2017 at 10:41 PM, Matt Sicker  wrote:
>
>> I'm not too experienced with it, but now that the Scala APIs are in their
>> own repo, it might be easier to use SBT instead of Maven for it. Just a
>> thought for a future release.
>>
>> On 2 April 2017 at 15:27, Matt Sicker  wrote:
>>
>>> And don't mind the site commit I made earlier. That was from a snapshot,
>>> so I have to commit it again anyways.
>>>
>>> On 2 April 2017 at 15:25, Matt Sicker  wrote:
>>>
 No, I figured I'd do log4j-core first. Still working on that right now,
 had to restart the build from the tag because a test randomly decided to
 fail at the worst possible time.

 On 2 April 2017 at 15:11, Ralph Goers 
 wrote:

> Has a Scala release been performed? The site needs to be deployed
> before I can modify the log4j page(s) to point to it.
>
> Ralph
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>


 --
 Matt Sicker 

>>>
>>>
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>



-- 
Matt Sicker 

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953544#comment-15953544
 ] 

ASF GitHub Bot commented on LOG4J2-1864:


Github user jvz commented on a diff in the pull request:

https://github.com/apache/logging-log4j2/pull/62#discussion_r109425995
  
--- Diff: 
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/mongodb/MongoDbProvider.java
 ---
@@ -97,6 +103,8 @@ public String toString() {
 @PluginFactory
 public static MongoDbProvider createNoSqlProvider(
 @PluginAttribute("collectionName") final String collectionName,
+@PluginAttribute(value = "capped", defaultBoolean = false) 
final Boolean isCapped,
--- End diff --

Take a look at CassandraAppender for how to write a plugin builder class. 
Any manual type conversion in the factory method can be generally updated to 
use the proper types as conversions for most common types is supported (and new 
types can always be added as appropriate; see InetAddress et al. added for 
CassandraAppender).


> Support capped collection for MongoDB Log-Provider
> --
>
> Key: LOG4J2-1864
> URL: https://issues.apache.org/jira/browse/LOG4J2-1864
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Matt
>
> MongoDB supports sth. called capped collections. If the 
> nosql-mongodb-appender supports this feature, the mongodb-collection could 
> never "overflow" and stick to a defined maximum size.
> see [pull request 62|https://github.com/apache/logging-log4j2/pull/62] for 
> more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Scala

[Mikael Ståldal]

Using SBT would help to avoid having to duplicate the source code for each
Scala version. However, I'm not sure about how to do the Maven site stuff
with SBT.

On Sun, Apr 2, 2017 at 10:41 PM, Matt Sicker  wrote:

> I'm not too experienced with it, but now that the Scala APIs are in their
> own repo, it might be easier to use SBT instead of Maven for it. Just a
> thought for a future release.
>
> On 2 April 2017 at 15:27, Matt Sicker  wrote:
>
>> And don't mind the site commit I made earlier. That was from a snapshot,
>> so I have to commit it again anyways.
>>
>> On 2 April 2017 at 15:25, Matt Sicker  wrote:
>>
>>> No, I figured I'd do log4j-core first. Still working on that right now,
>>> had to restart the build from the tag because a test randomly decided to
>>> fail at the worst possible time.
>>>
>>> On 2 April 2017 at 15:11, Ralph Goers 
>>> wrote:
>>>
 Has a Scala release been performed? The site needs to be deployed
 before I can modify the log4j page(s) to point to it.

 Ralph

 -
 To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
 For additional commands, e-mail: log4j-dev-h...@logging.apache.org


>>>
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> Matt Sicker 
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Re: [VOTE] Release Log4j 2.8.2 rc1

[Mikael Ståldal]

+1

Works for me.

On Sun, Apr 2, 2017 at 11:08 PM, Matt Sicker  wrote:

> This is a vote to release Log4j 2.8.2. Please download, test, and cast
> your votes on this mailing list.
>
> [] +1, release the artifacts
>
> [] -1, don't release because...
>
> The vote will remain open for 72 hours at least. All votes are welcome,
> and we encourage everyone to test the release, but only Logging PMC votes
> are counted towards the "official" vote count. As always, at least 3 +1s
> and more +1s than -1s are required.
>
> Changes in this version include:
>
> New
> Features
>
>- LOG4J2-1863 : Add
>support for filtering input in TcpSocketServer and UdpSocketServer.
>- LOG4J2-1848 : Add
>JSON encoding support to EncodingPatternConverter %encode{}.
>- LOG4J2-1843 : Add
>support for appending common suffix to each line of throwable stack trace.
>Thanks to Zilong Song.
>- LOG4J2-1838 : Add
>support for appending common suffix to each line of extended and root
>throwable stack trace. Thanks to Zilong Song.
>
>
> Fixed
> Bugs
>
>- LOG4J2-1861 : Fix
>JavaDoc on org.apache.logging.log4j.ThreadContext about inheritance.
>- LOG4J2-1862 : Fix
>JavaDoc about @Order and OrderComparator ordering. Thanks to wangyuntao.
>- LOG4J2-1849 :
>Fixed daylight savings time issue with FixedDateFormat.
>- LOG4J2-1850 : Fix
>CassandraRule and unit tests on Windows. Thanks to Ludovic Hochet.
>- LOG4J2-1840 : Fix
>typo in %replace converter documentation. Thanks to Pradeep Balasundaram.
>- LOG4J2-1846 :
>Handle when LogEvent.getLoggerName() returns null in
>LoggerNameLevelRewritePolicy.
>- LOG4J2-1845 :
>Handle when LogEvent.getLoggerName() returns null in KafkaAppender.
>- LOG4J2-1853 : The
>default value of RandomAccessFileAppender.Builder append field is
>wrong. Thanks to wangyuntao.
>- LOG4J2-1835 : Fix
>documentation about the licensing for JeroMQ.
>- LOG4J2-1836 :
>Update the API version to 2.6.0.
>- LOG4J2-1831 :
>NullPointerException in HtmlLayout. Thanks to Edward Serebrinskiy.
>- LOG4J2-1820 :
>Log4j 2.8 can lose exceptions when a security manager is present. Thanks to
>Jason Tedor.
>
>
> 
> Changes
>
>- LOG4J2-1827 :
>Move integration tests to their own module to speed up build.
>- LOG4J2-1856 :
>Update Jackson from 2.8.6 to 2.8.7.
>
> Tag: log4j-2.8.2-rc1
>
> Web site: https://rgoers.github.io/log4j2-site/
>
> Artifacts: https://repository.apache.org/content/
> repositories/orgapachelogging-1026/
>
> You can download all the artifacts via the command line:
>
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1026/
>
> --
> Matt Sicker 
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953145#comment-15953145
 ] 

ASF GitHub Bot commented on LOG4J2-1864:


Github user codescale commented on a diff in the pull request:

https://github.com/apache/logging-log4j2/pull/62#discussion_r109365941
  
--- Diff: 
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/mongodb/MongoDbProvider.java
 ---
@@ -97,6 +103,8 @@ public String toString() {
 @PluginFactory
 public static MongoDbProvider createNoSqlProvider(
 @PluginAttribute("collectionName") final String collectionName,
+@PluginAttribute(value = "capped", defaultBoolean = false) 
final Boolean isCapped,
--- End diff --

Hi @jvz, I changed the `Boolean` member to be a primitive type. But I don't 
know what kind of Builder you mean for the attributes? Does this builder exist 
for the MongoDbProvider? Cheers Matt


> Support capped collection for MongoDB Log-Provider
> --
>
> Key: LOG4J2-1864
> URL: https://issues.apache.org/jira/browse/LOG4J2-1864
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Matt
>
> MongoDB supports sth. called capped collections. If the 
> nosql-mongodb-appender supports this feature, the mongodb-collection could 
> never "overflow" and stick to a defined maximum size.
> see [pull request 62|https://github.com/apache/logging-log4j2/pull/62] for 
> more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1855) Add an optional random delay in TimeBasedTriggeringPolicy

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953115#comment-15953115
 ] 

ASF GitHub Bot commented on LOG4J2-1855:


Github user m-anthony commented on a diff in the pull request:

https://github.com/apache/logging-log4j2/pull/68#discussion_r109361653
  
--- Diff: 
log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/TimeBasedTriggeringPolicy.java
 ---
@@ -84,15 +91,18 @@ public boolean isTriggeringEvent(final LogEvent event) {
  * Creates a TimeBasedTriggeringPolicy.
  * @param interval The interval between rollovers.
  * @param modulate If true the time will be rounded to occur on a 
boundary aligned with the increment.
+ * @param maxRandomDelay If non-zero the rolling will be delayed by a 
random amount of time, up to the specified value (in seconds)  
  * @return a TimeBasedTriggeringPolicy.
  */
 @PluginFactory
 public static TimeBasedTriggeringPolicy createPolicy(
 @PluginAttribute("interval") final String interval,
-@PluginAttribute("modulate") final String modulate) {
+@PluginAttribute("modulate") final String modulate,
+@PluginAttribute("maxRandomDelay") final int maxRandomDelay) {
--- End diff --

OK I will do that :+1: 


> Add an optional random delay in TimeBasedTriggeringPolicy
> -
>
> Key: LOG4J2-1855
> URL: https://issues.apache.org/jira/browse/LOG4J2-1855
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Affects Versions: 2.8.1
>Reporter: Anthony Maire
>
> When there are lots of JVM on the same physical host configured to rolling 
> their log file with a TimeBasedTriggeringPolicy, it will create a temporary 
> load that can impact the behavior of the applications since all JVM will roll 
> and compress the old file at the same time
> The purpose of this enhancement is to add an additional property on 
> TimeBasedTriggeringPolicy to delay the rolling by a random amount of time to 
> avoid that massive simultaneous rolling.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org