logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-467) Thread name caching in async logger incompatible with use of Thread.setName()
Date Sat, 04 Jan 2014 04:26:51 GMT

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

Scott Deboy commented on LOG4J2-467:
------------------------------------

The test fails part way through for me since it isn't resolving the slf4j classes: Exception
in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory

I am only getting through the single threaded tests before it fails.

Assume I need the slf4j API and an implementation?  What's the right command to get those
included?

MBP means macbook pro..it's a mid 2012, 2.3 i7, SSD Samsung 840 pro w/16G, on Mavericks. 
Once I have a good command to run I'll update the bug with results.

> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message