subject:"\[jira\] \[Commented\] $LOG4J2\-1297$ Document \"gc\-free\" configuration and performance"

Great, thanks for the explanation! I can't wait to use this set-up in
production.

On 18 April 2016 at 17:48, Remko Popma  wrote:

> Yes, in that case the threadpool doesn't outlive the application so
> there's no chance of memory leaks.
>
> Not sure if Tomcat also can be configured to have separate threadpools per
> web app and to refresh the thread pool on web app undeploy/redeploy.
>
> Sent from my iPhone
>
> On 2016/04/19, at 3:27, Matt Sicker  wrote:
>
> But would you say it's safe to use ThreadLocal when you don't undeploy or
> redeploy web apps? Like if you always restart Tomcat when you redeploy,
> would it be safe to use ThreadLocal in such a scenario?
>
> On 18 April 2016 at 09:49, Remko Popma  wrote:
>
>> The problem is that values stored in ThreadLocals may live longer than
>> the web application since the threads that hold these values are in a pool
>> and the threads live on after the web application is undeployed. If the
>> value is a JDK class this is not a problem.
>>
>> If the value is a class that is defined in your webapp (or a library of
>> the web app) then holding on the the value means the class cannot be
>> garbage-collected. And voila, we have a memory leak...
>>
>> Garbage-free logging makes liberal use of ThreadLocals with non-JDK
>> values. If the web container separates the thread pools between
>> applications and restarts the thread pool with the web application, the
>> above memory leak does not occur. (I believe this is what WebSphere does.)
>>
>> Eventually we may be able to address this with LOG4J2-1116
>> .
>>
>>
>>
>> On Mon, Apr 18, 2016 at 11:04 PM, Matt Sicker  wrote:
>>
>>> So is this only bad to use when you have multiple wars on a single
>>> Tomcat, or is it bad for when you try to undeploy, or is there another
>>> issue here?
>>>
>>> On 18 April 2016 at 09:01, Remko Popma  wrote:
>>>
 Yes but if this is wrong because there is no threadpool or so, then you
 can use System property "log4j2.is.webapp" to tell Log4j that it
 should consider your app a non-webapp.

 On Mon, Apr 18, 2016 at 10:59 PM, Matt Sicker  wrote:

> Would an embedded Tomcat/Jetty a la Spring Boot really be considered a
> web application?
>
> On 18 April 2016 at 08:56, Remko Popma  wrote:
>
>> When I finish performance testing I will add graphs to the
>> Performance section of the gc-free manual page so that users can make an
>> informed decision. (The below one is an example.)
>>
>> So far, it seems that even with the garbage-free logging enabled,
>> synchronous logging throughput (the green line) is usually slightly 
>> faster
>> than it was with 2.5 (the purple line). So I think making garbage-free 
>> the
>> default is acceptable. Also, users who care about logging throughput will
>> be logging asynchronously, not synchronously: this scales much better 
>> with
>> the number of application threads.
>>
>>
>> 
>> 
>>
>> On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal <
>> mikael.stal...@magine.com> wrote:
>>
>>> Is it wise to enable by default given that "multi-threaded
>>> applications that use synchronous logging may see worse performance"?
>>>
>>> On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma 
>>> wrote:
>>>
 Enabled, except for web apps; for those log4j will be low garbage.

 See the first paragraph of the Configuration section in the manual
 page.

 Please let me know if this is not clear. (The fact that you asked
 means this probably needs improvement...)

 Sent from my iPhone

 On 2016/04/18, at 20:18, Mikael Ståldal 
 wrote:

 Will garbage-free logging be enabled or disabled by default?

 On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) <
 j...@apache.org> wrote:

>
> [
> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
> ]
>
> Remko Popma commented on LOG4J2-1297:
> -
>
> TODO allocate many temporary objects -> allocate temporary objects
>
> TODO multi-threaded applications that use synchronous logging may
> see worse performance: the lock that was previously only around the IO
> operation is widened to include the text formatting and conversion to
> bytes. -> _synchronous_ logging performance may be worse for 
> multi-threaded
> applications in this mode due to synchronization on the shared 
> buffer. If
> your application is multi-threaded and logging performance is 
> important,
> consider using Async Loggers.
>
> T

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

Yes, in that case the threadpool doesn't outlive the application so there's no 
chance of memory leaks. 

Not sure if Tomcat also can be configured to have separate threadpools per web 
app and to refresh the thread pool on web app undeploy/redeploy. 

Sent from my iPhone

> On 2016/04/19, at 3:27, Matt Sicker  wrote:
> 
> But would you say it's safe to use ThreadLocal when you don't undeploy or 
> redeploy web apps? Like if you always restart Tomcat when you redeploy, would 
> it be safe to use ThreadLocal in such a scenario?
> 
>> On 18 April 2016 at 09:49, Remko Popma  wrote:
>> The problem is that values stored in ThreadLocals may live longer than the 
>> web application since the threads that hold these values are in a pool and 
>> the threads live on after the web application is undeployed. If the value is 
>> a JDK class this is not a problem.
>> 
>> If the value is a class that is defined in your webapp (or a library of the 
>> web app) then holding on the the value means the class cannot be 
>> garbage-collected. And voila, we have a memory leak...
>> 
>> Garbage-free logging makes liberal use of ThreadLocals with non-JDK values. 
>> If the web container separates the thread pools between applications and 
>> restarts the thread pool with the web application, the above memory leak 
>> does not occur. (I believe this is what WebSphere does.)
>> 
>> Eventually we may be able to address this with LOG4J2-1116.
>> 
>> 
>> 
>>> On Mon, Apr 18, 2016 at 11:04 PM, Matt Sicker  wrote:
>>> So is this only bad to use when you have multiple wars on a single Tomcat, 
>>> or is it bad for when you try to undeploy, or is there another issue here?
>>> 
 On 18 April 2016 at 09:01, Remko Popma  wrote:
 Yes but if this is wrong because there is no threadpool or so, then you 
 can use System property "log4j2.is.webapp" to tell Log4j that it should 
 consider your app a non-webapp.
 
> On Mon, Apr 18, 2016 at 10:59 PM, Matt Sicker  wrote:
> Would an embedded Tomcat/Jetty a la Spring Boot really be considered a 
> web application?
> 
>> On 18 April 2016 at 08:56, Remko Popma  wrote:
>> When I finish performance testing I will add graphs to the Performance 
>> section of the gc-free manual page so that users can make an informed 
>> decision. (The below one is an example.)
>> 
>> So far, it seems that even with the garbage-free logging enabled, 
>> synchronous logging throughput (the green line) is usually slightly 
>> faster than it was with 2.5 (the purple line). So I think making 
>> garbage-free the default is acceptable. Also, users who care about 
>> logging throughput will be logging asynchronously, not synchronously: 
>> this scales much better with the number of application threads.
>> 
>> 
>> 
>> 
>> 
>>> On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal 
>>>  wrote:
>>> Is it wise to enable by default given that "multi-threaded applications 
>>> that use synchronous logging may see worse performance"?
>>> 
 On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma  
 wrote:
 Enabled, except for web apps; for those log4j will be low garbage. 
 
 See the first paragraph of the Configuration section in the manual 
 page. 
 
 Please let me know if this is not clear. (The fact that you asked 
 means this probably needs improvement...)
 
 Sent from my iPhone
 
