[jira] [Commented] (LOG4J2-1479) Help Apache Spark project to upgrade from Log4j 1.x to 2.x

[Chris Martin (JIRA)]

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

Chris Martin commented on LOG4J2-1479:
--

Hi- [~mikaelstaldal]

I've started work on the spark side to upgrade us to log4j2.  Most of it is 
pretty straightforward with the exception of which [Logging.scala 
|https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/internal/Logging.scala]does
 a bit of messing about with the internals of log4j.

Fundamentally this class does the following:
 * Determines if log4j is available
 * Determines if log4j has been initialized yet
 * Initializes log4j with a default config if one hasn't been specified
 * Overwrites logger levels
 * Resets the log4j system so it can be reinitialised form a new config at a 
later point.

I'd be interested in hearing your (or anyone else from the log4j2 project)'s 
opinion as to how this could be best achieved using log4j2.  I'm fairly sure 
that the sort of thing this class does is not the approved mechanism for using 
log4j, however for the moment I'd like to preserve the functionality of the 
logging trait as much as possible.

 

thanks,

Chris

 

 

 

> Help Apache Spark project to upgrade from Log4j 1.x to 2.x
> --
>
> Key: LOG4J2-1479
> URL: https://issues.apache.org/jira/browse/LOG4J2-1479
> Project: Log4j 2
>  Issue Type: Sub-task
>Reporter: Mikael Ståldal
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jenkins build is back to normal : Log4j 2 3.x #249

[Apache Jenkins Server]

See 

Build failed in Jenkins: Log4j 2 3.x #248

[Apache Jenkins Server]

See 

--
Started by an SCM change
Started by an SCM change
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on H35 (ubuntu xenial) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/logging-log4j2.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1794)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git reset --hard" returned 
status code 128:
stdout: 
stderr: fatal: unable to read tree 0ea7b3d65fb95137b65531d1c9277951123986a6

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1970)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1966)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.reset(CliGitAPIImpl.java:463)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:786)
at hudson.plugins.git.GitAPI.clean(GitAPI.java:311)
at sun.reflect.GeneratedMethodAccessor431.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:903)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:855)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H35
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:955)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:283)
at com.sun.proxy.$Proxy118.clean(Unknown Source)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:450)
at 
hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:30)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:884)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecuti

Jenkins build is back to stable : Log4j 2 3.x #247

[Apache Jenkins Server]

See 

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2478:


Github user asfgit closed the pull request at:

https://github.com/apache/logging-log4j2/pull/219


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2478:
-

Commit 81f982555961da1e08dd47e0e377e3858f949949 in logging-log4j2's branch 
refs/heads/master from [~ckozak]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=81f9825 ]

Changelog for LOG4J2-2478

This closes #219


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 pull request #219: LOG4J2-2478 Return the computed variables ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/logging-log4j2/pull/219


---

[jira] [Closed] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[Carter Kozak (JIRA)]

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

Carter Kozak closed LOG4J2-2478.

Resolution: Fixed

> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/220
  
I think cloning large arrays will mitigate any advantages of using 
ReusableParameterizedMessage over ParameterizedMessage.

If we use ParameterizedMessage for large parameter arrays, we can also 
simplify ReusableParameterizedMessage to remove the `varargs` field, and make 
the code easier to read.
This also solves the issue illustrated by my earlier commit where large 
arrays are referenced by 
ReusableParameterizedMessage/MutableLogEvent/RingBufferLogEvent until another 
logger is called with a parameter array.


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #220: [WIP][LOG4J2-2475] ReusableMessageFactory uses no...

[cakofony]

Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/220
  
I think cloning large arrays will mitigate any advantages of using 
ReusableParameterizedMessage over ParameterizedMessage.

If we use ParameterizedMessage for large parameter arrays, we can also 
simplify ReusableParameterizedMessage to remove the `varargs` field, and make 
the code easier to read.
This also solves the issue illustrated by my earlier commit where large 
arrays are referenced by 
ReusableParameterizedMessage/MutableLogEvent/RingBufferLogEvent until another 
logger is called with a parameter array.


---

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[Carter Kozak (JIRA)]

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

Carter Kozak commented on LOG4J2-2478:
--

Merged to master and release-2.x, Thank you for your contribution 
[~DiegoEliasCosta]!

> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-2478:
-

Thank you Carter!

> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2478:
-

Commit 869925c609b5700fba15b8291ddcdfba748cd7c2 in logging-log4j2's branch 
refs/heads/release-2.x from DiegoEliasCosta
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=869925c ]

LOG4J2-2478 Return the computed variables on each benchmark to avoid DCE


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2478:
-

Commit c886016594b2424b787521925c76df85801a0d41 in logging-log4j2's branch 
refs/heads/release-2.x from [~ckozak]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=c886016 ]

Changelog for LOG4J2-2478

This closes #219


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2478:
-

