Jenkins build is unstable: Log4j 2.x #1854

[Apache Jenkins Server]

See 


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

[jira] [Comment Edited] (LOG4J2-1343) Update ConsoleAppender to utilize gc-free Layout method

[Remko Popma (JIRA)]

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

Remko Popma edited comment on LOG4J2-1343 at 4/8/16 4:50 AM:
-

The current implementation that coarsely locks on the Appender Manager causes a 
deadlock in {{org.apache.logging.log4j.core.ThreadedTest}}.

The call sequence became clear after I added some system printouts:

{noformat}
pool-2-thread-1 ThreadedTest$LoggingRunnable@7df67951 calling 
logger.debug(state)
pool-2-thread-2 ThreadedTest$StateSettingRunnable@20afdd66 locking on state to 
call state.setState
pool-2-thread-2 ThreadedTest$State@7c7a06ec locked on state, entered setState, 
calling logger.debug...
pool-2-thread-3 ThreadedTest$LoggingRunnable@215a8856 calling 
logger.debug(state)
pool-2-thread-4 ThreadedTest$StateSettingRunnable@5f8707b5 locking on state to 
call state.setState
pool-2-thread-5 ThreadedTest$LoggingRunnable@51b48833 calling 
logger.debug(state)
pool-2-thread-6 ThreadedTest$StateSettingRunnable@2ba8331b locking on state to 
call state.setState
pool-2-thread-7 ThreadedTest$LoggingRunnable@1a12ff63 calling 
logger.debug(state)
pool-2-thread-8 ThreadedTest$StateSettingRunnable@452a6c88 locking on state to 
call state.setState
pool-2-thread-7 File.directEncodeEvent() synchronizing on manager
pool-2-thread-2 File.directEncodeEvent() synchronizing on manager
pool-2-thread-5 File.directEncodeEvent() synchronizing on manager
pool-2-thread-1 File.directEncodeEvent() synchronizing on manager
pool-2-thread-3 File.directEncodeEvent() synchronizing on manager
pool-2-thread-7 ThreadedTest$State@7c7a06ec locking on state to call 
state.getState
(deadlock)
{noformat}

