[jira] [Commented] (LOG4J2-1334) Garbage-free synchronous logging: add LogEventFactory that reuses a cached LogEvent

2016-04-17 Thread Remko Popma (JIRA)

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

Remko Popma commented on LOG4J2-1334:
-

Not sure if the LogEventFactory is the place to handle requests like 
LOG4J2-1347; it is very much an internal API... The MDC/NDC context map/stack 
are the best mechanism we have for this at the moment.

> Garbage-free synchronous logging: add LogEventFactory that reuses a cached 
> LogEvent
> ---
>
> Key: LOG4J2-1334
> URL: https://issues.apache.org/jira/browse/LOG4J2-1334
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6
>
>
> Until now I kept the scope of the garbage-free logging epic LOG4J2-1270 
> limited to asynchronous logging with all loggers asynchronous. This seemed a 
> natural thing to do since async loggers already have pre-allocated all 
> LogEvent instances.
> Now that LOG4J2-1270 is nearing completion it looks as if the only thing that 
> is required to allow synchronous logging to be garbage-free is a reusable 
> LogEvent implementation, stored in a ThreadLocal. This ticket is to analyse  
> and track the work for this option.



--
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] [Updated] (LOG4J2-1334) Garbage-free synchronous logging: add LogEventFactory that reuses a cached LogEvent

2016-04-17 Thread Remko Popma (JIRA)

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1334:

Summary: Garbage-free synchronous logging: add LogEventFactory that reuses 
a cached LogEvent  (was: Add LogEventFactory that reuses a cached LogEvent for 
garbage-free synchronous logging)

> Garbage-free synchronous logging: add LogEventFactory that reuses a cached 
> LogEvent
> ---
>
> Key: LOG4J2-1334
> URL: https://issues.apache.org/jira/browse/LOG4J2-1334
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6
>
>
> Until now I kept the scope of the garbage-free logging epic LOG4J2-1270 
> limited to asynchronous logging with all loggers asynchronous. This seemed a 
> natural thing to do since async loggers already have pre-allocated all 
> LogEvent instances.
> Now that LOG4J2-1270 is nearing completion it looks as if the only thing that 
> is required to allow synchronous logging to be garbage-free is a reusable 
> LogEvent implementation, stored in a ThreadLocal. This ticket is to analyse  
> and track the work for this option.



--
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-17 Thread Remko Popma (JIRA)

[ 
https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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



Re: logging-log4j2 git commit: Do not use our own deprecated code.

2016-04-17 Thread Gary Gregory
Yes, good catch. TY!

Gary

On Sun, Apr 17, 2016 at 4:53 PM, Matt Sicker  wrote:

> Wait I'm confused, aren't you supposed to use the return value from
> traceEntry() inside traceExit()?
>
> On 17 April 2016 at 18:52,  wrote:
>
>> Repository: logging-log4j2
>> Updated Branches:
>>   refs/heads/master f30bd69f8 -> 5f692411a
>>
>>
>> Do not use our own deprecated code.
>>
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit:
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/5f692411
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/5f692411
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/5f692411
>>
>> Branch: refs/heads/master
>> Commit: 5f692411a4568946ae4dfe053c9de19635dde18e
>> Parents: f30bd69
>> Author: ggregory 
>> Authored: Sun Apr 17 16:52:55 2016 -0700
>> Committer: ggregory 
>> Committed: Sun Apr 17 16:52:55 2016 -0700
>>
>> --
>>  .../log4j/core/net/server/TcpSocketServer.java| 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>> --
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/5f692411/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
>> --
>> diff --git
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
>> index db5917c..9103a01 100644
>> ---
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
>> +++
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
>> @@ -56,7 +56,7 @@ public class TcpSocketServer
>> extends AbstractSocketServer
>>
>>  @Override
>>  public void run() {
>> -logger.entry();
>> +logger.traceEntry();
>>  boolean closed = false;
>>  try {
>>  try {
>> @@ -80,7 +80,7 @@ public class TcpSocketServer
>> extends AbstractSocketServer
>>  } finally {
>>  handlers.remove(Long.valueOf(getId()));
>>  }
>> -logger.exit();
>> +logger.traceExit();
>>  }
>>
>>  public void shutdown() {
>> @@ -218,7 +218,7 @@ public class TcpSocketServer
>> extends AbstractSocketServer
>>   */
>>  @Override
>>  public void run() {
>> -logger.entry();
>> +logger.traceEntry();
>>  while (isActive()) {
>>  if (serverSocket.isClosed()) {
>>  return;
>> @@ -240,7 +240,7 @@ public class TcpSocketServer
>> extends AbstractSocketServer
>>  } catch (final IOException e) {
>>  if (serverSocket.isClosed()) {
>>  // OK we're done.
>> -logger.exit();
>> +logger.traceExit();
>>  return;
>>  }
>>  logger.error("Exception encountered on accept. Ignoring.
>> Stack Trace :", e);
>> @@ -255,7 +255,7 @@ public class TcpSocketServer
>> extends AbstractSocketServer
>>  // Ignore the exception
>>  }
>>  }
>> -logger.exit();
>> +logger.traceExit();
>>  }
>>
>>  /**
>> @@ -264,10 +264,10 @@ public class TcpSocketServer
>> extends AbstractSocketServer
>>   * @throws IOException if the server socket could not be closed
>>   */
>>  public void shutdown() throws IOException {
>> -logger.entry();
>> +logger.traceEntry();
>>  setActive(false);
>>  Thread.currentThread().interrupt();
>>  serverSocket.close();
>> -logger.exit();
>> +logger.traceExit();
>>  }
>>  }
>>
>>
>
>
> --
> Matt Sicker 
>



-- 
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: logging-log4j2 git commit: Do not use our own deprecated code.

2016-04-17 Thread Matt Sicker
Wait I'm confused, aren't you supposed to use the return value from
traceEntry() inside traceExit()?

On 17 April 2016 at 18:52,  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master f30bd69f8 -> 5f692411a
>
>
> Do not use our own deprecated code.
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/5f692411
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/5f692411
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/5f692411
>
> Branch: refs/heads/master
> Commit: 5f692411a4568946ae4dfe053c9de19635dde18e
> Parents: f30bd69
> Author: ggregory 
> Authored: Sun Apr 17 16:52:55 2016 -0700
> Committer: ggregory 
> Committed: Sun Apr 17 16:52:55 2016 -0700
>
> --
>  .../log4j/core/net/server/TcpSocketServer.java| 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/5f692411/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
> --
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
> index db5917c..9103a01 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/net/server/TcpSocketServer.java
> @@ -56,7 +56,7 @@ public class TcpSocketServer
> extends AbstractSocketServer
>
>  @Override
>  public void run() {
> -logger.entry();
> +logger.traceEntry();
>  boolean closed = false;
>  try {
>  try {
> @@ -80,7 +80,7 @@ public class TcpSocketServer
> extends AbstractSocketServer
>  } finally {
>  handlers.remove(Long.valueOf(getId()));
>  }
> -logger.exit();
> +logger.traceExit();
>  }
>
>  public void shutdown() {
> @@ -218,7 +218,7 @@ public class TcpSocketServer
> extends AbstractSocketServer
>   */
>  @Override
>  public void run() {
> -logger.entry();
> +logger.traceEntry();
>  while (isActive()) {
>  if (serverSocket.isClosed()) {
>  return;
> @@ -240,7 +240,7 @@ public class TcpSocketServer
> extends AbstractSocketServer
>  } catch (final IOException e) {
>  if (serverSocket.isClosed()) {
>  // OK we're done.
> -logger.exit();
> +logger.traceExit();
>  return;
>  }
>  logger.error("Exception encountered on accept. Ignoring.
> Stack Trace :", e);
> @@ -255,7 +255,7 @@ public class TcpSocketServer
> extends AbstractSocketServer
>  // Ignore the exception
>  }
>  }
> -logger.exit();
> +logger.traceExit();
>  }
>
>  /**
> @@ -264,10 +264,10 @@ public class TcpSocketServer
> extends AbstractSocketServer
>   * @throws IOException if the server socket could not be closed
>   */
>  public void shutdown() throws IOException {
> -logger.entry();
> +logger.traceEntry();
>  setActive(false);
>  Thread.currentThread().interrupt();
>  serverSocket.close();
> -logger.exit();
> +logger.traceExit();
>  }
>  }
>
>


-- 
Matt Sicker 


[jira] [Resolved] (LOG4J2-1362) Create a YAML layout

2016-04-17 Thread Gary Gregory (JIRA)

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-1362.
--
   Resolution: Fixed
Fix Version/s: 2.6

In Git master.

> Create a YAML layout
> 
>
> Key: LOG4J2-1362
> URL: https://issues.apache.org/jira/browse/LOG4J2-1362
> Project: Log4j 2
>  Issue Type: New Feature
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_77, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_77\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6
>
>
> Create a YAML layout; this will reuse what we already have for XML and JSON 
> through Jackson.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-17 Thread Ralph Goers (JIRA)

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

Ralph Goers commented on LOG4J2-1348:
-

That's why I love open source - many eyes and brains are much better than one!

BTW - Thanks for working on this.  Feel free to keep contributing!

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc-also.patch, 
> ctc-instance.patch, ctc.patch, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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] [Updated] (LOG4J2-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-17 Thread Greg Thomas (JIRA)

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Thomas updated LOG4J2-1348:

Attachment: ctc-instance.patch

Patch that implements the {{CloseableThreadContext.Instance ctc = 
CloseableThreadContext.put(...).put(...).push(...)}} style of API

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc-also.patch, 
> ctc-instance.patch, ctc.patch, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-17 Thread Greg Thomas (JIRA)

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

Greg Thomas commented on LOG4J2-1348:
-

That sounds like a good idea (wish I'd though of it!); to make it more 
explicit, it would be called like ...

{{CloseableThreadContext.Instance ctc = 
CloseableThreadContext.put(...).put(...)}}

i.e. the static method {{CloseableThreadContext.put()}} returns an instance of 
an object of type CloseableThreadContext.Instance - and the instance method 
{{put()}} of  CloseableThreadContext.Instance returns {{this}}. I'll rework 
accordingly ...

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc-also.patch, ctc.patch, 
> thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1334) Add LogEventFactory that reuses a cached LogEvent for garbage-free synchronous logging

2016-04-17 Thread Remko Popma (JIRA)

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

Remko Popma commented on LOG4J2-1334:
-

I made good progress on this ticket in the last week. Still to do:

- I need to add more unit tests for MutableLogEvent and the 
ReusableLogEventFactory.
- Two of the current unit tests fail when I enable synchronous garbage-free 
logging: CsvParameterLayoutTest and one more (forgot which). Both are related 
to LOG4J2-1342: passing on parameters in a ParameterizedMessage from the 
application thread to the asynchronous background thread.
- The new GcFreeMixedSyncAyncLoggingTest fails because objects are still being 
allocated somewhere when enqueueing a MutableLogEvent.
- Started working on a latency test to compare garbage-free logging to classic 
logging.

> Add LogEventFactory that reuses a cached LogEvent for garbage-free 
> synchronous logging
> --
>
> Key: LOG4J2-1334
> URL: https://issues.apache.org/jira/browse/LOG4J2-1334
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6
>
>
> Until now I kept the scope of the garbage-free logging epic LOG4J2-1270 
> limited to asynchronous logging with all loggers asynchronous. This seemed a 
> natural thing to do since async loggers already have pre-allocated all 
> LogEvent instances.
> Now that LOG4J2-1270 is nearing completion it looks as if the only thing that 
> is required to allow synchronous logging to be garbage-free is a reusable 
> LogEvent implementation, stored in a ThreadLocal. This ticket is to analyse  
> and track the work for this option.



--
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