Commit de8b8fbf4687d6fb7e6fba46d69825ced7b862e5 in logging-log4j2's branch 
refs/heads/master from [~ckozak]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=de8b8fb ]

Changelog for LOG4J2-2478


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2478:
-

Commit 2f224d3aa73324a8927fd4304a3cdeb73448b37c in logging-log4j2's branch 
refs/heads/master from DiegoEliasCosta
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=2f224d3 ]

LOG4J2-2478 Return the computed variables on each benchmark to avoid DCE


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/220
  
Good point that we cannot distinguish between parameter arrays created by 
the user (which we shouldn’t reuse) and parameter arrays created by the 
compiler because of a varargs invocation. 

Would it be an idea to clone large (size greater than 10) parameter arrays? 
(And use this cloned array in the reusable message.)

That would ensure we won’t modify user-specified arrays. 


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #220: [WIP][LOG4J2-2475] ReusableMessageFactory uses no...

[remkop]

Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/220
  
Good point that we cannot distinguish between parameter arrays created by 
the user (which we shouldn’t reuse) and parameter arrays created by the 
compiler because of a varargs invocation. 

Would it be an idea to clone large (size greater than 10) parameter arrays? 
(And use this cloned array in the reusable message.)

That would ensure we won’t modify user-specified arrays. 


---

[jira] [Commented] (LOG4J2-2466) ColumnMapping literal not working

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2466:
-

Commit 5815d1b7d153ccffe67642b25b0d4b6b1fb450e1 in logging-log4j2's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=5815d1b ]

[LOG4J2-2466] ColumnMapping literal not working.