In the above example thread 2 has a lock on state, and tries to lock on manager 
(in {{logger.debug("hello")}}, while thread 7 is calling 
{{logger.debug(state)}}, has a lock on manager and tries to lock on state (from 
{{state.toString()}}.

This means we cannot hold locks while turning the LogEvent into text. It is 
probably okay to hold a lock while turning that text into bytes though.


was (Author: rem...@yahoo.com):
The current implementation that coarsely locks on the Appender Manager causes a 
deadlock in {{org.apache.logging.log4j.core.ThreadedTest}}.

The call sequence became clear after I added some system printouts:

{noformat}
pool-2-thread-1 ThreadedTest$LoggingRunnable@7df67951 calling 
logger.debug(state)
pool-2-thread-2 ThreadedTest$StateSettingRunnable@20afdd66 locking on state to 
call state.setState
pool-2-thread-2 ThreadedTest$State@7c7a06ec locked on state, entered setState, 
calling logger.debug...
pool-2-thread-3 ThreadedTest$LoggingRunnable@215a8856 calling 
logger.debug(state)
pool-2-thread-4 ThreadedTest$StateSettingRunnable@5f8707b5 locking on state to 
call state.setState
pool-2-thread-5 ThreadedTest$LoggingRunnable@51b48833 calling 
logger.debug(state)
pool-2-thread-6 ThreadedTest$StateSettingRunnable@2ba8331b locking on state to 
call state.setState
pool-2-thread-7 ThreadedTest$LoggingRunnable@1a12ff63 calling 
logger.debug(state)
pool-2-thread-8 ThreadedTest$StateSettingRunnable@452a6c88 locking on state to 
call state.setState
pool-2-thread-7 File.directEncodeEvent() synchronizing on manager
pool-2-thread-2 File.directEncodeEvent() synchronizing on manager
pool-2-thread-5 File.directEncodeEvent() synchronizing on manager
pool-2-thread-1 File.directEncodeEvent() synchronizing on manager
pool-2-thread-3 File.directEncodeEvent() synchronizing on manager
pool-2-thread-7 ThreadedTest$State@7c7a06ec locking on state to call 
state.getState
(deadlock)
{noformat}

In the above example thread 2 has a lock on state, and tries to lock on manager 
(in {{logger.debug("hello")}}, while thread 7 is calling 
{{logger.debug(state)}}, has a lock on manager and tries to lock on state (from 
{{state.toString()}}.

> Update ConsoleAppender to utilize gc-free Layout method
> ---
>
> Key: LOG4J2-1343
> URL: https://issues.apache.org/jira/browse/LOG4J2-1343
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6
>
>
> TBD: would we want to include this in the upcoming 2.6 release?



--
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] [Reopened] (LOG4J2-1343) Update ConsoleAppender to utilize gc-free Layout method

[Remko Popma (JIRA)]

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

Remko Popma reopened LOG4J2-1343:
-

The current implementation that coarsely locks on the Appender Manager causes a 
deadlock in {{org.apache.logging.log4j.core.ThreadedTest}}.

The call sequence became clear after I added some system printouts:

{noformat}
pool-2-thread-1 ThreadedTest$LoggingRunnable@7df67951 calling 
logger.debug(state)
pool-2-thread-2 ThreadedTest$StateSettingRunnable@20afdd66 locking on state to 
call state.setState
pool-2-thread-2 ThreadedTest$State@7c7a06ec locked on state, entered setState, 
calling logger.debug...
pool-2-thread-3 ThreadedTest$LoggingRunnable@215a8856 calling 
logger.debug(state)
pool-2-thread-4 ThreadedTest$StateSettingRunnable@5f8707b5 locking on state to 
call state.setState
pool-2-thread-5 ThreadedTest$LoggingRunnable@51b48833 calling 
logger.debug(state)
pool-2-thread-6 ThreadedTest$StateSettingRunnable@2ba8331b locking on state to 
call state.setState
pool-2-thread-7 ThreadedTest$LoggingRunnable@1a12ff63 calling 
logger.debug(state)
pool-2-thread-8 ThreadedTest$StateSettingRunnable@452a6c88 locking on state to 
call state.setState
pool-2-thread-7 File.directEncodeEvent() synchronizing on manager
pool-2-thread-2 File.directEncodeEvent() synchronizing on manager
pool-2-thread-5 File.directEncodeEvent() synchronizing on manager
pool-2-thread-1 File.directEncodeEvent() synchronizing on manager
pool-2-thread-3 File.directEncodeEvent() synchronizing on manager
pool-2-thread-7 ThreadedTest$State@7c7a06ec locking on state to call 
state.getState
(deadlock)
{noformat}

In the above example thread 2 has a lock on state, and tries to lock on manager 
(in {{logger.debug("hello")}}, while thread 7 is calling 
{{logger.debug(state)}}, has a lock on manager and tries to lock on state (from 
{{state.toString()}}.

> Update ConsoleAppender to utilize gc-free Layout method
> ---
>
> Key: LOG4J2-1343
> URL: https://issues.apache.org/jira/browse/LOG4J2-1343
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6
>
>
> TBD: would we want to include this in the upcoming 2.6 release?



--
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-1359:
-

If there's no way to mix the compile environment, then I guess it would have to 
be in its own jdk9 module, yeah.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
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] [Created] (LOG4J2-1360) Add bridge to JDK9 System.Logger interface

[Matt Sicker (JIRA)]

Matt Sicker created LOG4J2-1360:
---

 Summary: Add bridge to JDK9 System.Logger interface
 Key: LOG4J2-1360
 URL: https://issues.apache.org/jira/browse/LOG4J2-1360
 Project: Log4j 2
  Issue Type: New Feature
 Environment: Java 1.9+
Reporter: Matt Sicker


The System.Logger interface is described in 
[JDK-8046565|https://bugs.openjdk.java.net/browse/JDK-8046565] and documented 
[here|http://download.java.net/jdk9/docs/api/java/lang/System.Logger.html]. 
There's also the related 
[System.LoggerFinder|http://download.java.net/jdk9/docs/api/java/lang/System.LoggerFinder.html]
 factory class to implement.



--
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Matt Sicker (JIRA)]

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

Matt Sicker updated LOG4J2-1359:

Labels: jdk9  (was: )

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-1359:
-

Interesting. Given the need to compile this with javac 1.9, would this be a 
separate module then?

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-1359:
-

I tested StackWalker a few weeks ago. I don't remember the actual numbers I 
got, but StackWalker was considerably faster than using a Throwable to capture 
the location information.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Matt Sicker (JIRA)]

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

Matt Sicker updated LOG4J2-1359:

Description: 
[StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]

Based on the functional nature of this API, supporting it may require compiling 
at least one class using javac 1.9 and reflectively loading it in 
ReflectionUtil similar to how Spring supports newer JDK APIs.

Without support for StackWalker, ReflectionUtil will fall back to using a 
slower API in Java 1.9. This is because the Reflection class is a sun-internal 
class which are no longer exported to non-JDK code without setting special 
command line flags.

  was:
[StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]

Based on the functional nature of this API, supporting it may require compiling 
at least one class using javac 1.9 and reflectively loading it in 
ReflectionUtil similar to how Spring supports newer JDK APIs.

Without support for StackWalker, ReflectionUtil will fall back to using a 
slower API in Java 1.9.


> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
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] [Created] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Matt Sicker (JIRA)]

Matt Sicker created LOG4J2-1359:
---

 Summary: Add support for Java 9 StackWalker API in ReflectionUtil
 Key: LOG4J2-1359
 URL: https://issues.apache.org/jira/browse/LOG4J2-1359
 Project: Log4j 2
  Issue Type: Improvement
  Components: API
 Environment: Java 1.9+
Reporter: Matt Sicker


[StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]

Based on the functional nature of this API, supporting it may require compiling 
at least one class using javac 1.9 and reflectively loading it in 
ReflectionUtil similar to how Spring supports newer JDK APIs.

Without support for StackWalker, ReflectionUtil will fall back to using a 
slower API in Java 1.9.



--
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: Build failed in Jenkins: Log4j 2.x #1852

[Remko Popma]

I'm assuming this is caused by one on my recent changes. 

The reasons I can think of is either the change to SimpleMessage to carry a 
CharSequence, or the wider lock in the file/console appenders: in the gc-free 
mechanism the Layout converts a LogEvent to bytes within a synchronized block. 
This may affect multi-threaded tests. 

I restricted the gc-free layout mechanism to async loggers for now. 

Sent from my iPhone

> On 2016/04/08, at 5:49, Matt Sicker  wrote:
> 
> > Build timed out (after 240 minutes). Marking the build as failed.
> 
> Whoa.
> 
>> On 7 April 2016 at 15:40, Apache Jenkins Server  
>> wrote:
>> See 
>> 
>> Changes:
>> 
>> [rpopma] LOG4J2-1326 modify SimpleMessage and ReusableSimpleMessage so they 
>> can
>> 
>> [rpopma] LOG4J2-1326 ReusableSimpleMessage test fix
>> 
>> [rpopma] LOG4J2-1326 add methods to Logger interface that explicitly accept a
>> 
>> [rpopma] LOG4J2-1326 add methods to AbstractLogger that explicitly accept a
>> 
>> [rpopma] LOG4J2-1326 add methods isEnabled and logIfEnabled that accept a
>> 
>> [rpopma] LOG4J2-1326 add methods isEnabled that accepts a CharSequence to
>> 
>> [rpopma] LOG4J2-1326 MessageFactory changes to create a CharSequence-based
>> 
>> [rpopma] LOG4J2-1326 add methods isEnabled that accepts a CharSequence to
>> 
>> [rpopma] LOG4J2-1326 add tests for explicitly logging CharSequence
>> 
>> [rpopma] LOG4J2-1326 SimpleMessage serialized format changed
>> 
>> [rpopma] LOG4J2-1326 ensure that in garbage-free mode, logging a CharSequence
>> 
>> [rpopma] LOG4J2-1326 change log
>> 
>> [rpopma] LOG4J2-1297 documentation update: added section on the API changes
>> 
>> --
>> [...truncated 2398 lines...]
>> at 
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>  [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.Suite.runChild(Suite.java:128) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.Suite.runChild(Suite.java:27) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) 
>> [junit-4.12.jar:4.12]
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) 
>> [junit-4.12.jar:4.12]
>> at 
>> org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) 
>> [surefire-junit47-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
>>  [surefire-junit47-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
>>  [surefire-junit47-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
>>  [surefire-junit47-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
>>  [surefire-junit47-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:161)
>>  [surefire-junit47-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
>>  [surefire-booter-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
>>  [surefire-booter-2.19.1.jar:2.19.1]
>> at 
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) 
>> [surefire-booter-2.19.1.jar:2.19.1]
>> Suppressed: java.lang.Exception: java.lang.Exception
>> at 
>> org.apache.logging.log4j.core.impl.ThrowableProxyTest.testCircularSuppressedNestedException(ThrowableProxyTest.java:283)
>>  [test-classes/:?]
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
>> Method) 

Re: Build failed in Jenkins: Log4j 2.x #1852

[Matt Sicker]

> Build timed out (after 240 minutes). Marking the build as failed.

Whoa.

On 7 April 2016 at 15:40, Apache Jenkins Server 
wrote:

> See 
>
> Changes:
>
> [rpopma] LOG4J2-1326 modify SimpleMessage and ReusableSimpleMessage so
> they can
>
> [rpopma] LOG4J2-1326 ReusableSimpleMessage test fix
>
> [rpopma] LOG4J2-1326 add methods to Logger interface that explicitly
> accept a
>
> [rpopma] LOG4J2-1326 add methods to AbstractLogger that explicitly accept a
>
> [rpopma] LOG4J2-1326 add methods isEnabled and logIfEnabled that accept a
>
> [rpopma] LOG4J2-1326 add methods isEnabled that accepts a CharSequence to
>
> [rpopma] LOG4J2-1326 MessageFactory changes to create a CharSequence-based
>
> [rpopma] LOG4J2-1326 add methods isEnabled that accepts a CharSequence to
>
> [rpopma] LOG4J2-1326 add tests for explicitly logging CharSequence
>
> [rpopma] LOG4J2-1326 SimpleMessage serialized format changed
>
> [rpopma] LOG4J2-1326 ensure that in garbage-free mode, logging a
> CharSequence
>
> [rpopma] LOG4J2-1326 change log
>
> [rpopma] LOG4J2-1297 documentation update: added section on the API changes
>
> --
> [...truncated 2398 lines...]
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> [junit-4.12.jar:4.12]
> at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> [junit-4.12.jar:4.12]
> at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> [junit-4.12.jar:4.12]
> at org.junit.runners.Suite.runChild(Suite.java:128)
> [junit-4.12.jar:4.12]
> at org.junit.runners.Suite.runChild(Suite.java:27)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> [junit-4.12.jar:4.12]
> at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> [junit-4.12.jar:4.12]
> at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> [junit-4.12.jar:4.12]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> [junit-4.12.jar:4.12]
> at
> org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> [surefire-junit47-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> [surefire-junit47-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> [surefire-junit47-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> [surefire-junit47-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> [surefire-junit47-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:161)
> [surefire-junit47-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> [surefire-booter-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> [surefire-booter-2.19.1.jar:2.19.1]
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> [surefire-booter-2.19.1.jar:2.19.1]
> Suppressed: java.lang.Exception: java.lang.Exception
> at
> org.apache.logging.log4j.core.impl.ThrowableProxyTest.testCircularSuppressedNestedException(ThrowableProxyTest.java:283)
> [test-classes/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:1.7.0_51]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> ~[?:1.7.0_51]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606)
> ~[?:1.7.0_51]
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> [junit-4.12.jar:4.12]
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> [junit-4.12.jar:4.12]
> at
> 

Build failed in Jenkins: Log4j 2.x #1852

[Apache Jenkins Server]

See 

Changes:

[rpopma] LOG4J2-1326 modify SimpleMessage and ReusableSimpleMessage so they can

[rpopma] LOG4J2-1326 ReusableSimpleMessage test fix

[rpopma] LOG4J2-1326 add methods to Logger interface that explicitly accept a

[rpopma] LOG4J2-1326 add methods to AbstractLogger that explicitly accept a

[rpopma] LOG4J2-1326 add methods isEnabled and logIfEnabled that accept a

[rpopma] LOG4J2-1326 add methods isEnabled that accepts a CharSequence to

[rpopma] LOG4J2-1326 MessageFactory changes to create a CharSequence-based

[rpopma] LOG4J2-1326 add methods isEnabled that accepts a CharSequence to

[rpopma] LOG4J2-1326 add tests for explicitly logging CharSequence

[rpopma] LOG4J2-1326 SimpleMessage serialized format changed

[rpopma] LOG4J2-1326 ensure that in garbage-free mode, logging a CharSequence

[rpopma] LOG4J2-1326 change log

[rpopma] LOG4J2-1297 documentation update: added section on the API changes

--
[...truncated 2398 lines...]
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
 [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.run(ParentRunner.java:363) 
[junit-4.12.jar:4.12]
at org.junit.runners.Suite.runChild(Suite.java:128) 
[junit-4.12.jar:4.12]
at org.junit.runners.Suite.runChild(Suite.java:27) [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) 
[junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.run(ParentRunner.java:363) 
[junit-4.12.jar:4.12]
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) 
[surefire-junit47-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
 [surefire-junit47-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
 [surefire-junit47-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
 [surefire-junit47-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
 [surefire-junit47-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:161)
 [surefire-junit47-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
 [surefire-booter-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
 [surefire-booter-2.19.1.jar:2.19.1]
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) 
[surefire-booter-2.19.1.jar:2.19.1]
Suppressed: java.lang.Exception: java.lang.Exception
at 
org.apache.logging.log4j.core.impl.ThrowableProxyTest.testCircularSuppressedNestedException(ThrowableProxyTest.java:283)
 [test-classes/:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
~[?:1.7.0_51]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
~[?:1.7.0_51]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606) 
~[?:1.7.0_51]
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
 [junit-4.12.jar:4.12]
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 [junit-4.12.jar:4.12]
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
 [junit-4.12.jar:4.12]
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
 [junit-4.12.jar:4.12]
at 
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) 
[junit-4.12.jar:4.12]
at 

[jira] [Comment Edited] (LOG4J2-1326) API change: add methods for logging CharSequences (was: Provide support for CharSequence parameters for low and zero-GC applications)

[Remko Popma (JIRA)]

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

Remko Popma edited comment on LOG4J2-1326 at 4/7/16 3:45 PM:
-

Fixed in master.

I added these methods to the Logger interface:

{code}
debug(Marker, CharSequence)
debug(Marker, CharSequence, Throwable)
debug(CharSequence)
debug(CharSequence, Throwable)

// ... similar for the other log levels
{code}

Please verify and close.


was (Author: rem...@yahoo.com):
Fixed in master.

Adding these methods to the Logger interface:

{code}
debug(Marker, CharSequence)
debug(Marker, CharSequence, Throwable)
debug(CharSequence)
debug(CharSequence, Throwable)

// ... similar for the other log levels
{code}

Please verify and close.

> API change: add methods for logging CharSequences (was: Provide support for 
> CharSequence parameters for low and zero-GC applications)
> -
>
> Key: LOG4J2-1326
> URL: https://issues.apache.org/jira/browse/LOG4J2-1326
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: API
>Affects Versions: 2.5
>Reporter: Vlad Shurupov
>Assignee: Remko Popma
>  Labels: features, performance
> Fix For: 2.6
>
>
> Currently, the preferred way of logging character sequences in log4j 2 is by 
> passing in tokens of type {{java.lang.String}}. It would be very beneficial 
> if the API could provide methods that take {{java.lang.CharSequence}} tokens. 
> This would allow high performance zero or low-GC applications to re-use the 
> existing mutable structures implementing {{java.lang.CharSequence}}  for 
> continuous logging without new objects being created.
> A high-performance implementation of the logger would be expected to copy out 
> the contents of a single or multiple instances of {{java.lang.CharSequence}} 
> so that they could be re-used in the subsequent logging call.



--
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] [Resolved] (LOG4J2-1326) API change: add methods for logging CharSequences (was: Provide support for CharSequence parameters for low and zero-GC applications)

[Remko Popma (JIRA)]

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

Remko Popma resolved LOG4J2-1326.
-
Resolution: Fixed

Fixed in master.

Adding these methods to the Logger interface:

{code}
debug(Marker, CharSequence)
debug(Marker, CharSequence, Throwable)
debug(CharSequence)
debug(CharSequence, Throwable)

// ... similar for the other log levels
{code}

Please verify and close.

> API change: add methods for logging CharSequences (was: Provide support for 
> CharSequence parameters for low and zero-GC applications)
> -
>
> Key: LOG4J2-1326
> URL: https://issues.apache.org/jira/browse/LOG4J2-1326
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: API
>Affects Versions: 2.5
>Reporter: Vlad Shurupov
>Assignee: Remko Popma
>  Labels: features, performance
> Fix For: 2.6
>
>
> Currently, the preferred way of logging character sequences in log4j 2 is by 
> passing in tokens of type {{java.lang.String}}. It would be very beneficial 
> if the API could provide methods that take {{java.lang.CharSequence}} tokens. 
> This would allow high performance zero or low-GC applications to re-use the 
> existing mutable structures implementing {{java.lang.CharSequence}}  for 
> continuous logging without new objects being created.
> A high-performance implementation of the logger would be expected to copy out 
> the contents of a single or multiple instances of {{java.lang.CharSequence}} 
> so that they could be re-used in the subsequent logging call.



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

[Ralph Goers]

They should be. You can always create a marker that acts as a collection of 
other markers, so there is no need to support a list in the LogEvent.

Ralph

> On Apr 7, 2016, at 7:03 AM, Matt Sicker  wrote:
> 
> Aren't hierarchical markers good enough for that?
> 
> On 7 April 2016 at 00:02, Ralph Goers  > wrote:
> Didn’t we have this discussion several weeks ago? I don’t see a reason to 
> support it.
> 
> Ralph
> 
>> On Apr 6, 2016, at 9:51 PM, Gary Gregory > > wrote:
>> 
>> Before I go down some rabbit hole...
>> 
>> Any thoughts on marking log events with more than one marker?
>> 
>> Gary
>> 
>> -- 
>> 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 
> 
> 
> 
> -- 
> Matt Sicker >

Re: Markers Markers

[Matt Sicker]

Aren't hierarchical markers good enough for that?

On 7 April 2016 at 00:02, Ralph Goers  wrote:

> Didn’t we have this discussion several weeks ago? I don’t see a reason to
> support it.
>
> Ralph
>
> On Apr 6, 2016, at 9:51 PM, Gary Gregory  wrote:
>
> Before I go down some rabbit hole...
>
> Any thoughts on marking log events with more than one marker?
>
> Gary
>
> --
> 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
>
>
>


-- 
Matt Sicker 

[jira] [Closed] (LOG4J2-1184) NullPointerException when attempting to configure logging in custom ShutdownCallbackRegistry

[Matt Sicker (JIRA)]

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

Matt Sicker closed LOG4J2-1184.
---
Resolution: Won't Fix

> NullPointerException when attempting to configure logging in custom 
> ShutdownCallbackRegistry
> 
>
> Key: LOG4J2-1184
> URL: https://issues.apache.org/jira/browse/LOG4J2-1184
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: OSX, Ubuntu
>Reporter: Robert Veitch
>Priority: Minor
>
> I have a custom ShutdownCallbackRegistry implementation, which I've 
> configured to be instantiated via:
> -Dlog4j.shutdownCallbackRegistry=
> If I configure a logger in the normal way, either via a static or instance 
> variable, I get a NullPointerException on startup. Something like:
> private static final Logger logger = LoggerFactory.getLogger(MyClass.class);
> I think this is probably because the configured registry instance gets 
> created prior to the log4j subsystem responsible for loggers. My workaround 
> is to define the logger variable without assigning it:
> private static final Logger logger;
> And then assigning it as the first line of my run method:
> public void run() {
> logger = LoggerFactory.getLogger(MyClass.class);
> // shutdown registry code
> }
> But if possible, it seems like the instantiation order should be reworked so 
> that implementers of a custom registry do not have to do this.



--
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] [Assigned] (LOG4J2-1326) API change: add methods for logging CharSequences (was: Provide support for CharSequence parameters for low and zero-GC applications)

[Remko Popma (JIRA)]

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

Remko Popma reassigned LOG4J2-1326:
---

Assignee: Remko Popma

> API change: add methods for logging CharSequences (was: Provide support for 
> CharSequence parameters for low and zero-GC applications)
> -
>
> Key: LOG4J2-1326
> URL: https://issues.apache.org/jira/browse/LOG4J2-1326
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: API
>Affects Versions: 2.5
>Reporter: Vlad Shurupov
>Assignee: Remko Popma
>  Labels: features, performance
> Fix For: 2.6
>
>
> Currently, the preferred way of logging character sequences in log4j 2 is by 
> passing in tokens of type {{java.lang.String}}. It would be very beneficial 
> if the API could provide methods that take {{java.lang.CharSequence}} tokens. 
> This would allow high performance zero or low-GC applications to re-use the 
> existing mutable structures implementing {{java.lang.CharSequence}}  for 
> continuous logging without new objects being created.
> A high-performance implementation of the logger would be expected to copy out 
> the contents of a single or multiple instances of {{java.lang.CharSequence}} 
> so that they could be re-used in the subsequent logging call.



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