[ https://issues.apache.org/jira/browse/LOG4J2-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862187#comment-13862187 ]
Scott Deboy commented on LOG4J2-467: ------------------------------------ What should be the bottleneck in this test? I ran this on my MBP and I see around 70% idle CPU, disk doesn't look like it's being thrashed. > Thread name caching in async logger incompatible with use of Thread.setName() > ----------------------------------------------------------------------------- > > Key: LOG4J2-467 > URL: https://issues.apache.org/jira/browse/LOG4J2-467 > Project: Log4j 2 > Issue Type: Bug > Components: Core > Affects Versions: 2.0-beta9 > Environment: Debian Squeeze amd64 > OpenJDK 7u25 > Reporter: Anthony Baldocchi > Assignee: Remko Popma > Fix For: 2.0-rc1 > > Attachments: PerfTestDriver.java > > > AsyncLogger caches a thread's name in a thread-local info variable. I make > use of a thread pool where the submitted Runnables call Thread.setName() at > the beginning of their task and the thread name is included in the log > message. For an example of this behavior, see > org.jboss.netty.util.ThreadRenamingRunnable in Netty 3.x. With the cached > thread name, the log messages will contain whatever name the thread had when > it logged for the first time and so long as the thread doesn't terminate > (such as in a core pool thread), all log messages involving this thread will > be erroneous. If Thread.getName has a significant performance impact for > async logging, I would be satisfied if this behavior were configurable, > perhaps on a per-logger basis, so that the penalty only needs to be taken by > users who make use of Thread.setName() -- This message was sent by Atlassian JIRA (v6.1.5#6160) --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org