> ColumnMapping literal not working
> -
>
> Key: LOG4J2-2466
> URL: https://issues.apache.org/jira/browse/LOG4J2-2466
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.1
>Reporter: Paolo Bonanomi
>Priority: Major
> Fix For: 3.0.0, 2.11.2
>
>
> If i set a literal value in column mapping:
> 
>  
>  
>  
> 
> generated sql is wrong:
> INSERT INTO ... (..) VALUES (?, ... {color:#FF}'myvalue'?{color}, ...)
>  
> I think the problem should be in class JdbcDatabaseManager, row 374. Maybe an 
> else is missing. Please check.
>  
> for (final ColumnMapping mapping : data.columnMappings) {
>  final String mappingName = mapping.getName();
>  if (Strings.isNotEmpty(mapping.getLiteralValue())) {
>  logger().trace("Adding INSERT VALUES literal for ColumnMapping[{}]: {}={} ", 
> i, mappingName, mapping.getLiteralValue());
>  sb.append(mapping.getLiteralValue());
>  }
> {color:#FF}*** missing else ***{color} if 
> (Strings.isNotEmpty(mapping.getParameter())) {
>  logger().trace("Adding INSERT VALUES parameter for ColumnMapping[{}]: {}={} 
> ", i, mappingName, mapping.getParameter());
>  sb.append(mapping.getParameter());
>  columnMappings.add(mapping);
>  } else {
>  logger().trace("Adding INSERT VALUES parameter marker for ColumnMapping[{}]: 
> {}={} ", i, mappingName, PARAMETER_MARKER);
>  sb.append(PARAMETER_MARKER);
>  columnMappings.add(mapping);
>  }
>  sb.append(',');
>  i++;
> }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LOG4J2-2466) ColumnMapping literal not working

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-2466.
--
   Resolution: Fixed
 Assignee: Gary Gregory
Fix Version/s: 2.11.2
   3.0.0

Committed to git master and release-2.x branches. 

Please verify and close if it works for you.

> ColumnMapping literal not working
> -
>
> Key: LOG4J2-2466
> URL: https://issues.apache.org/jira/browse/LOG4J2-2466
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.1
>Reporter: Paolo Bonanomi
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.0.0, 2.11.2
>
>
> If i set a literal value in column mapping:
> 
>  
>  
>  
> 
> generated sql is wrong:
> INSERT INTO ... (..) VALUES (?, ... {color:#FF}'myvalue'?{color}, ...)
>  
> I think the problem should be in class JdbcDatabaseManager, row 374. Maybe an 
> else is missing. Please check.
>  
> for (final ColumnMapping mapping : data.columnMappings) {
>  final String mappingName = mapping.getName();
>  if (Strings.isNotEmpty(mapping.getLiteralValue())) {
>  logger().trace("Adding INSERT VALUES literal for ColumnMapping[{}]: {}={} ", 
> i, mappingName, mapping.getLiteralValue());
>  sb.append(mapping.getLiteralValue());
>  }
> {color:#FF}*** missing else ***{color} if 
> (Strings.isNotEmpty(mapping.getParameter())) {
>  logger().trace("Adding INSERT VALUES parameter for ColumnMapping[{}]: {}={} 
> ", i, mappingName, mapping.getParameter());
>  sb.append(mapping.getParameter());
>  columnMappings.add(mapping);
>  } else {
>  logger().trace("Adding INSERT VALUES parameter marker for ColumnMapping[{}]: 
> {}={} ", i, mappingName, PARAMETER_MARKER);
>  sb.append(PARAMETER_MARKER);
>  columnMappings.add(mapping);
>  }
>  sb.append(',');
>  i++;
> }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2466) ColumnMapping literal not working

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2466:
-

Commit fc5401d40dcb8eddbabe67147f6b3e242478fc47 in logging-log4j2's branch 
refs/heads/release-2.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=fc5401d ]

[LOG4J2-2466] ColumnMapping literal not working.

> ColumnMapping literal not working
> -
>
> Key: LOG4J2-2466
> URL: https://issues.apache.org/jira/browse/LOG4J2-2466
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.1
>Reporter: Paolo Bonanomi
>Priority: Major
>
> If i set a literal value in column mapping:
> 
>  
>  
>  
> 
> generated sql is wrong:
> INSERT INTO ... (..) VALUES (?, ... {color:#FF}'myvalue'?{color}, ...)
>  
> I think the problem should be in class JdbcDatabaseManager, row 374. Maybe an 
> else is missing. Please check.
>  
> for (final ColumnMapping mapping : data.columnMappings) {
>  final String mappingName = mapping.getName();
>  if (Strings.isNotEmpty(mapping.getLiteralValue())) {
>  logger().trace("Adding INSERT VALUES literal for ColumnMapping[{}]: {}={} ", 
> i, mappingName, mapping.getLiteralValue());
>  sb.append(mapping.getLiteralValue());
>  }
> {color:#FF}*** missing else ***{color} if 
> (Strings.isNotEmpty(mapping.getParameter())) {
>  logger().trace("Adding INSERT VALUES parameter for ColumnMapping[{}]: {}={} 
> ", i, mappingName, mapping.getParameter());
>  sb.append(mapping.getParameter());
>  columnMappings.add(mapping);
>  } else {
>  logger().trace("Adding INSERT VALUES parameter marker for ColumnMapping[{}]: 
> {}={} ", i, mappingName, PARAMETER_MARKER);
>  sb.append(PARAMETER_MARKER);
>  columnMappings.add(mapping);
>  }
>  sb.append(',');
>  i++;
> }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2478:


Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/219
  
I can take care of this :-)


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #219: LOG4J2-2478 Return the computed variables on each...

[cakofony]

Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/219
  
I can take care of this :-)


---

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user cakofony closed the pull request at:

https://github.com/apache/logging-log4j2/pull/218


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 pull request #218: [LOG4J2-2475] More efficient parameter res...

[cakofony]

Github user cakofony closed the pull request at:

https://github.com/apache/logging-log4j2/pull/218


---

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


GitHub user cakofony opened a pull request:

https://github.com/apache/logging-log4j2/pull/220

[WIP][LOG4J2-2475] ReusableMessageFactory uses non-reusable messages in 
some cases

Large parameter arrays passed to the logger will result in a
ParameterizedMessage instance being created rather than
adding the varargs to a ReusableParameterizedMessage instance.
This avoids potential mutation of the input array when it
is reused later.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cakofony/logging-log4j2 
reusable_message_object_parameters

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/logging-log4j2/pull/220.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #220


commit 0ea9702ac218aea566f1b40213e99018beb381a3
Author: Carter Kozak 
Date:   2018-10-16T22:18:46Z

[LOG4J2-2475] ReusableMessageFactory uses non-reusable messages in some 
cases

Large parameter arrays passed to the logger will result in a
ParameterizedMessage instance being created rather than
adding the varargs to a ReusableParameterizedMessage instance.
This avoids potential mutation of the input array when it
is reused later.




> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
Pushed the above idea to #220


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #218: [LOG4J2-2475] More efficient parameter reset for ...

[cakofony]

Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
Pushed the above idea to #220


---

[GitHub] logging-log4j2 pull request #220: [WIP][LOG4J2-2475] ReusableMessageFactory ...

[cakofony]

GitHub user cakofony opened a pull request:

https://github.com/apache/logging-log4j2/pull/220

[WIP][LOG4J2-2475] ReusableMessageFactory uses non-reusable messages in 
some cases

Large parameter arrays passed to the logger will result in a
ParameterizedMessage instance being created rather than
adding the varargs to a ReusableParameterizedMessage instance.
This avoids potential mutation of the input array when it
is reused later.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cakofony/logging-log4j2 
reusable_message_object_parameters

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/logging-log4j2/pull/220.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #220


commit 0ea9702ac218aea566f1b40213e99018beb381a3
Author: Carter Kozak 
Date:   2018-10-16T22:18:46Z

[LOG4J2-2475] ReusableMessageFactory uses non-reusable messages in some 
cases

Large parameter arrays passed to the logger will result in a
ParameterizedMessage instance being created rather than
adding the varargs to a ReusableParameterizedMessage instance.
This avoids potential mutation of the input array when it
is reused later.




---

Jenkins build is unstable: Log4j 2 3.x #246

[Apache Jenkins Server]

See 

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
No worries, thank you for your feedback as always!

We might want to consider updating `ReusableMessageFactory.newMessage(final 
String message, final Object... params)` to return a non-reusable 
ParameterizedMessage instance. It seems like a bug that logging an object array 
may result in that array being mutated the next time an event is logged on the 
same thread. It's unfortunate that we cannot differentiate between an array 
passed as a value, and an array created by a varargs invocation.

Thoughts?


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #218: [LOG4J2-2475] More efficient parameter reset for ...

[cakofony]

Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
No worries, thank you for your feedback as always!

We might want to consider updating `ReusableMessageFactory.newMessage(final 
String message, final Object... params)` to return a non-reusable 
ParameterizedMessage instance. It seems like a bug that logging an object array 
may result in that array being mutated the next time an event is logged on the 
same thread. It's unfortunate that we cannot differentiate between an array 
passed as a value, and an array created by a varargs invocation.

Thoughts?


---

[GitHub] logging-log4j2 issue #218: [LOG4J2-2475] More efficient parameter reset for ...

[remkop]

Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
That was fast, thank you Carter!
It looks to me that the difference is just a handful of nanoseconds to null 
out a 1000-element array.

I would expect the ringbuffer to contain mostly small arrays and an 
occasional large array, and only those large arrays would then take an extra 
few nanos to null out.

I do believe that it is more robust to null out the whole array. This 
allows future contributors who are perhaps less familiar with the code to make 
changes without breaking things. 


---

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
That was fast, thank you Carter!
It looks to me that the difference is just a handful of nanoseconds to null 
out a 1000-element array.

I would expect the ringbuffer to contain mostly small arrays and an 
occasional large array, and only those large arrays would then take an extra 
few nanos to null out.

I do believe that it is more robust to null out the whole array. This 
allows future contributors who are perhaps less familiar with the code to make 
changes without breaking things. 


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
n=1000
```
Benchmark  Mode  CntScore   
Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  1406346.075 ± 
82926.012  ops/s
```

n=100
```
Benchmark  Mode  CntScore   
 Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  4332639.602 ± 
232499.236  ops/s
```

n=10
```
Benchmark  Mode  CntScore   
  Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  5480582.409 ± 
1238380.733  ops/s
```

And another run with this change
```
Benchmark  Mode  CntScore   
 Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  5814710.334 ± 
899317.421  ops/s
```


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #218: [LOG4J2-2475] More efficient parameter reset for ...

[cakofony]

Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
n=1000
```
Benchmark  Mode  CntScore   
Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  1406346.075 ± 
82926.012  ops/s
```

n=100
```
Benchmark  Mode  CntScore   
 Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  4332639.602 ± 
232499.236  ops/s
```

n=10
```
Benchmark  Mode  CntScore   
  Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  5480582.409 ± 
1238380.733  ops/s
```

And another run with this change
```
Benchmark  Mode  CntScore   
 Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  5814710.334 ± 
899317.421  ops/s
```


---

[jira] [Commented] (LOG4J2-2478) JMH Benchmarks in not consuming all computed variables (risk of DCE)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2478:


Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/219
  
These are all good changes and we should merge this PR.
Not sure when I can do it but perhaps someone else gets there first.


> JMH Benchmarks in not consuming all computed variables (risk of DCE)
> 
>
> Key: LOG4J2-2478
> URL: https://issues.apache.org/jira/browse/LOG4J2-2478
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Tests
> Environment: I am reporting the result of 5 full executions with 
> default parameters (iterations, forks, warmups, etc..)
> Tests run on a Computational server with CPU: E5-1660-3.3GHZ (6 cores + HT), 
> 64 GB RAM.
>Reporter: Diego Elias Damasceno Costa
>Priority: Minor
> Attachments: logginglog4j2-jmhantipatterns-retu.csv
>
>
> We are conducting a scientific study to investigate bad 
> practices/anti-patterns on creating micro-benchmarks using JMH, and we found 
> an instance of harmfull non-consumed computation in 
> `AbstractStringLayoutStringEncodingBenchmark`.
> As a good practice, every computation performed in inside the benchmark 
> should be consumed (see [JMH 
> Documentation|[http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java].]
>  
> This is partially done here with the self-made consume method, but on some 
> benchmarks (such as baseline, usAsciiGetBytes) the return is not consumed in 
> the benchmark, which opens the possibility of a Dead-Code Elimination to be 
> performed by JVM. 
> *There is a very simple solution:* just return the long primitive calculated 
> by _consume()_ at the end of each benchmark. This is done on other benchmarks 
> of the project as well.
> In our tests, benchmarks were lightly affected (see attachment), with 
> Throughputs 5-35% lower after our fix patch. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LOG4J2-2413) Exceptions are added to all columns when a JDBC Appender's ColumnMapping uses a Pattern

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-2413.
--
   Resolution: Fixed
 Assignee: Gary Gregory
Fix Version/s: 2.11.2
   3.0.0

I created a different test case but the main change is the same as your patch.

Please verify and close this ticket if it works for you.

> Exceptions are added to all columns when a JDBC Appender's ColumnMapping uses 
> a Pattern
> ---
>
> Key: LOG4J2-2413
> URL: https://issues.apache.org/jira/browse/LOG4J2-2413
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.1
>Reporter: Andres Luuk
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.0.0, 2.11.2
>
>
> I think there is a bug in ColumnMapping build() on creating the Layout from 
> pattern.
> It should also include: .withAlwaysWriteExceptions(false) in there.
> Currently if you add logger.error(e.getMessage(), e) somewhere it will try to 
> insert the stack into every database field if patterns is used to create the 
> ColumnMapping's.
> This comes from the default behaviour of PatternLayout that in case of an 
> excepiton it tryes to add it in the end of every pattern.
> But if you have Multiple columins in your table with JDBCAppender then you 
> probably have other metadata on those fields then the actual exception and 
> you will get an insertion error on most fields because the data is to big.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #219: LOG4J2-2478 Return the computed variables on each...

[remkop]

Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/219
  
These are all good changes and we should merge this PR.
Not sure when I can do it but perhaps someone else gets there first.


---

[jira] [Commented] (LOG4J2-2472) Update mongo-java-driver 3 from 3.8.0 to 3.8.2.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2472:
-

Commit beed8107eeb477b7313aa9e457de70cb33c0a473 in logging-log4j2's branch 
refs/heads/release-2.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=beed810 ]

[LOG4J2-2472] Exceptions are added to all columns when a JDBC Appender's
ColumnMapping uses a Pattern.

> Update mongo-java-driver 3 from 3.8.0 to 3.8.2.
> ---
>
> Key: LOG4J2-2472
> URL: https://issues.apache.org/jira/browse/LOG4J2-2472
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.0.0, 2.11.2
>
>
> Update mongo-java-driver 3 from 3.8.0 to 3.8.2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2472) Update mongo-java-driver 3 from 3.8.0 to 3.8.2.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2472:
-

Commit 4613ba9fec04933cc73a351dfb2ed5fb6000ad27 in logging-log4j2's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=4613ba9 ]

[LOG4J2-2472] Exceptions are added to all columns when a JDBC Appender's
ColumnMapping uses a Pattern.

> Update mongo-java-driver 3 from 3.8.0 to 3.8.2.
> ---
>
> Key: LOG4J2-2472
> URL: https://issues.apache.org/jira/browse/LOG4J2-2472
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.0.0, 2.11.2
>
>
> Update mongo-java-driver 3 from 3.8.0 to 3.8.2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user garydgregory commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
One "realistic" example would be to think of logging against a database
table. Some tables have lots of columns. How many, well, a thousand is
possible I suppose.

Gary

On Tue, Oct 16, 2018 at 3:55 PM Remko Popma 
wrote:

> I cannot imagine any program logging one million parameters so this
> benchmark is perhaps a bit academic. :-)
> In a realistic program a "large" parameter array is probably more like 100
> elements (and I would not like to maintain a program that has a logging
> statement with 100 parameters).
>
> Can we measure again with an extreme case of 1000 parameters?
>
> I suspect that with an array of 1000 (or even 10,000) elements we won't
> see much difference between nulling out only the first 10 or the full
> array, in which case it is more robust to simply null out the whole array.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #218: [LOG4J2-2475] More efficient parameter reset for ...

[garydgregory]

Github user garydgregory commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
One "realistic" example would be to think of logging against a database
table. Some tables have lots of columns. How many, well, a thousand is
possible I suppose.

Gary

On Tue, Oct 16, 2018 at 3:55 PM Remko Popma 
wrote:

> I cannot imagine any program logging one million parameters so this
> benchmark is perhaps a bit academic. :-)
> In a realistic program a "large" parameter array is probably more like 100
> elements (and I would not like to maintain a program that has a logging
> statement with 100 parameters).
>
> Can we measure again with an extreme case of 1000 parameters?
>
> I suspect that with an array of 1000 (or even 10,000) elements we won't
> see much difference between nulling out only the first 10 or the full
> array, in which case it is more robust to simply null out the whole array.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
I cannot imagine any program logging one million parameters so this 
benchmark is perhaps a bit academic. :-)
In a realistic program a "large" parameter array is probably more like 100 
elements (and I would not like to maintain a program that has a logging 
statement with 100 parameters).

Can we measure again with an extreme case of 1000 parameters?

I suspect that with an array of 1000 (or even 10,000) elements we won't see 
much difference between nulling out only the first 10 or the full array, in 
which case it is more robust to simply null out the whole array.



> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #218: [LOG4J2-2475] More efficient parameter reset for ...

[remkop]

Github user remkop commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
I cannot imagine any program logging one million parameters so this 
benchmark is perhaps a bit academic. :-)
In a realistic program a "large" parameter array is probably more like 100 
elements (and I would not like to maintain a program that has a logging 
statement with 100 parameters).

Can we measure again with an extreme case of 1000 parameters?

I suspect that with an array of 1000 (or even 10,000) elements we won't see 
much difference between nulling out only the first 10 or the full array, in 
which case it is more robust to simply null out the whole array.



---

[jira] [Updated] (LOG4J2-2413) Exceptions are added to all columns when a JDBC Appender's ColumnMapping uses a Pattern

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-2413:
-
Summary: Exceptions are added to all columns when a JDBC Appender's 
ColumnMapping uses a Pattern  (was: Using JDBCAppender-s ColumnMapping with 
Pattern)

> Exceptions are added to all columns when a JDBC Appender's ColumnMapping uses 
> a Pattern
> ---
>
> Key: LOG4J2-2413
> URL: https://issues.apache.org/jira/browse/LOG4J2-2413
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.1
>Reporter: Andres Luuk
>Priority: Major
>
> I think there is a bug in ColumnMapping build() on creating the Layout from 
> pattern.
> It should also include: .withAlwaysWriteExceptions(false) in there.
> Currently if you add logger.error(e.getMessage(), e) somewhere it will try to 
> insert the stack into every database field if patterns is used to create the 
> ColumnMapping's.
> This comes from the default behaviour of PatternLayout that in case of an 
> excepiton it tryes to add it in the end of every pattern.
> But if you have Multiple columins in your table with JDBCAppender then you 
> probably have other metadata on those fields then the actual exception and 
> you will get an insertion error on most fields because the data is to big.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jenkins build is back to normal : Log4j 2 2.x #3644

[Apache Jenkins Server]

See 

Build failed in Jenkins: Log4j 2 3.x #245

[Apache Jenkins Server]

See 


Changes:

[ggregory] Javadoc.

[ggregory] Javadoc.

--
[...truncated 1.03 MB...]
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/logging/log4j/samples/log4j-samples-loggerProperties/3.0.0-SNAPSHOT/log4j-samples-loggerProperties-3.0.0-SNAPSHOT-sources.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/logging/log4j/samples/log4j-samples-loggerProperties/3.0.0-SNAPSHOT/log4j-samples-loggerProperties-3.0.0-SNAPSHOT-test-sources.jar
[INFO] 
[INFO] 
[INFO] Building Apache Log4j BOM 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ log4j-bom ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ log4j-bom ---
[INFO] 
[INFO] --- maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @ 
log4j-bom ---
[INFO] No site descriptor found: nothing to attach.
[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ log4j-bom ---
[INFO] Installing 
 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/logging/log4j/log4j-bom/3.0.0-SNAPSHOT/log4j-bom-3.0.0-SNAPSHOT.pom
[INFO] 
[INFO] 
[INFO] Building Apache Log4j JDBC 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ log4j-jdbc ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ log4j-jdbc ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ log4j-jdbc ---
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ 
log4j-jdbc ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ log4j-jdbc 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 11 source files to 

Processing annotations
Annotations processed
Processing annotations
No elements to process
[INFO] 
[INFO] --- maven-bundle-plugin:3.5.0:manifest (default) @ log4j-jdbc ---
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ 
log4j-jdbc ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ 
log4j-jdbc ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 14 source files to 

[INFO] -
[WARNING] COMPILATION WARNING : 
[INFO] -
[WARNING] No processor claimed any of these annotations: 
org.junit.Rule,org.junit.After,org.junit.runner.RunWith,org.junit.runners.Parameterized.Parameters,org.junit.Test,org.junit.ClassRule
[INFO] 1 warning
[INFO] -
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[23,32]
 package org.apache.commons.lang3 does not exist
[INFO] 1 error
[INFO] -
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Log4j 2 . SUCCESS [ 20.383 s]
[INFO] Apache Log4j API Java 9 support  SUCCESS [ 51.475 s]
[INFO] Apache Log4j API ... SUCCESS [01:13 min]
[INFO] Apache Log4j Core Java 9 support ... SUCCESS [  5.89

Build failed in Jenkins: Log4j 2 2.x #3643

[Apache Jenkins Server]

See 

--
[...truncated 10.40 MB...]
  while locating org.eclipse.aether.impl.RemoteRepositoryManager
for parameter 10 at 
org.eclipse.aether.internal.impl.DefaultRepositorySystem.(DefaultRepositorySystem.java:121)
  while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.eclipse.aether.RepositorySystem
  while locating org.apache.maven.artifact.resolver.DefaultArtifactResolver
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.apache.maven.artifact.resolver.ArtifactResolver
  while locating org.apache.maven.repository.legacy.LegacyRepositorySystem
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.apache.maven.repository.RepositorySystem
  while locating 
org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.apache.maven.execution.MavenExecutionRequestPopulator
Caused by: java.lang.IllegalArgumentException: Can not set 
org.eclipse.aether.spi.log.Logger field 
org.eclipse.aether.internal.impl.DefaultUpdatePolicyAnalyzer.logger to 
org.eclipse.aether.internal.impl.PlexusLoggerFactory
at 
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
at 
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
at 
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:764)
at 
org.eclipse.sisu.bean.BeanPropertyField.set(BeanPropertyField.java:74)
at 
org.eclipse.sisu.plexus.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:48)
at 
org.eclipse.sisu.bean.BeanInjector.injectMembers(BeanInjector.java:52)
at 
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:140)
at 
com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
at 
com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
at 
com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at 
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at 
com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
at 
com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at 
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at 
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at 
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at 
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at 
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallb

Build failed in Jenkins: Log4j 2 2.x #3642

[Apache Jenkins Server]

See 


Changes:

[garydgregory] Bullet-proof JDBC tests by always calling the SQL DDL to dropo a 
table

--
[...truncated 10.46 MB...]
  while locating org.eclipse.aether.impl.RemoteRepositoryManager
for parameter 10 at 
org.eclipse.aether.internal.impl.DefaultRepositorySystem.(DefaultRepositorySystem.java:121)
  while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.eclipse.aether.RepositorySystem
  while locating org.apache.maven.artifact.resolver.DefaultArtifactResolver
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.apache.maven.artifact.resolver.ArtifactResolver
  while locating org.apache.maven.repository.legacy.LegacyRepositorySystem
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.apache.maven.repository.RepositorySystem
  while locating 
org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via 
modules: org.eclipse.sisu.wire.WireModule -> 
org.eclipse.sisu.plexus.PlexusBindingModule)
  while locating org.apache.maven.execution.MavenExecutionRequestPopulator
Caused by: java.lang.IllegalArgumentException: Can not set 
org.eclipse.aether.spi.log.Logger field 
org.eclipse.aether.internal.impl.DefaultUpdatePolicyAnalyzer.logger to 
org.eclipse.aether.internal.impl.PlexusLoggerFactory
at 
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
at 
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
at 
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:764)
at 
org.eclipse.sisu.bean.BeanPropertyField.set(BeanPropertyField.java:74)
at 
org.eclipse.sisu.plexus.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:48)
at 
org.eclipse.sisu.bean.BeanInjector.injectMembers(BeanInjector.java:52)
at 
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:140)
at 
com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
at 
com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
at 
com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at 
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at 
com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
at 
com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at 
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at 
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at 
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at 
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at 
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
 

Build failed in Jenkins: Log4j 2 3.x #244

[Apache Jenkins Server]

See 


Changes:

[garydgregory] Bullet-proof JDBC tests by always calling the SQL DDL to dropo a 
table

--
[...truncated 1.09 MB...]
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/logging/log4j/samples/log4j-samples-loggerProperties/3.0.0-SNAPSHOT/log4j-samples-loggerProperties-3.0.0-SNAPSHOT-sources.jar
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/logging/log4j/samples/log4j-samples-loggerProperties/3.0.0-SNAPSHOT/log4j-samples-loggerProperties-3.0.0-SNAPSHOT-test-sources.jar
[INFO] 
[INFO] 
[INFO] Building Apache Log4j BOM 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ log4j-bom ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ log4j-bom ---
[INFO] 
[INFO] --- maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @ 
log4j-bom ---
[INFO] No site descriptor found: nothing to attach.
[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ log4j-bom ---
[INFO] Installing 
 to 
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/logging/log4j/log4j-bom/3.0.0-SNAPSHOT/log4j-bom-3.0.0-SNAPSHOT.pom
[INFO] 
[INFO] 
[INFO] Building Apache Log4j JDBC 3.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ log4j-jdbc ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ log4j-jdbc ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ log4j-jdbc ---
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ 
log4j-jdbc ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ log4j-jdbc 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 11 source files to 

Processing annotations
Annotations processed
Processing annotations
No elements to process
[INFO] 
[INFO] --- maven-bundle-plugin:3.5.0:manifest (default) @ log4j-jdbc ---
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ 
log4j-jdbc ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ 
log4j-jdbc ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 14 source files to 

[INFO] -
[WARNING] COMPILATION WARNING : 
[INFO] -
[WARNING] No processor claimed any of these annotations: 
org.junit.Rule,org.junit.After,org.junit.runner.RunWith,org.junit.runners.Parameterized.Parameters,org.junit.Test,org.junit.ClassRule
[INFO] 1 warning
[INFO] -
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[23,32]
 package org.apache.commons.lang3 does not exist
[INFO] 1 error
[INFO] -
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Log4j 2 . SUCCESS [ 23.690 s]
[INFO] Apache Log4j API Java 9 support  SUCCESS [01:15 min]
[INFO] Apache Log4j API ... SUCCESS [01:09 min]
[INFO] Apache Log4j Core Java

Jenkins build is back to normal : Log4j 2 2.x #3641

[Apache Jenkins Server]

See 

[jira] [Commented] (LOG4J2-2475) Limit reusable event.clear parameter clearing to argsCount

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2475:


Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
In most cases, I don't think this will make much difference because setting 
all 10 spots in a the reusable parameter buffer is incredibly fast.

This aims to solve problems that arise when a larger parameter array is 
passed to a logger, since that array will be reused and passed between 
MutableLogEvent (or RingBufferLogEvent) and ReusableParameterizedMessage. I 
don't want to discard parameter arrays above a given threshold because there 
are scenarios where we would want to allow them to be reused, but we also don't 
want to iterate over each index and set it to null if we know there's only a 
single parameter.

I've put together a simple benchmark to illustrate performance 
implications. It's fairly contrived, close to the worst case scenario.

Without this change:
```
Benchmark  Mode  Cnt ScoreError 
 Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  1706.636 ± 89.416 
 ops/s
```

With this change:
```
Benchmark  Mode  CntScore   
  Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  5472588.826 ± 
1029286.946  ops/s
```


> Limit reusable event.clear parameter clearing to argsCount
> --
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the 
> logger directly. These may take longer to clear, despite only containing one 
> or two parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] logging-log4j2 issue #218: [LOG4J2-2475] More efficient parameter reset for ...

[cakofony]

Github user cakofony commented on the issue:

https://github.com/apache/logging-log4j2/pull/218
  
In most cases, I don't think this will make much difference because setting 
all 10 spots in a the reusable parameter buffer is incredibly fast.

This aims to solve problems that arise when a larger parameter array is 
passed to a logger, since that array will be reused and passed between 
MutableLogEvent (or RingBufferLogEvent) and ReusableParameterizedMessage. I 
don't want to discard parameter arrays above a given threshold because there 
are scenarios where we would want to allow them to be reused, but we also don't 
want to iterate over each index and set it to null if we know there's only a 
single parameter.

I've put together a simple benchmark to illustrate performance 
implications. It's fairly contrived, close to the worst case scenario.

Without this change:
```
Benchmark  Mode  Cnt ScoreError 
 Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  1706.636 ± 
89.416  ops/s
```

With this change:
```
Benchmark  Mode  CntScore   
  Error  Units
ManyParametersInSetupBenchmark.fewParameters  thrpt3  5472588.826 ± 
1029286.946  ops/s
```


---

[jira] [Commented] (LOG4NET-613) Adding JSON serialization layout

[Dominik Psenner (JIRA)]

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

Dominik Psenner commented on LOG4NET-613:
-

What do you mean with component? An extension is typically an assembly (dll) 
that is referenced in the application and configuration file. This means that 
the extension codebase consists of at least a csproj file and a class that 
implements the functionality. That codebase could live in the core repository. 
In that case the build scripts would trigger the build and test the resulting 
artifacts. Adding the codebase can be achieved with a pull request. Since the 
contribution appears to be significant, you will have ti sign and file an ICLA 
as well.