> On 2016/04/18, at 20:18, Mikael Ståldal  
> wrote:
> 
> Will garbage-free logging be enabled or disabled by default?
> 
>> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) 
>>  wrote:
>> 
>> [ 
>> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
>>  ]
>> 
>> Remko Popma commented on LOG4J2-1297:
>> -
>> 
>> TODO allocate many temporary objects -> allocate temporary objects
>> 
>> TODO multi-threaded applications that use synchronous logging may 
>> see worse performance: the lock that was previously only around the 
>> IO operation is widened to include the text formatting and 
>> conversion to bytes. -> _synchronous_ logging performance may be 
>> worse for multi-threaded applications in this mode due to 
>> synchronization on the shared buffer. If your application is 
>> multi-threaded and logging performance is important, consider using 
>> Async Loggers.
>> 
>> TODO Caution: Only dates in the predefined formats are garbage-free 
>> -> Caution: Only the predefined date formats are garbage-free
>> 
>> TODO "(Note that Log4j may call toString() on message and parameter

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

But would you say it's safe to use ThreadLocal when you don't undeploy or
redeploy web apps? Like if you always restart Tomcat when you redeploy,
would it be safe to use ThreadLocal in such a scenario?

On 18 April 2016 at 09:49, Remko Popma  wrote:

> The problem is that values stored in ThreadLocals may live longer than the
> web application since the threads that hold these values are in a pool and
> the threads live on after the web application is undeployed. If the value
> is a JDK class this is not a problem.
>
> If the value is a class that is defined in your webapp (or a library of
> the web app) then holding on the the value means the class cannot be
> garbage-collected. And voila, we have a memory leak...
>
> Garbage-free logging makes liberal use of ThreadLocals with non-JDK
> values. If the web container separates the thread pools between
> applications and restarts the thread pool with the web application, the
> above memory leak does not occur. (I believe this is what WebSphere does.)
>
> Eventually we may be able to address this with LOG4J2-1116
> .
>
>
>
> On Mon, Apr 18, 2016 at 11:04 PM, Matt Sicker  wrote:
>
>> So is this only bad to use when you have multiple wars on a single
>> Tomcat, or is it bad for when you try to undeploy, or is there another
>> issue here?
>>
>> On 18 April 2016 at 09:01, Remko Popma  wrote:
>>
>>> Yes but if this is wrong because there is no threadpool or so, then you
>>> can use System property "log4j2.is.webapp" to tell Log4j that it should
>>> consider your app a non-webapp.
>>>
>>> On Mon, Apr 18, 2016 at 10:59 PM, Matt Sicker  wrote:
>>>
 Would an embedded Tomcat/Jetty a la Spring Boot really be considered a
 web application?

 On 18 April 2016 at 08:56, Remko Popma  wrote:

> When I finish performance testing I will add graphs to the Performance
> section of the gc-free manual page so that users can make an informed
> decision. (The below one is an example.)
>
> So far, it seems that even with the garbage-free logging enabled,
> synchronous logging throughput (the green line) is usually slightly faster
> than it was with 2.5 (the purple line). So I think making garbage-free the
> default is acceptable. Also, users who care about logging throughput will
> be logging asynchronously, not synchronously: this scales much better with
> the number of application threads.
>
>
>
> 
>
> On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal <
> mikael.stal...@magine.com> wrote:
>
>> Is it wise to enable by default given that "multi-threaded
>> applications that use synchronous logging may see worse performance"?
>>
>> On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma 
>> wrote:
>>
>>> Enabled, except for web apps; for those log4j will be low garbage.
>>>
>>> See the first paragraph of the Configuration section in the manual
>>> page.
>>>
>>> Please let me know if this is not clear. (The fact that you asked
>>> means this probably needs improvement...)
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/04/18, at 20:18, Mikael Ståldal 
>>> wrote:
>>>
>>> Will garbage-free logging be enabled or disabled by default?
>>>
>>> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) >> > wrote:
>>>

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

 Remko Popma commented on LOG4J2-1297:
 -

 TODO allocate many temporary objects -> allocate temporary objects

 TODO multi-threaded applications that use synchronous logging may
 see worse performance: the lock that was previously only around the IO
 operation is widened to include the text formatting and conversion to
 bytes. -> _synchronous_ logging performance may be worse for 
 multi-threaded
 applications in this mode due to synchronization on the shared buffer. 
 If
 your application is multi-threaded and logging performance is 
 important,
 consider using Async Loggers.

 TODO Caution: Only dates in the predefined formats are garbage-free
 -> Caution: Only the predefined date formats are garbage-free

 TODO "(Note that Log4j may call toString() on message and parameter
 objects when garbage-free logging is disabled because system property
 log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
 toString() on message and parameter objects when garbage-free logging 
 is
 disabled (when system property log4j2.enable.threadlocals is set to
 "false".)

 TODO "made an effort to make logg

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

The problem is that values stored in ThreadLocals may live longer than the
web application since the threads that hold these values are in a pool and
the threads live on after the web application is undeployed. If the value
is a JDK class this is not a problem.

If the value is a class that is defined in your webapp (or a library of the
web app) then holding on the the value means the class cannot be
garbage-collected. And voila, we have a memory leak...

Garbage-free logging makes liberal use of ThreadLocals with non-JDK values.
If the web container separates the thread pools between applications and
restarts the thread pool with the web application, the above memory leak
does not occur. (I believe this is what WebSphere does.)

Eventually we may be able to address this with LOG4J2-1116
.



On Mon, Apr 18, 2016 at 11:04 PM, Matt Sicker  wrote:

> So is this only bad to use when you have multiple wars on a single Tomcat,
> or is it bad for when you try to undeploy, or is there another issue here?
>
> On 18 April 2016 at 09:01, Remko Popma  wrote:
>
>> Yes but if this is wrong because there is no threadpool or so, then you
>> can use System property "log4j2.is.webapp" to tell Log4j that it should
>> consider your app a non-webapp.
>>
>> On Mon, Apr 18, 2016 at 10:59 PM, Matt Sicker  wrote:
>>
>>> Would an embedded Tomcat/Jetty a la Spring Boot really be considered a
>>> web application?
>>>
>>> On 18 April 2016 at 08:56, Remko Popma  wrote:
>>>
 When I finish performance testing I will add graphs to the Performance
 section of the gc-free manual page so that users can make an informed
 decision. (The below one is an example.)

 So far, it seems that even with the garbage-free logging enabled,
 synchronous logging throughput (the green line) is usually slightly faster
 than it was with 2.5 (the purple line). So I think making garbage-free the
 default is acceptable. Also, users who care about logging throughput will
 be logging asynchronously, not synchronously: this scales much better with
 the number of application threads.



 

 On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal <
 mikael.stal...@magine.com> wrote:

> Is it wise to enable by default given that "multi-threaded
> applications that use synchronous logging may see worse performance"?
>
> On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma 
> wrote:
>
>> Enabled, except for web apps; for those log4j will be low garbage.
>>
>> See the first paragraph of the Configuration section in the manual
>> page.
>>
>> Please let me know if this is not clear. (The fact that you asked
>> means this probably needs improvement...)
>>
>> Sent from my iPhone
>>
>> On 2016/04/18, at 20:18, Mikael Ståldal 
>> wrote:
>>
>> Will garbage-free logging be enabled or disabled by default?
>>
>> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) 
>> wrote:
>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
>>> ]
>>>
>>> Remko Popma commented on LOG4J2-1297:
>>> -
>>>
>>> TODO allocate many temporary objects -> allocate temporary objects
>>>
>>> TODO multi-threaded applications that use synchronous logging may
>>> see worse performance: the lock that was previously only around the IO
>>> operation is widened to include the text formatting and conversion to
>>> bytes. -> _synchronous_ logging performance may be worse for 
>>> multi-threaded
>>> applications in this mode due to synchronization on the shared buffer. 
>>> If
>>> your application is multi-threaded and logging performance is important,
>>> consider using Async Loggers.
>>>
>>> TODO Caution: Only dates in the predefined formats are garbage-free
>>> -> Caution: Only the predefined date formats are garbage-free
>>>
>>> TODO "(Note that Log4j may call toString() on message and parameter
>>> objects when garbage-free logging is disabled because system property
>>> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
>>> toString() on message and parameter objects when garbage-free logging is
>>> disabled (when system property log4j2.enable.threadlocals is set to
>>> "false".)
>>>
>>> TODO "made an effort to make logging code garbage-free" -> "made an
>>> effort to make logging garbage-free"
>>>
>>>
>>> > Document "gc-free" configuration and performance
>>> > 
>>> >
>>> > Key: LOG4J2-1297
>>> > URL:
>>> https://issues.apache.org/jira/browse/LOG4J2-1297
>>> > Project: Log4j 2
>>>

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

So is this only bad to use when you have multiple wars on a single Tomcat,
or is it bad for when you try to undeploy, or is there another issue here?

On 18 April 2016 at 09:01, Remko Popma  wrote:

> Yes but if this is wrong because there is no threadpool or so, then you
> can use System property "log4j2.is.webapp" to tell Log4j that it should
> consider your app a non-webapp.
>
> On Mon, Apr 18, 2016 at 10:59 PM, Matt Sicker  wrote:
>
>> Would an embedded Tomcat/Jetty a la Spring Boot really be considered a
>> web application?
>>
>> On 18 April 2016 at 08:56, Remko Popma  wrote:
>>
>>> When I finish performance testing I will add graphs to the Performance
>>> section of the gc-free manual page so that users can make an informed
>>> decision. (The below one is an example.)
>>>
>>> So far, it seems that even with the garbage-free logging enabled,
>>> synchronous logging throughput (the green line) is usually slightly faster
>>> than it was with 2.5 (the purple line). So I think making garbage-free the
>>> default is acceptable. Also, users who care about logging throughput will
>>> be logging asynchronously, not synchronously: this scales much better with
>>> the number of application threads.
>>>
>>>
>>>
>>> 
>>>
>>> On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal <
>>> mikael.stal...@magine.com> wrote:
>>>
 Is it wise to enable by default given that "multi-threaded
 applications that use synchronous logging may see worse performance"?

 On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma 
 wrote:

> Enabled, except for web apps; for those log4j will be low garbage.
>
> See the first paragraph of the Configuration section in the manual
> page.
>
> Please let me know if this is not clear. (The fact that you asked
> means this probably needs improvement...)
>
> Sent from my iPhone
>
> On 2016/04/18, at 20:18, Mikael Ståldal 
> wrote:
>
> Will garbage-free logging be enabled or disabled by default?
>
> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) 
> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
>> ]
>>
>> Remko Popma commented on LOG4J2-1297:
>> -
>>
>> TODO allocate many temporary objects -> allocate temporary objects
>>
>> TODO multi-threaded applications that use synchronous logging may see
>> worse performance: the lock that was previously only around the IO
>> operation is widened to include the text formatting and conversion to
>> bytes. -> _synchronous_ logging performance may be worse for 
>> multi-threaded
>> applications in this mode due to synchronization on the shared buffer. If
>> your application is multi-threaded and logging performance is important,
>> consider using Async Loggers.
>>
>> TODO Caution: Only dates in the predefined formats are garbage-free
>> -> Caution: Only the predefined date formats are garbage-free
>>
>> TODO "(Note that Log4j may call toString() on message and parameter
>> objects when garbage-free logging is disabled because system property
>> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
>> toString() on message and parameter objects when garbage-free logging is
>> disabled (when system property log4j2.enable.threadlocals is set to
>> "false".)
>>
>> TODO "made an effort to make logging code garbage-free" -> "made an
>> effort to make logging garbage-free"
>>
>>
>> > Document "gc-free" configuration and performance
>> > 
>> >
>> > Key: LOG4J2-1297
>> > URL:
>> https://issues.apache.org/jira/browse/LOG4J2-1297
>> > Project: Log4j 2
>> >  Issue Type: New Feature
>> >  Components: Documentation
>> >Affects Versions: 2.5
>> >Reporter: Remko Popma
>> >Assignee: Remko Popma
>> > Fix For: 2.6
>> >
>> > Attachments: log4j-2.5-FlightRecording.png,
>> log4j-2.6-FlightRecording.png
>> >
>> >
>> > Update the site with a description of which configurations are
>> GC-free (i.e., that don't create temporary objects in steady running 
>> state).
>> > Currently that means
>> > * Loggers are all asynchronous (Log4jContextSelector is set to
>> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
>> > * The configuration does not contain a  section.
>> > * The "steady-state" appenders are either RandomAccessFile or
>> RollingRandomAccessFile Appenders (logging to any other appender will 
>> cause
>> temporary objects to be created - including ConsoleAppender).
>> > * The Layout is a Patter

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

Yes but if this is wrong because there is no threadpool or so, then you can
use System property "log4j2.is.webapp" to tell Log4j that it should
consider your app a non-webapp.

On Mon, Apr 18, 2016 at 10:59 PM, Matt Sicker  wrote:

> Would an embedded Tomcat/Jetty a la Spring Boot really be considered a web
> application?
>
> On 18 April 2016 at 08:56, Remko Popma  wrote:
>
>> When I finish performance testing I will add graphs to the Performance
>> section of the gc-free manual page so that users can make an informed
>> decision. (The below one is an example.)
>>
>> So far, it seems that even with the garbage-free logging enabled,
>> synchronous logging throughput (the green line) is usually slightly faster
>> than it was with 2.5 (the purple line). So I think making garbage-free the
>> default is acceptable. Also, users who care about logging throughput will
>> be logging asynchronously, not synchronously: this scales much better with
>> the number of application threads.
>>
>>
>>
>> 
>>
>> On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal <
>> mikael.stal...@magine.com> wrote:
>>
>>> Is it wise to enable by default given that "multi-threaded applications
>>> that use synchronous logging may see worse performance"?
>>>
>>> On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma 
>>> wrote:
>>>
 Enabled, except for web apps; for those log4j will be low garbage.

 See the first paragraph of the Configuration section in the manual
 page.

 Please let me know if this is not clear. (The fact that you asked means
 this probably needs improvement...)

 Sent from my iPhone

 On 2016/04/18, at 20:18, Mikael Ståldal 
 wrote:

 Will garbage-free logging be enabled or disabled by default?

 On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) 
 wrote:

>
> [
> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
> ]
>
> Remko Popma commented on LOG4J2-1297:
> -
>
> TODO allocate many temporary objects -> allocate temporary objects
>
> TODO multi-threaded applications that use synchronous logging may see
> worse performance: the lock that was previously only around the IO
> operation is widened to include the text formatting and conversion to
> bytes. -> _synchronous_ logging performance may be worse for 
> multi-threaded
> applications in this mode due to synchronization on the shared buffer. If
> your application is multi-threaded and logging performance is important,
> consider using Async Loggers.
>
> TODO Caution: Only dates in the predefined formats are garbage-free ->
> Caution: Only the predefined date formats are garbage-free
>
> TODO "(Note that Log4j may call toString() on message and parameter
> objects when garbage-free logging is disabled because system property
> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
> toString() on message and parameter objects when garbage-free logging is
> disabled (when system property log4j2.enable.threadlocals is set to
> "false".)
>
> TODO "made an effort to make logging code garbage-free" -> "made an
> effort to make logging garbage-free"
>
>
> > Document "gc-free" configuration and performance
> > 
> >
> > Key: LOG4J2-1297
> > URL:
> https://issues.apache.org/jira/browse/LOG4J2-1297
> > Project: Log4j 2
> >  Issue Type: New Feature
> >  Components: Documentation
> >Affects Versions: 2.5
> >Reporter: Remko Popma
> >Assignee: Remko Popma
> > Fix For: 2.6
> >
> > Attachments: log4j-2.5-FlightRecording.png,
> log4j-2.6-FlightRecording.png
> >
> >
> > Update the site with a description of which configurations are
> GC-free (i.e., that don't create temporary objects in steady running 
> state).
> > Currently that means
> > * Loggers are all asynchronous (Log4jContextSelector is set to
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> > * The configuration does not contain a  section.
> > * The "steady-state" appenders are either RandomAccessFile or
> RollingRandomAccessFile Appenders (logging to any other appender will 
> cause
> temporary objects to be created - including ConsoleAppender).
> > * The Layout is a PatternLayout that uses one of the pre-defined
> date formats, does not have any regular expression replacements, and does
> not have lookups (TODO: may need to restrict this further).
> > * The thread name is cached (this is the [default|
> https://issues.apache.org/jira/browse/LOG4J2-467]). Running with
>>

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

Would an embedded Tomcat/Jetty a la Spring Boot really be considered a web
application?

On 18 April 2016 at 08:56, Remko Popma  wrote:

> When I finish performance testing I will add graphs to the Performance
> section of the gc-free manual page so that users can make an informed
> decision. (The below one is an example.)
>
> So far, it seems that even with the garbage-free logging enabled,
> synchronous logging throughput (the green line) is usually slightly faster
> than it was with 2.5 (the purple line). So I think making garbage-free the
> default is acceptable. Also, users who care about logging throughput will
> be logging asynchronously, not synchronously: this scales much better with
> the number of application threads.
>
>
>
> 
>
> On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal  > wrote:
>
>> Is it wise to enable by default given that "multi-threaded applications
>> that use synchronous logging may see worse performance"?
>>
>> On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma 
>> wrote:
>>
>>> Enabled, except for web apps; for those log4j will be low garbage.
>>>
>>> See the first paragraph of the Configuration section in the manual page.
>>>
>>> Please let me know if this is not clear. (The fact that you asked means
>>> this probably needs improvement...)
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/04/18, at 20:18, Mikael Ståldal 
>>> wrote:
>>>
>>> Will garbage-free logging be enabled or disabled by default?
>>>
>>> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) 
>>> wrote:
>>>

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

 Remko Popma commented on LOG4J2-1297:
 -

 TODO allocate many temporary objects -> allocate temporary objects

 TODO multi-threaded applications that use synchronous logging may see
 worse performance: the lock that was previously only around the IO
 operation is widened to include the text formatting and conversion to
 bytes. -> _synchronous_ logging performance may be worse for multi-threaded
 applications in this mode due to synchronization on the shared buffer. If
 your application is multi-threaded and logging performance is important,
 consider using Async Loggers.

 TODO Caution: Only dates in the predefined formats are garbage-free ->
 Caution: Only the predefined date formats are garbage-free

 TODO "(Note that Log4j may call toString() on message and parameter
 objects when garbage-free logging is disabled because system property
 log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
 toString() on message and parameter objects when garbage-free logging is
 disabled (when system property log4j2.enable.threadlocals is set to
 "false".)

 TODO "made an effort to make logging code garbage-free" -> "made an
 effort to make logging garbage-free"


 > Document "gc-free" configuration and performance
 > 
 >
 > Key: LOG4J2-1297
 > URL:
 https://issues.apache.org/jira/browse/LOG4J2-1297
 > Project: Log4j 2
 >  Issue Type: New Feature
 >  Components: Documentation
 >Affects Versions: 2.5
 >Reporter: Remko Popma
 >Assignee: Remko Popma
 > Fix For: 2.6
 >
 > Attachments: log4j-2.5-FlightRecording.png,
 log4j-2.6-FlightRecording.png
 >
 >
 > Update the site with a description of which configurations are
 GC-free (i.e., that don't create temporary objects in steady running 
 state).
 > Currently that means
 > * Loggers are all asynchronous (Log4jContextSelector is set to
 org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
 > * The configuration does not contain a  section.
 > * The "steady-state" appenders are either RandomAccessFile or
 RollingRandomAccessFile Appenders (logging to any other appender will cause
 temporary objects to be created - including ConsoleAppender).
 > * The Layout is a PatternLayout that uses one of the pre-defined date
 formats, does not have any regular expression replacements, and does not
 have lookups (TODO: may need to restrict this further).
 > * The thread name is cached (this is the [default|
 https://issues.apache.org/jira/browse/LOG4J2-467]). Running with
 -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
 > * In user code, when logging a parameterized message, the number of
 parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
 > * In user code, when logging a parameterized message, parameters of
 primitive type are boxed in a reused StringBuilder (Log4j provides a
 utility to make this

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

When I finish performance testing I will add graphs to the Performance
section of the gc-free manual page so that users can make an informed
decision. (The below one is an example.)

So far, it seems that even with the garbage-free logging enabled,
synchronous logging throughput (the green line) is usually slightly faster
than it was with 2.5 (the purple line). So I think making garbage-free the
default is acceptable. Also, users who care about logging throughput will
be logging asynchronously, not synchronously: this scales much better with
the number of application threads.





On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal 
wrote:

> Is it wise to enable by default given that "multi-threaded applications
> that use synchronous logging may see worse performance"?
>
> On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma 
> wrote:
>
>> Enabled, except for web apps; for those log4j will be low garbage.
>>
>> See the first paragraph of the Configuration section in the manual page.
>>
>> Please let me know if this is not clear. (The fact that you asked means
>> this probably needs improvement...)
>>
>> Sent from my iPhone
>>
>> On 2016/04/18, at 20:18, Mikael Ståldal 
>> wrote:
>>
>> Will garbage-free logging be enabled or disabled by default?
>>
>> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) 
>> wrote:
>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
>>> ]
>>>
>>> Remko Popma commented on LOG4J2-1297:
>>> -
>>>
>>> TODO allocate many temporary objects -> allocate temporary objects
>>>
>>> TODO multi-threaded applications that use synchronous logging may see
>>> worse performance: the lock that was previously only around the IO
>>> operation is widened to include the text formatting and conversion to
>>> bytes. -> _synchronous_ logging performance may be worse for multi-threaded
>>> applications in this mode due to synchronization on the shared buffer. If
>>> your application is multi-threaded and logging performance is important,
>>> consider using Async Loggers.
>>>
>>> TODO Caution: Only dates in the predefined formats are garbage-free ->
>>> Caution: Only the predefined date formats are garbage-free
>>>
>>> TODO "(Note that Log4j may call toString() on message and parameter
>>> objects when garbage-free logging is disabled because system property
>>> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
>>> toString() on message and parameter objects when garbage-free logging is
>>> disabled (when system property log4j2.enable.threadlocals is set to
>>> "false".)
>>>
>>> TODO "made an effort to make logging code garbage-free" -> "made an
>>> effort to make logging garbage-free"
>>>
>>>
>>> > Document "gc-free" configuration and performance
>>> > 
>>> >
>>> > Key: LOG4J2-1297
>>> > URL: https://issues.apache.org/jira/browse/LOG4J2-1297
>>> > Project: Log4j 2
>>> >  Issue Type: New Feature
>>> >  Components: Documentation
>>> >Affects Versions: 2.5
>>> >Reporter: Remko Popma
>>> >Assignee: Remko Popma
>>> > Fix For: 2.6
>>> >
>>> > Attachments: log4j-2.5-FlightRecording.png,
>>> log4j-2.6-FlightRecording.png
>>> >
>>> >
>>> > Update the site with a description of which configurations are GC-free
>>> (i.e., that don't create temporary objects in steady running state).
>>> > Currently that means
>>> > * Loggers are all asynchronous (Log4jContextSelector is set to
>>> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
>>> > * The configuration does not contain a  section.
>>> > * The "steady-state" appenders are either RandomAccessFile or
>>> RollingRandomAccessFile Appenders (logging to any other appender will cause
>>> temporary objects to be created - including ConsoleAppender).
>>> > * The Layout is a PatternLayout that uses one of the pre-defined date
>>> formats, does not have any regular expression replacements, and does not
>>> have lookups (TODO: may need to restrict this further).
>>> > * The thread name is cached (this is the [default|
>>> https://issues.apache.org/jira/browse/LOG4J2-467]). Running with
>>> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
>>> > * In user code, when logging a parameterized message, the number of
>>> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
>>> > * In user code, when logging a parameterized message, parameters of
>>> primitive type are boxed in a reused StringBuilder (Log4j provides a
>>> utility to make this relatively painless).
>>> > Even with the above restrictions, Log4j may occasionally create
>>> garbage:
>>> > * Initially StringBuilders are presized to 128 characters. They may
>>> grow for larger messages (contributing to garbage in Old Gen). If  the
>>> StringBuilde

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-04-18 Thread Mikael Ståldal

Is it wise to enable by default given that "multi-threaded applications
that use synchronous logging may see worse performance"?

On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma  wrote:

> Enabled, except for web apps; for those log4j will be low garbage.
>
> See the first paragraph of the Configuration section in the manual page.
>
> Please let me know if this is not clear. (The fact that you asked means
> this probably needs improvement...)
>
> Sent from my iPhone
>
> On 2016/04/18, at 20:18, Mikael Ståldal  wrote:
>
> Will garbage-free logging be enabled or disabled by default?
>
> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) 
> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
>> ]
>>
>> Remko Popma commented on LOG4J2-1297:
>> -
>>
>> TODO allocate many temporary objects -> allocate temporary objects
>>
>> TODO multi-threaded applications that use synchronous logging may see
>> worse performance: the lock that was previously only around the IO
>> operation is widened to include the text formatting and conversion to
>> bytes. -> _synchronous_ logging performance may be worse for multi-threaded
>> applications in this mode due to synchronization on the shared buffer. If
>> your application is multi-threaded and logging performance is important,
>> consider using Async Loggers.
>>
>> TODO Caution: Only dates in the predefined formats are garbage-free ->
>> Caution: Only the predefined date formats are garbage-free
>>
>> TODO "(Note that Log4j may call toString() on message and parameter
>> objects when garbage-free logging is disabled because system property
>> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
>> toString() on message and parameter objects when garbage-free logging is
>> disabled (when system property log4j2.enable.threadlocals is set to
>> "false".)
>>
>> TODO "made an effort to make logging code garbage-free" -> "made an
>> effort to make logging garbage-free"
>>
>>
>> > Document "gc-free" configuration and performance
>> > 
>> >
>> > Key: LOG4J2-1297
>> > URL: https://issues.apache.org/jira/browse/LOG4J2-1297
>> > Project: Log4j 2
>> >  Issue Type: New Feature
>> >  Components: Documentation
>> >Affects Versions: 2.5
>> >Reporter: Remko Popma
>> >Assignee: Remko Popma
>> > Fix For: 2.6
>> >
>> > Attachments: log4j-2.5-FlightRecording.png,
>> log4j-2.6-FlightRecording.png
>> >
>> >
>> > Update the site with a description of which configurations are GC-free
>> (i.e., that don't create temporary objects in steady running state).
>> > Currently that means
>> > * Loggers are all asynchronous (Log4jContextSelector is set to
>> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
>> > * The configuration does not contain a  section.
>> > * The "steady-state" appenders are either RandomAccessFile or
>> RollingRandomAccessFile Appenders (logging to any other appender will cause
>> temporary objects to be created - including ConsoleAppender).
>> > * The Layout is a PatternLayout that uses one of the pre-defined date
>> formats, does not have any regular expression replacements, and does not
>> have lookups (TODO: may need to restrict this further).
>> > * The thread name is cached (this is the [default|
>> https://issues.apache.org/jira/browse/LOG4J2-467]). Running with
>> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
>> > * In user code, when logging a parameterized message, the number of
>> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
>> > * In user code, when logging a parameterized message, parameters of
>> primitive type are boxed in a reused StringBuilder (Log4j provides a
>> utility to make this relatively painless).
>> > Even with the above restrictions, Log4j may occasionally create garbage:
>> > * Initially StringBuilders are presized to 128 characters. They may
>> grow for larger messages (contributing to garbage in Old Gen). If  the
>> StringBuilder grows beyond 512 characters it is trimmed back to 512
>> characters to prevent memory leaks from excessively long messages. (TODO:
>> the resizing algorithm is {{size = value.length * 2 + 2}}, so a better
>> cutoff value is 518.)
>> > * Messages containing {{"$\{"}} will be converted to a String and
>> StrSubstitutor will be used to replace occurences of variables with their
>> matching values. Multiple temporary objects are created during this process.
>> > Furthermore, we need to explain that some of this functionality depends
>> on ThreadLocals and so is disabled by default in web applications to
>> prevent memory leaks. The page should also explain how to manually switch
>> off the use of ThreadLocals.
>> > Finally, the page should show

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

Enabled, except for web apps; for those log4j will be low garbage. 

See the first paragraph of the Configuration section in the manual page. 

Please let me know if this is not clear. (The fact that you asked means this 
probably needs improvement...)

Sent from my iPhone

> On 2016/04/18, at 20:18, Mikael Ståldal  wrote:
> 
> Will garbage-free logging be enabled or disabled by default?
> 
>> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA)  wrote:
>> 
>> [ 
>> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
>>  ]
>> 
>> Remko Popma commented on LOG4J2-1297:
>> -
>> 
>> TODO allocate many temporary objects -> allocate temporary objects
>> 
>> TODO multi-threaded applications that use synchronous logging may see worse 
>> performance: the lock that was previously only around the IO operation is 
>> widened to include the text formatting and conversion to bytes. -> 
>> _synchronous_ logging performance may be worse for multi-threaded 
>> applications in this mode due to synchronization on the shared buffer. If 
>> your application is multi-threaded and logging performance is important, 
>> consider using Async Loggers.
>> 
>> TODO Caution: Only dates in the predefined formats are garbage-free -> 
>> Caution: Only the predefined date formats are garbage-free
>> 
>> TODO "(Note that Log4j may call toString() on message and parameter objects 
>> when garbage-free logging is disabled because system property 
>> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call toString() 
>> on message and parameter objects when garbage-free logging is disabled (when 
>> system property log4j2.enable.threadlocals is set to "false".)
>> 
>> TODO "made an effort to make logging code garbage-free" -> "made an effort 
>> to make logging garbage-free"
>> 
>> 
>> > Document "gc-free" configuration and performance
>> > 
>> >
>> > Key: LOG4J2-1297
>> > URL: https://issues.apache.org/jira/browse/LOG4J2-1297
>> > Project: Log4j 2
>> >  Issue Type: New Feature
>> >  Components: Documentation
>> >Affects Versions: 2.5
>> >Reporter: Remko Popma
>> >Assignee: Remko Popma
>> > Fix For: 2.6
>> >
>> > Attachments: log4j-2.5-FlightRecording.png, 
>> > log4j-2.6-FlightRecording.png
>> >
>> >
>> > Update the site with a description of which configurations are GC-free 
>> > (i.e., that don't create temporary objects in steady running state).
>> > Currently that means
>> > * Loggers are all asynchronous (Log4jContextSelector is set to 
>> > org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
>> > * The configuration does not contain a  section.
>> > * The "steady-state" appenders are either RandomAccessFile or 
>> > RollingRandomAccessFile Appenders (logging to any other appender will 
>> > cause temporary objects to be created - including ConsoleAppender).
>> > * The Layout is a PatternLayout that uses one of the pre-defined date 
>> > formats, does not have any regular expression replacements, and does not 
>> > have lookups (TODO: may need to restrict this further).
>> > * The thread name is cached (this is the 
>> > [default|https://issues.apache.org/jira/browse/LOG4J2-467]). Running with 
>> > -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
>> > * In user code, when logging a parameterized message, the number of 
>> > parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
>> > * In user code, when logging a parameterized message, parameters of 
>> > primitive type are boxed in a reused StringBuilder (Log4j provides a 
>> > utility to make this relatively painless).
>> > Even with the above restrictions, Log4j may occasionally create garbage:
>> > * Initially StringBuilders are presized to 128 characters. They may grow 
>> > for larger messages (contributing to garbage in Old Gen). If  the 
>> > StringBuilder grows beyond 512 characters it is trimmed back to 512 
>> > characters to prevent memory leaks from excessively long messages. (TODO: 
>> > the resizing algorithm is {{size = value.length * 2 + 2}}, so a better 
>> > cutoff value is 518.)
>> > * Messages containing {{"$\{"}} will be converted to a String and 
>> > StrSubstitutor will be used to replace occurences of variables with their 
>> > matching values. Multiple temporary objects are created during this 
>> > process.
>> > Furthermore, we need to explain that some of this functionality depends on 
>> > ThreadLocals and so is disabled by default in web applications to prevent 
>> > memory leaks. The page should also explain how to manually switch off the 
>> > use of ThreadLocals.
>> > Finally, the page should show a performance test comparison similar to the 
>> > [performance 
>> > section|http://logging.apache.org/

Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-04-18 Thread Mikael Ståldal

Will garbage-free logging be enabled or disabled by default?

On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
> ]
>
> Remko Popma commented on LOG4J2-1297:
> -
>
> TODO allocate many temporary objects -> allocate temporary objects
>
> TODO multi-threaded applications that use synchronous logging may see
> worse performance: the lock that was previously only around the IO
> operation is widened to include the text formatting and conversion to
> bytes. -> _synchronous_ logging performance may be worse for multi-threaded
> applications in this mode due to synchronization on the shared buffer. If
> your application is multi-threaded and logging performance is important,
> consider using Async Loggers.
>
> TODO Caution: Only dates in the predefined formats are garbage-free ->
> Caution: Only the predefined date formats are garbage-free
>
> TODO "(Note that Log4j may call toString() on message and parameter
> objects when garbage-free logging is disabled because system property
> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call
> toString() on message and parameter objects when garbage-free logging is
> disabled (when system property log4j2.enable.threadlocals is set to
> "false".)
>
> TODO "made an effort to make logging code garbage-free" -> "made an effort
> to make logging garbage-free"
>
>
> > Document "gc-free" configuration and performance
> > 
> >
> > Key: LOG4J2-1297
> > URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> > Project: Log4j 2
> >  Issue Type: New Feature
> >  Components: Documentation
> >Affects Versions: 2.5
> >Reporter: Remko Popma
> >Assignee: Remko Popma
> > Fix For: 2.6
> >
> > Attachments: log4j-2.5-FlightRecording.png,
> log4j-2.6-FlightRecording.png
> >
> >
> > Update the site with a description of which configurations are GC-free
> (i.e., that don't create temporary objects in steady running state).
> > Currently that means
> > * Loggers are all asynchronous (Log4jContextSelector is set to
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> > * The configuration does not contain a  section.
> > * The "steady-state" appenders are either RandomAccessFile or
> RollingRandomAccessFile Appenders (logging to any other appender will cause
> temporary objects to be created - including ConsoleAppender).
> > * The Layout is a PatternLayout that uses one of the pre-defined date
> formats, does not have any regular expression replacements, and does not
> have lookups (TODO: may need to restrict this further).
> > * The thread name is cached (this is the [default|
> https://issues.apache.org/jira/browse/LOG4J2-467]). Running with
> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
> > * In user code, when logging a parameterized message, the number of
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
> > * In user code, when logging a parameterized message, parameters of
> primitive type are boxed in a reused StringBuilder (Log4j provides a
> utility to make this relatively painless).
> > Even with the above restrictions, Log4j may occasionally create garbage:
> > * Initially StringBuilders are presized to 128 characters. They may grow
> for larger messages (contributing to garbage in Old Gen). If  the
> StringBuilder grows beyond 512 characters it is trimmed back to 512
> characters to prevent memory leaks from excessively long messages. (TODO:
> the resizing algorithm is {{size = value.length * 2 + 2}}, so a better
> cutoff value is 518.)
> > * Messages containing {{"$\{"}} will be converted to a String and
> StrSubstitutor will be used to replace occurences of variables with their
> matching values. Multiple temporary objects are created during this process.
> > Furthermore, we need to explain that some of this functionality depends
> on ThreadLocals and so is disabled by default in web applications to
> prevent memory leaks. The page should also explain how to manually switch
> off the use of ThreadLocals.
> > Finally, the page should show a performance test comparison similar to
> the [performance section|
> http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on the
> Async Loggers page. I'm thinking a comparison between Logback, Log4j-1,
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>


-- 
[image: MagineTV]

*Mikael Ståld

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-04-17 Thread Remko Popma (JIRA)


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

Remko Popma commented on LOG4J2-1297:
-

TODO allocate many temporary objects -> allocate temporary objects 

TODO multi-threaded applications that use synchronous logging may see worse 
performance: the lock that was previously only around the IO operation is 
widened to include the text formatting and conversion to bytes. -> 
_synchronous_ logging performance may be worse for multi-threaded applications 
in this mode due to synchronization on the shared buffer. If your application 
is multi-threaded and logging performance is important, consider using Async 
Loggers.

TODO Caution: Only dates in the predefined formats are garbage-free -> Caution: 
Only the predefined date formats are garbage-free

TODO "(Note that Log4j may call toString() on message and parameter objects 
when garbage-free logging is disabled because system property 
log4j2.enable.threadlocals is set to "false".)" -> Log4j may call toString() on 
message and parameter objects when garbage-free logging is disabled (when 
system property log4j2.enable.threadlocals is set to "false".)

TODO "made an effort to make logging code garbage-free" -> "made an effort to 
make logging garbage-free"


> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6
>
> Attachments: log4j-2.5-FlightRecording.png, 
> log4j-2.6-FlightRecording.png
>
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> * The configuration does not contain a  section.
> * The "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender).
> * The Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further).
> * The thread name is cached (this is the 
> [default|https://issues.apache.org/jira/browse/LOG4J2-467]). Running with 
> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
> * In user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
> * In user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless).
> Even with the above restrictions, Log4j may occasionally create garbage:
> * Initially StringBuilders are presized to 128 characters. They may grow for 
> larger messages (contributing to garbage in Old Gen). If  the StringBuilder 
> grows beyond 512 characters it is trimmed back to 512 characters to prevent 
> memory leaks from excessively long messages. (TODO: the resizing algorithm is 
> {{size = value.length * 2 + 2}}, so a better cutoff value is 518.)
> * Messages containing {{"$\{"}} will be converted to a String and 
> StrSubstitutor will be used to replace occurences of variables with their 
> matching values. Multiple temporary objects are created during this process.
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-04-03 Thread Remko Popma (JIRA)


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

Remko Popma commented on LOG4J2-1297:
-

Yes, users probably know the converters by key ("%c" etc) rather than by name. 
Listing these in a HTML table may be better: the %d Date key needs more details 
on what date formats are garbage-free. Also probably better to list 
location-based converters explicitly as _not_ gc-friendly.

I'm also thinking to move the Configuration section to below the "Impact on 
Application Code: Autoboxing" section.

Supported Appenders: a bullet list is probably easier to read/scan.

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Attachments: log4j-2.5-FlightRecording.png, 
> log4j-2.6-FlightRecording.png
>
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> * The configuration does not contain a  section.
> * The "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender).
> * The Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further).
> * The thread name is cached (this is the 
> [default|https://issues.apache.org/jira/browse/LOG4J2-467]). Running with 
> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
> * In user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
> * In user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless).
> Even with the above restrictions, Log4j may occasionally create garbage:
> * Initially StringBuilders are presized to 128 characters. They may grow for 
> larger messages (contributing to garbage in Old Gen). If  the StringBuilder 
> grows beyond 512 characters it is trimmed back to 512 characters to prevent 
> memory leaks from excessively long messages. (TODO: the resizing algorithm is 
> {{size = value.length * 2 + 2}}, so a better cutoff value is 518.)
> * Messages containing {{"$\{"}} will be converted to a String and 
> StrSubstitutor will be used to replace occurences of variables with their 
> matching values. Multiple temporary objects are created during this process.
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-04-03 Thread Matt Sicker (JIRA)


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

Matt Sicker commented on LOG4J2-1297:
-

When referencing the PatternConverters, it might be helpful to include their 
key like "%c" for the logger name.

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Attachments: log4j-2.5-FlightRecording.png, 
> log4j-2.6-FlightRecording.png
>
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> * The configuration does not contain a  section.
> * The "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender).
> * The Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further).
> * The thread name is cached (this is the 
> [default|https://issues.apache.org/jira/browse/LOG4J2-467]). Running with 
> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
> * In user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
> * In user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless).
> Even with the above restrictions, Log4j may occasionally create garbage:
> * Initially StringBuilders are presized to 128 characters. They may grow for 
> larger messages (contributing to garbage in Old Gen). If  the StringBuilder 
> grows beyond 512 characters it is trimmed back to 512 characters to prevent 
> memory leaks from excessively long messages. (TODO: the resizing algorithm is 
> {{size = value.length * 2 + 2}}, so a better cutoff value is 518.)
> * Messages containing {{"$\{"}} will be converted to a String and 
> StrSubstitutor will be used to replace occurences of variables with their 
> matching values. Multiple temporary objects are created during this process.
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-04-03 Thread Remko Popma (JIRA)

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

Remko Popma commented on LOG4J2-1297:
-

Draft of the work in progress, feedback welcome:

h1. Garbage-free Steady State Logging

Garbage collection pauses are a common cause of latency spikes and for many
systems significant effort is spent on controlling these pauses.

Traditionally, logging libraries allocate many temporary objects like log event
objects, Strings, char arrays, byte arrays and more during steady state
logging. This contributes to pressure on the garbage collector and increases
the frequency with which GC pauses occur.

>From version 2.6, Log4j can be used in a "garbage free" mode where objects and
>buffers are reused and temporary object allocation is avoided as much as
>possible.

h2. A Contrived Example
To highlight the difference, we used Java Flight Recorder to measure a simple
application that does nothing but logging a simple string as often as possible
for about 12 seconds.

The application was configured to use Async Loggers, a RandomAccessFile
appender and a "%d %p %c\{1.} \[%t] %m %ex%n" pattern layout.

Mission Control shows that with Log4j 2.5 this application allocated memory at
a rate of about 809 MB/sec, resulting in 141 minor collections. Log4j 2.6 does
not allocate temporary objects in this configuration, and as a result the same
application with Log4j 2.6 had a memory allocation rate of 1.6 MB/sec and 0
(zero) garbage collections.

h2. Enabling Garbage-free Logging

h4.Configuration

In Log4j 2.6, garbage-free logging is enabled by default, except for web
applications. Log4j will disable garbage-free logging if it detects that it is
used in a web application (either when the {{javax.servlet.Servlet}} is in the
classpath or when the {{log4j2.is.webapp}} system property is set to "true").
This is because garbage-free logging uses a number of ThreadLocal fields, which
can cause memory leaks when the thread pools of web application containers hold
references to these fields even after the web application is undeployed.

It is possible to manually disable garbage-free logging by setting system
property {{log4j2.enable.threadlocals}} to "false" before Log4j is initialized.

The above properties can also be specified by creating a file named
{{log4j2.component.properties}} and including this file in the classpath of the
application.

| *Caution:* as of version 2.6, a Log4j configuration containing a
{{}} section will result in temporary objects being created during
steady-state logging.|

h4. Appenders

The following appenders are garbage-free: Console, File, RollingFile,
RandomAccessFile, RollingRandomAccessFile, MemoryMappedFile, and Socket.

Any other appenders (including Async) not in the above list create temporary
objects during steady-state logging. Use Async Loggers to log asynchronously in
a garbage-free manner.

h4. Layouts

>From the built-in layouts, currently only PatternLayout is garbage-free, but
>only when used with the following conversion patterns.

* ClassNamePatternConverter
* DatePatternConverter
* FileLocationPatternConverter
* LevelPatternConverter
* LineLocationPatternConverter
* LineSeparatorPatternConverter
* LiteralPatternConverter (unless literal contains '${')
* LoggerPatternConverter
* MarkerSimpleNamePatternConverter
* MessagePatternConverter
* MethodLocationPatternConverter
* NamePatternConverter
* NanoTimePatternConverter
* ThreadIdPatternConverter
* ThreadNamePatternConverter
* ThreadPriorityPatternConverter

Other PatternLayout conversion patterns, and some other Layouts are scheduled
to be updated to avoid creating temporary objects in a subsequent release.

| *Caution:* patterns containing regular expressions and lookups for property
substitution will result in temporary objects being created during steady-state
logging.|

h4. Application Code and Autoboxing

We made an effort to make existing application logging code garbage-free
without requiring code changes, but there is one area where this was not
possible. When logging primitive values (i.e. int, double, boolean, etc.),
autoboxing occurs and the JVM converts these primitive values to their Object
wrapper equivalents.

Log4j provides an {{Unboxer}} utility to prevent autoboxing of primitive
parameters. This utility contains a thread-local pool of reused StringBuilders.
The {{Unboxer.box(primitive)}} methods write directly into a StringBuilder, and
the resulting text will be copied into the final log message text without
creating temporary objects.

{code}
import static org.apache.logging.log4j.uti

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-03-23 Thread JIRA


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

Mikael Ståldal commented on LOG4J2-1297:


It seems like the stacktrace formatting in PatternLayout (%throwable) will not 
be garbage free.

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> * The configuration does not contain a  section.
> * The "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender).
> * The Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further).
> * The thread name is cached (this is the 
> [default|https://issues.apache.org/jira/browse/LOG4J2-467]). Running with 
> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
> * In user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
> * In user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless).
> Even with the above restrictions, Log4j may occasionally create garbage:
> * Initially StringBuilders are presized to 128 characters. They may grow for 
> larger messages (contributing to garbage in Old Gen). If  the StringBuilder 
> grows beyond 512 characters it is trimmed back to 512 characters to prevent 
> memory leaks from excessively long messages. (TODO: the resizing algorithm is 
> {{size = value.length * 2 + 2}}, so a better cutoff value is 518.)
> * Messages containing {{"$\{"}} will be converted to a String and 
> StrSubstitutor will be used to replace occurences of variables with their 
> matching values. Multiple temporary objects are created during this process.
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance


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

Remko Popma commented on LOG4J2-1297:
-

Sure, I will look at doing the performance testing using the 
LOG4J2-1278-gc-free-logger branch (I will keep it in sync with master).

I will perf test with 7 args.

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> * The configuration does not contain a  section.
> * The "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender).
> * The Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further).
> * In user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
> * In user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless).
> Even with the above restrictions, Log4j may occasionally create garbage:
> * Initially StringBuilders are presized to 128 characters. They may grow for 
> larger messages (contributing to garbage in Old Gen). If  the StringBuilder 
> grows beyond 512 characters it is trimmed back to 512 characters to prevent 
> memory leaks from excessively long messages. (TODO: the resizing algorithm is 
> {{size = value.length * 2 + 2}}, so a better cutoff value is 518.)
> * Messages containing {{"$\{"}} will be converted to a String and 
> StrSubstitutor will be used to replace occurences of variables with their 
> matching values. Multiple temporary objects are created during this process.
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-02-23 Thread Gary Gregory (JIRA)


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

Gary Gregory commented on LOG4J2-1297:
--

Instead of big-banging on the vararg rollout, can we pick one like debug with 7 
args and measure that to see what we get?

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector)
> * the configuration does not contain a  section
> * the "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender)
> * the Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further)
> * in user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278)
> * in user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless)
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance


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

Remko Popma commented on LOG4J2-1297:
-

Sure, but first we need to get consensus on the number of unrolled varargs in 
LOG4J2-1278 so I can merge that branch and start performance testing. Perf 
tests take a long time...

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector)
> * the configuration does not contain a  section
> * the "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender)
> * the Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further)
> * in user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278)
> * in user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless)
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance


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

Remko Popma commented on LOG4J2-1297:
-

I don't see an easy way to handle LOG4J2-1282 at the moment. An additional 
complication is that StrSubstitutor is involved, and that class is not exactly 
GC-free...

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector)
> * the configuration does not contain a  section
> * the "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender)
> * the Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further)
> * in user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278)
> * in user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless)
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-02-23 Thread Matt Sicker (JIRA)


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

Matt Sicker commented on LOG4J2-1297:
-

Don't forget to annotate the code! :)

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector)
> * the configuration does not contain a  section
> * the "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender)
> * the Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further)
> * in user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278)
> * in user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless)
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance

2016-02-23 Thread Gary Gregory (JIRA)


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

Gary Gregory commented on LOG4J2-1297:
--

Is the properties section read-only? If so, could we avoid creating a new map 
if the ThreadContextMap is otherwise empty?

> Document "gc-free" configuration and performance
> 
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Update the site with a description of which configurations are GC-free (i.e., 
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector)
> * the configuration does not contain a  section
> * the "steady-state" appenders are either RandomAccessFile or 
> RollingRandomAccessFile Appenders (logging to any other appender will cause 
> temporary objects to be created - including ConsoleAppender)
> * the Layout is a PatternLayout that uses one of the pre-defined date 
> formats, does not have any regular expression replacements, and does not have 
> lookups (TODO: may need to restrict this further)
> * in user code, when logging a parameterized message, the number of 
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278)
> * in user code, when logging a parameterized message, parameters of primitive 
> type are boxed in a reused StringBuilder (Log4j provides a utility to make 
> this relatively painless)
> Furthermore, we need to explain that some of this functionality depends on 
> ThreadLocals and so is disabled by default in web applications to prevent 
> memory leaks. The page should also explain how to manually switch off the use 
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the 
> [performance 
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on 
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1, 
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance