Re: Async logging and thread name

The usual reason for using char[] instead of String is so you can overwrite it in heap without having to wait for garbage collection and is only used for security reasons (e.g., a password). I'm going to guess legacy reasons for the char[], but native code could make sense, too. On 15 February

Re: Async logging and thread name

Hi Leon, Yes by default the thread name is cached. There is a system property to switch that off: see https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/async/ThreadNameCachingStrategy.java The reason for the caching is that every call

Re: Async logging and thread name

Only thing I can think of offhand is an issue with ReusableLogEventFactory. I don't see anything in the 2.8 changelog fixing anything related. Could you try disabling GC-free mode? < https://logging.apache.org/log4j/2.x/manual/garbagefree.html> I'm sure Remko will have some ideas when he's

Async logging and thread name

Hi, Is there any thread name caching going on with log4j2 (doesn't matter sync/async)? If I have a thread pool of tasks and call Thread.currentThread().setName (with unique id) in the beginning of the task execution, I sometimes see reuse of previous thread name in the log statements. Id is

Build failed in Jenkins: Log4jWindows » Windows,JDK 1.7 (unlimited security) 64-bit Windows only #21

See Changes: [ggregory] Update tests from org.apache.felix.framework 4.6.1 to 5.0.0. [ggregory] Update tests from org.apache.felix.framework 5.0.0

Build failed in Jenkins: Log4jWindows » Windows,JDK 1.8 (unlimited security) 64-bit Windows only #21

See Changes: [ggregory] Update tests from org.apache.felix.framework 4.6.1 to 5.0.0. [ggregory] Update tests from org.apache.felix.framework 5.0.0

[jira] [Updated] (LOG4J2-1804) Rolling file %i based rolling broken in 2.8

[ https://issues.apache.org/jira/browse/LOG4J2-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierrick HYMBERT updated LOG4J2-1804: - Attachment: LOG4J2-1804.junit.and.fix.patch Suggested patch, but I think the approach of

[jira] [Updated] (LOG4J2-1804) Rolling file %i based rolling broken in 2.8

[ https://issues.apache.org/jira/browse/LOG4J2-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierrick HYMBERT updated LOG4J2-1804: - Attachment: LOG4J2-1804.junit.patch > Rolling file %i based rolling broken in 2.8 >

[jira] [Updated] (LOG4J2-1804) Rolling file %i based rolling broken in 2.8

[ https://issues.apache.org/jira/browse/LOG4J2-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierrick HYMBERT updated LOG4J2-1804: - Attachment: (was: LOG4J2-1804.junit.patch) > Rolling file %i based rolling broken in

[jira] [Commented] (LOG4J2-1804) Rolling file %i based rolling broken in 2.8

[ https://issues.apache.org/jira/browse/LOG4J2-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15868278#comment-15868278 ] Pierrick HYMBERT commented on LOG4J2-1804: -- Temporary solution for 2.8 by configuration is to

[jira] [Comment Edited] (LOG4J2-1804) Rolling file %i based rolling broken in 2.8

[ https://issues.apache.org/jira/browse/LOG4J2-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15868278#comment-15868278 ] Pierrick HYMBERT edited comment on LOG4J2-1804 at 2/15/17 6:07 PM: ---

[jira] [Updated] (LOG4J2-1804) Rolling file %i based rolling broken in 2.8

[ https://issues.apache.org/jira/browse/LOG4J2-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierrick HYMBERT updated LOG4J2-1804: - Attachment: LOG4J2-1804.junit.patch Unit test to reproduce the issue. > Rolling file %i

[jira] [Closed] (LOG4J2-1817) Can AbstractManager close managers after it has let go of the lock?

[ https://issues.apache.org/jira/browse/LOG4J2-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nik Everett closed LOG4J2-1817. --- Resolution: Not A Problem Yes, that'll work. I should have seen that earlier. Thanks for pointing me

[jira] [Commented] (LOG4J2-1817) Can AbstractManager close managers after it has let go of the lock?

[ https://issues.apache.org/jira/browse/LOG4J2-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15868135#comment-15868135 ] Ralph Goers commented on LOG4J2-1817: - Can't you just override the stop method to do: {code} public

Fwd: logging-log4j2 git commit: Fix build on Windows (as seen on my machine and the build VM).

I haven't worked with OSGi in several months now, but that added import-package looks very odd. Technically, I think the bnd plugin is supposed to automatically figure that one out (importing packages from within the same jar), and besides, I wouldn't think there'd be a class visibility issue from

Re: RollingAppenderSizeTest failures

The Cassandra rule I made was just a simplified version of existing Cassandra test runners. The main thing is calling a class inside a full Cassandra distro that can start Cassandra simply from Java rather than from a shell script like you'd normally do in a server situation. Maybe try specifying

[jira] [Created] (LOG4J2-1817) Can AbstractManager close managers after it has let go of the lock?

Nik Everett created LOG4J2-1817: --- Summary: Can AbstractManager close managers after it has let go of the lock? Key: LOG4J2-1817 URL: https://issues.apache.org/jira/browse/LOG4J2-1817 Project: Log4j 2

[jira] [Commented] (LOG4J2-1691) Setup build process for new Git repo logging-log4j-scala, including site

[ https://issues.apache.org/jira/browse/LOG4J2-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867478#comment-15867478 ] Mikael Ståldal commented on LOG4J2-1691: It would be nice if it could be done before we make the