> Adding JSON serialization layout
> 
>
> Key: LOG4NET-613
> URL: https://issues.apache.org/jira/browse/LOG4NET-613
> Project: Log4net
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.0.8
>Reporter: Jo Cutajar
>Priority: Minor
> Fix For: 2.1.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Hi,
> I've created an extension which will effectively enable Json logging from 
> log4net. It is implemented as a Layout so it can be used with pretty much any 
> appender, especially the UDP appender :o). The aim is to enable fast local 
> UDP drop off for logs in combination with nxlog. But I took care to allow 
> code reuse and flexibility.
> Project: [https://gitlab.com/BrightOpen/log4net.Ext.Json]
> Please help me [integrate this into 
> log4net|https://gitlab.com/BrightOpen/log4net.Ext.Json/issues/1].
> Thanks, Jo



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (LOG4J2-2477) the thread of asyncLogger is more and more

[wupj (JIRA)]

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

wupj closed LOG4J2-2477.

Resolution: Won't Do

> the thread of asyncLogger is more and more 
> ---
>
> Key: LOG4J2-2477
> URL: https://issues.apache.org/jira/browse/LOG4J2-2477
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core
>Affects Versions: 2.7
> Environment: version :2.7
>Reporter: wupj
>Priority: Major
> Attachments: image-2018-10-15-14-32-09-319.png, 
> image-2018-10-15-14-32-39-369.png
>
>
> I don't why the the thread of 
> Log4j2-TF-1-AsyncLogger[AsyncContext@236e4a57]-1  is more and more. now it's 
> 626,436,984 (TIMED_WAITING).as picture  !image-2018-10-15-14-32-09-319.png!
> The config of AsyncLogger.WaitStrategy is 'Sleep'.
> Although it's more and more ,the cpu and membery is  seeing working well. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)