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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor49.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at h

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

[Apache Jenkins Server]

See 

--
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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
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.$Proxy117.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.mo

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

[Apache Jenkins Server]

See 

--
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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
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.$Proxy117.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.mo

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key and make the cache entry map be global

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}
- We made the benchmark test to  compares the performance of ThrowableProxy 
optimizations for different exception
-  baseline: test `ThrowableProxy` in log4j2, not optimized, with bug, 
for comparison consideration.
-  bugfixed: fixed bug in `ThrowableProxy` accessing the cache.
-  optimized: make the cache global, instead of a new one for each 
exception instance.

Then we see
* more than `10` times improvement when the bug is fixed for exceptions with 
stack element class duplicated many times.
* and about `2` times further improvement when make the cache global (compared 
with log4j2, more than `20` times improvement).
- benchmark test detail: 
https://github.com/liuwenchn/log4j2-throwableproxy-benchmark
- PR: https://github.com/apache/logging-log4j2/pull/195
 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}
- We made the benchmark test to  compares the performance of ThrowableProxy 
optimizations for different exception
-  baseline: test `ThrowableProxy` in log4j2, not optimized, with bug, 
for comparison consideration.
-  bugfixed: fixed bug in `ThrowableProxy` accessing the cache.
-  optimized: make the cache global, instead of a new one for each 
exception instance.

Then we see
* more than `10` times improvement when the bug is fixed for exceptions with 
stack element class duplicated many times.
* and about `2` times further improvement when make the cache global (compared 
with log4j2, more than `20` times improvement).
- detail: https://github.com/liuwenchn/log4j2-throwableproxy-benchmark
 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with 

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key and make the cache entry map be global

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Summary: fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to 
be put and gotten with same key and  make the cache entry map be global  (was: 
fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key and )

> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key and  make the cache entry map be global
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism in the method loadClass
>  - In addition to fixing the problem, I think cache map could be made global, 
> instead of a new one for each exception instance. 
> {code:java}
> private ThrowableProxy(final Throwable throwable, final Set 
> visited) {
> ...
> final Map map = new HashMap<>();
> this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null, 
>  
> throwable.getStackTrace());
> ...
>  }
> {code}
> - We made the benchmark test to  compares the performance of ThrowableProxy 
> optimizations for different exception
> -  baseline: test `ThrowableProxy` in log4j2, not optimized, with 
> bug, for comparison consideration.
> -  bugfixed: fixed bug in `ThrowableProxy` accessing the cache.
> -  optimized: make the cache global, instead of a new one for each 
> exception instance.
> Then we see
> * more than `10` times improvement when the bug is fixed for exceptions with 
> stack element class duplicated many times.
> * and about `2` times further improvement when make the cache global 
> (compared with log4j2, more than `20` times improvement).
> - detail: https://github.com/liuwenchn/log4j2-throwableproxy-benchmark
>  



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key and

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Summary: fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to 
be put and gotten with same key and   (was: fix the CacheEntry map in 
ThrowableProxy#toExtendedStackTrace to be put and gotten with same key)

> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key and 
> -
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism in the method loadClass
>  - In addition to fixing the problem, I think cache map could be made global, 
> instead of a new one for each exception instance. 
> {code:java}
> private ThrowableProxy(final Throwable throwable, final Set 
> visited) {
> ...
> final Map map = new HashMap<>();
> this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null, 
>  
> throwable.getStackTrace());
> ...
>  }
> {code}
> - We made the benchmark test to  compares the performance of ThrowableProxy 
> optimizations for different exception
> -  baseline: test `ThrowableProxy` in log4j2, not optimized, with 
> bug, for comparison consideration.
> -  bugfixed: fixed bug in `ThrowableProxy` accessing the cache.
> -  optimized: make the cache global, instead of a new one for each 
> exception instance.
> Then we see
> * more than `10` times improvement when the bug is fixed for exceptions with 
> stack element class duplicated many times.
> * and about `2` times further improvement when make the cache global 
> (compared with log4j2, more than `20` times improvement).
> - detail: https://github.com/liuwenchn/log4j2-throwableproxy-benchmark
>  



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}
- We made the benchmark test to  compares the performance of ThrowableProxy 
optimizations for different exception
-  baseline: test `ThrowableProxy` in log4j2, not optimized, with bug, 
for comparison consideration.
-  bugfixed: fixed bug in `ThrowableProxy` accessing the cache.
-  optimized: make the cache global, instead of a new one for each 
exception instance.

Then we see
* more than `10` times improvement when the bug is fixed for exceptions with 
stack element class duplicated many times.
* and about `2` times further improvement when make the cache global (compared 
with log4j2, more than `20` times improvement).
- detail: https://github.com/liuwenchn/log4j2-throwableproxy-benchmark
 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}
- We made the benchmark test to  compares the performance of ThrowableProxy 
optimizations for different exception
-  baseline: test `ThrowableProxy` in log4j2, not optimized, with bug, 
for comparison consideration.
-  bugfixed: fixed bug in `ThrowableProxy` accessing the cache.
-  optimized: make the cache global, instead of a new one for each 
exception instance.

Then we see
* more than `10` times improvement when the bug is fixed for exceptions with 
stack element class duplicated many times.
* and about `2` times further improvement when make the cache global (compared 
with log4j2, more than `20` times improvement).

 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-23

[jira] [Closed] (LOG4J2-2390) Fix incorrect links in Log4j web documentation.

[Ralph Goers (JIRA)]

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

Ralph Goers closed LOG4J2-2390.
---

> Fix incorrect links in Log4j web documentation.
> ---
>
> Key: LOG4J2-2390
> URL: https://issues.apache.org/jira/browse/LOG4J2-2390
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Web/Servlet
>Affects Versions: 2.11.0
>Reporter: Ralph Goers
>Priority: Major
> Fix For: 2.11.1
>
>




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

[jira] [Resolved] (LOG4J2-2390) Fix incorrect links in Log4j web documentation.

[Ralph Goers (JIRA)]

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

Ralph Goers resolved LOG4J2-2390.
-
Resolution: Fixed

Commits merged.

> Fix incorrect links in Log4j web documentation.
> ---
>
> Key: LOG4J2-2390
> URL: https://issues.apache.org/jira/browse/LOG4J2-2390
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Web/Servlet
>Affects Versions: 2.11.0
>Reporter: Ralph Goers
>Priority: Major
> Fix For: 2.11.1
>
>




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

[GitHub] logging-log4j2 pull request #167: (doc) fix links to java docs, the correct ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[Apache Jenkins Server]

See 

--
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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
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.$Proxy117.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.mo

[jira] [Commented] (LOG4J2-2390) Fix incorrect links in Log4j web documentation.

[ASF subversion and git services (JIRA)]

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

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

Commit 53fac8e80f299de141a5481a54b6198662e807ae in logging-log4j2's branch 
refs/heads/master from [~ralph.go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=53fac8e ]

LOG4J2-2390 - Fix broken links in log4j web documentation


> Fix incorrect links in Log4j web documentation.
> ---
>
> Key: LOG4J2-2390
> URL: https://issues.apache.org/jira/browse/LOG4J2-2390
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Web/Servlet
>Affects Versions: 2.11.0
>Reporter: Ralph Goers
>Priority: Major
> Fix For: 2.11.1
>
>




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

[jira] [Commented] (LOG4J2-2390) Fix incorrect links in Log4j web documentation.

[ASF subversion and git services (JIRA)]

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

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

Commit 61732f34b9925f4d9f950d4429d3ef28e65bc4f2 in logging-log4j2's branch 
refs/heads/release-2.x from Anton.Balaniuc
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=61732f3 ]

LOG4J2-2390 - Fix broken links in log4j web documentation


> Fix incorrect links in Log4j web documentation.
> ---
>
> Key: LOG4J2-2390
> URL: https://issues.apache.org/jira/browse/LOG4J2-2390
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Web/Servlet
>Affects Versions: 2.11.0
>Reporter: Ralph Goers
>Priority: Major
> Fix For: 2.11.1
>
>




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

[GitHub] logging-log4j2 issue #167: (doc) fix links to java docs, the correct path is...

[rgoers]

Github user rgoers commented on the issue:

https://github.com/apache/logging-log4j2/pull/167
  
Log4j-2390 created to track this.


---

[jira] [Created] (LOG4J2-2390) Fix incorrect links in Log4j web documentation.

[Ralph Goers (JIRA)]

Ralph Goers created LOG4J2-2390:
---

 Summary: Fix incorrect links in Log4j web documentation.
 Key: LOG4J2-2390
 URL: https://issues.apache.org/jira/browse/LOG4J2-2390
 Project: Log4j 2
  Issue Type: Bug
  Components: Web/Servlet
Affects Versions: 2.11.0
Reporter: Ralph Goers
 Fix For: 2.11.1






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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}
- We made the benchmark test to  compares the performance of ThrowableProxy 
optimizations for different exception
-  baseline: test `ThrowableProxy` in log4j2, not optimized, with bug, 
for comparison consideration.
-  bugfixed: fixed bug in `ThrowableProxy` accessing the cache.
-  optimized: make the cache global, instead of a new one for each 
exception instance.

Then we see
* more than `10` times improvement when the bug is fixed for exceptions with 
stack element class duplicated many times.
* and about `2` times further improvement when make the cache global (compared 
with log4j2, more than `20` times improvement).

 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}

 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTra

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

[Apache Jenkins Server]

See 

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}

 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass

{code:java}
final String className = stackTraceElement.getClassName();{code}
... 
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 

{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null, 
throwable.getStackTrace());
...
}
{code}

 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of 

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass

{code:java}
final String className = stackTraceElement.getClassName();{code}
... 
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 

{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null, 
throwable.getStackTrace());
...
}
{code}

 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}

 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();{code}
> ... 
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main im

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null,  
throwable.getStackTrace());
...
 }
{code}

 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null, 
throwable.getStackTrace());
...
}
{code}



 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the prob

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 
{code:java}
private ThrowableProxy(final Throwable throwable, final Set visited) 
{
...
final Map map = new HashMap<>();
this.extendedStackTrace = this.toExtendedStackTrace(stack, map, null, 
throwable.getStackTrace());
...
}
{code}



 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 

 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism in the method loadClass
>  - In addition to fixing the problem, I think cache map could be m

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 

 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism in the method loadClass
>  - In addition to fixing the problem, I think cache map could be made global, 
> instead of a new one for each exception instance. 
>  



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass
 - In addition to fixing the problem, I think cache map could be made global, 
instead of a new one for each exception instance. 

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism in the method loadClass
>  - In addition to fixing the problem, I think cache map could be made global, 
> instead of a new one for each exception instance. 



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method loadClass

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method of loading class


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism in the method loadClass



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism in the method of loading class

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism in the method of loading class



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

 - The main impact of the problem was that it would increase of frequency of 
loading classes ,which led to the execution of the program be slow down, 
because of the synchronization mechanism

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}
- The main impact of the problem was that it would increase of frequency of  
loading Classes ,which  led to the execution of the program be slow down, 
because of the synchronization mechanism


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
>  - The main impact of the problem was that it would increase of frequency of 
> loading classes ,which led to the execution of the program be slow down, 
> because of the synchronization mechanism



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}
- The main impact of the problem was that it would increase of frequency of  
loading Classes ,which  led to the execution of the program be slow down, 
because of the synchronization mechanism

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}
- The main impact of the problem  


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
> - The main impact of the problem was that it would increase of frequency of  
> loading Classes ,which  led to the execution of the program be slow down, 
> because of the synchronization mechanism



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

[jira] [Commented] (LOG4J2-2331) Rolling file appender concatenating debug message instead of using formatting

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2331:


Github user asfgit closed the pull request at:

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


> Rolling file appender concatenating debug message instead of using formatting
> -
>
> Key: LOG4J2-2331
> URL: https://issues.apache.org/jira/browse/LOG4J2-2331
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.11.0
> Environment: Any - Mac with log4j 2.11.0 using `-Dlog4j.debug` and a 
> RollingFileAppender
>Reporter: Michael Wells Baranski
>Assignee: Carter Kozak
>Priority: Minor
>  Labels: easyfix
> Fix For: 3.0.0, 2.11.1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When debug is on, RollingFileAppender prints the shutdown message and 
> concatenates the name, instead of passing it as an argument to be formatted:
> `"Shutting down RollingFileManager {}" + getName()`
> should be:
> `"Shutting down RollingFileManager {}", getName()`



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

[GitHub] logging-log4j2 pull request #172: Fix for https://issues.apache.org/jira/bro...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}
- The main impact of the problem  

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}
> - The main impact of the problem  



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
 * stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class, just as org.apache.logging.log4j.MyClass
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

  was:
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
* stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
>  * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class, just as org.apache.logging.log4j.MyClass
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
gotten with same key
* stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

  was:
* stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}



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

[jira] [Updated] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

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

LIU WEN updated LOG4J2-2389:

Description: 
* stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class
{code:java}
final String className = stackTraceElement.getClassName();
……
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}

  was:
* stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class
{code:java}
final String className = stackTraceElement.getClassName();
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}


> fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and 
> gotten with same key
> 
>
> Key: LOG4J2-2389
> URL: https://issues.apache.org/jira/browse/LOG4J2-2389
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 
> 2.11.0
>Reporter: LIU WEN
>Priority: Major
>
> * stackTraceElement.toString() returns a string representation of this stack 
> trace element, just as MyClass.mash(MyClass.java)
>  * stackTraceElement.getClassName() returns the fully qualified name of the 
> Class
> {code:java}
> final String className = stackTraceElement.getClassName();
> ……
> final CacheEntry cacheEntry = map.get(className);
> if (cacheEntry != null) {
>   final CacheEntry entry = cacheEntry;
>   extClassInfo = entry.element;
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> } else {
>   final CacheEntry entry = this.toCacheEntry(stackTraceElement,
>   this.loadClass(lastLoader, className), false);
>   extClassInfo = entry.element;
>   map.put(stackTraceElement.toString(), entry);
>   if (entry.loader != null) {
>  lastLoader = entry.loader;
>   }
> }
> {code}



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

[jira] [Created] (LOG4J2-2389) fix the CacheEntry map in ThrowableProxy#toExtendedStackTrace to be put and gotten with same key

[LIU WEN (JIRA)]

LIU WEN created LOG4J2-2389:
---

 Summary: fix the CacheEntry map in 
ThrowableProxy#toExtendedStackTrace to be put and gotten with same key
 Key: LOG4J2-2389
 URL: https://issues.apache.org/jira/browse/LOG4J2-2389
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.11.0, 2.10.0, 2.9.1, 2.9.0, 2.8.2, 2.8.1, 2.8, 2.7, 
2.6.2
Reporter: LIU WEN


* stackTraceElement.toString() returns a string representation of this stack 
trace element, just as MyClass.mash(MyClass.java)
 * stackTraceElement.getClassName() returns the fully qualified name of the 
Class
{code:java}
final String className = stackTraceElement.getClassName();
final CacheEntry cacheEntry = map.get(className);
if (cacheEntry != null) {
  final CacheEntry entry = cacheEntry;
  extClassInfo = entry.element;
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
} else {
  final CacheEntry entry = this.toCacheEntry(stackTraceElement,
  this.loadClass(lastLoader, className), false);
  extClassInfo = entry.element;
  map.put(stackTraceElement.toString(), entry);
  if (entry.loader != null) {
 lastLoader = entry.loader;
  }
}
{code}



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

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

[Apache Jenkins Server]

See 

--
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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
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.$Proxy117.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.mo

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

[Apache Jenkins Server]

See 

--
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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
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.$Proxy117.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.mo

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-2388:
--

[~ralph.go...@dslextreme.com], I forgot the "closes" comment for githib but the 
user closed the PR.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Closed] (LOG4J2-2377) NullPointerException in org.apache.logging.log4j.util.LoaderUtil.getClassLoaders() when using Bootstrap class loader

[Gary Gregory (JIRA)]

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

Gary Gregory closed LOG4J2-2377.


Closing per user report.

> NullPointerException in 
> org.apache.logging.log4j.util.LoaderUtil.getClassLoaders() when using 
> Bootstrap class loader
> 
>
> Key: LOG4J2-2377
> URL: https://issues.apache.org/jira/browse/LOG4J2-2377
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.9.1, 2.10.0, 2.11.0
>Reporter: Mirko Rzehak
>Priority: Blocker
> Fix For: 3.0.0, 2.11.1
>
>
> When log4j2 classes are loaded via the Bootstrap classloader, creating a 
> Logger ({{LogManager.getLogger()}}) causes a NullPointerException:
> {code:java}
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at Test.(Test.java:6)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.util.LoaderUtil.getClassLoaders(LoaderUtil.java:115)
>   at 
> org.apache.logging.log4j.util.ProviderUtil.(ProviderUtil.java:66)
>   at 
> org.apache.logging.log4j.util.ProviderUtil.lazyInit(ProviderUtil.java:146)
>   at 
> org.apache.logging.log4j.util.ProviderUtil.hasProviders(ProviderUtil.java:130)
>   at org.apache.logging.log4j.LogManager.(LogManager.java:89)
>   ... 1 more
> {code}
> To reproduce this behavior I put the log4j jar files (log4j-api and 
> log4j-core) into a dedicated directory and start my test program with 
> {{-Djava.endorsed.dirs=dirname}}. Classes from jars in that directory are 
> loaded using the Bootstrap classloader.
>  
> The issue came with 2.9.1. It worked with 2.9.0 and earlier versions.



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

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2388:


Github user failled commented on the issue:

https://github.com/apache/logging-log4j2/pull/196
  
PR has been merged


> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2388:


Github user failled closed the pull request at:

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


> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[GitHub] logging-log4j2 pull request #196: Fix LOG4J2-2388 / Blocking thread when log...

[failled]

Github user failled closed the pull request at:

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


---

[GitHub] logging-log4j2 issue #196: Fix LOG4J2-2388 / Blocking thread when logging me...

[failled]

Github user failled commented on the issue:

https://github.com/apache/logging-log4j2/pull/196
  
PR has been merged


---

[jira] [Closed] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[Failled (JIRA)]

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

Failled closed LOG4J2-2388.
---

Works for me

Thanks for the quick merge !

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Commented] (LOG4J2-2377) NullPointerException in org.apache.logging.log4j.util.LoaderUtil.getClassLoaders() when using Bootstrap class loader

[Mirko Rzehak (JIRA)]

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

Mirko Rzehak commented on LOG4J2-2377:
--

Yep, that's it. No more exception with the latest 2.11.1 snapshot. Thanks again.

> NullPointerException in 
> org.apache.logging.log4j.util.LoaderUtil.getClassLoaders() when using 
> Bootstrap class loader
> 
>
> Key: LOG4J2-2377
> URL: https://issues.apache.org/jira/browse/LOG4J2-2377
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.9.1, 2.10.0, 2.11.0
>Reporter: Mirko Rzehak
>Priority: Blocker
> Fix For: 3.0.0, 2.11.1
>
>
> When log4j2 classes are loaded via the Bootstrap classloader, creating a 
> Logger ({{LogManager.getLogger()}}) causes a NullPointerException:
> {code:java}
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at Test.(Test.java:6)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.util.LoaderUtil.getClassLoaders(LoaderUtil.java:115)
>   at 
> org.apache.logging.log4j.util.ProviderUtil.(ProviderUtil.java:66)
>   at 
> org.apache.logging.log4j.util.ProviderUtil.lazyInit(ProviderUtil.java:146)
>   at 
> org.apache.logging.log4j.util.ProviderUtil.hasProviders(ProviderUtil.java:130)
>   at org.apache.logging.log4j.LogManager.(LogManager.java:89)
>   ... 1 more
> {code}
> To reproduce this behavior I put the log4j jar files (log4j-api and 
> log4j-core) into a dedicated directory and start my test program with 
> {{-Djava.endorsed.dirs=dirname}}. Classes from jars in that directory are 
> loaded using the Bootstrap classloader.
>  
> The issue came with 2.9.1. It worked with 2.9.0 and earlier versions.



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

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

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

[Apache Jenkins Server]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on H24 (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.GeneratedMethodAccessor125.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 
H24
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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2388:
-

Gary - Did you merge from github with "Closes #196"? This PR is still showing 
as being open with merge conflicts.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Commented] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2316:
-

The parent is null when the logger config is the root logger. As such, it is 
completely normal for it to be null. Of course, when the parent is null the 
name will be "".  If you don't allow a null value what would the root logger 
reference?

> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Comment Edited] (LOG4J2-2375) When KafkaAppender is used with other KafkaProducer, there is a problem.

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2375 at 7/21/18 4:42 PM:
---

May you please provide the stack trace?

PRs are welcome, with a unit tests of course ;) 


was (Author: garydgregory):
May you please provide the stack trace.

PRs are welcome, with a unit tests of course ;) 

> When KafkaAppender is used with other KafkaProducer, there is a problem.
> 
>
> Key: LOG4J2-2375
> URL: https://issues.apache.org/jira/browse/LOG4J2-2375
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.0
> Environment: scala 2.12.6 
> kafka 1.1.0 
> log4j2 2.11.0
>Reporter: zhangjk
>Priority: Critical
>
> hi:
> When i use the log4j2's KafkaAppender , I found a bug.  the property CONFIG 
> of the ProducerConfig is null.
> here's my code:
> log4j2.xml
> {code:java}
> 
> 
> 
> localhost:9092
> 
> 
> {code}
> the main class:
> {code:java}
> object KafkaTest extends App {
>   // this is scala code.
>   // create a KafkaProducer
>   val p = new Producer
> }
> {code}
> producer code:
> {code:java}
> class Producer {
>   val props = {
> val p = new Properties()
> 
> p
>   }
>   val producer = {
> val p = new KafkaProducer[Integer, String](props)
> p
>   }
> }
> {code}
> The reason for this BUG is that:  the `new Producer` is first initialized, 
> and the `ProducerConfig` has a static method block, and it called the 
> `CommonClientConfigs` class. in the `CommonClientConfigs` class,  it has a 
> static Log property, so, this will initialize the Log4j2's configuration, and 
> this will call a startup method of the Appender, it actually calls the 
> KafkaAppender's method. and then the method create a new `KafkaProducer`, 
> this will create a new `ProducerConfig` instance, but the static method block 
> is not completed, so the `CONFIG` is null.  this cause the 
> `NullPointerException`  
> my english is bad, so , hope to understand what i mean
>  



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

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

[jira] [Comment Edited] (LOG4J2-2375) When KafkaAppender is used with other KafkaProducer, there is a problem.

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2375 at 7/21/18 4:41 PM:
---

May you please provide the stack trace.

PRs are welcome, with a unit tests of course ;) 


was (Author: garydgregory):
PRs are welcome, with a unit tests of course ;) Also provide the stack trace.

> When KafkaAppender is used with other KafkaProducer, there is a problem.
> 
>
> Key: LOG4J2-2375
> URL: https://issues.apache.org/jira/browse/LOG4J2-2375
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.0
> Environment: scala 2.12.6 
> kafka 1.1.0 
> log4j2 2.11.0
>Reporter: zhangjk
>Priority: Critical
>
> hi:
> When i use the log4j2's KafkaAppender , I found a bug.  the property CONFIG 
> of the ProducerConfig is null.
> here's my code:
> log4j2.xml
> {code:java}
> 
> 
> 
> localhost:9092
> 
> 
> {code}
> the main class:
> {code:java}
> object KafkaTest extends App {
>   // this is scala code.
>   // create a KafkaProducer
>   val p = new Producer
> }
> {code}
> producer code:
> {code:java}
> class Producer {
>   val props = {
> val p = new Properties()
> 
> p
>   }
>   val producer = {
> val p = new KafkaProducer[Integer, String](props)
> p
>   }
> }
> {code}
> The reason for this BUG is that:  the `new Producer` is first initialized, 
> and the `ProducerConfig` has a static method block, and it called the 
> `CommonClientConfigs` class. in the `CommonClientConfigs` class,  it has a 
> static Log property, so, this will initialize the Log4j2's configuration, and 
> this will call a startup method of the Appender, it actually calls the 
> KafkaAppender's method. and then the method create a new `KafkaProducer`, 
> this will create a new `ProducerConfig` instance, but the static method block 
> is not completed, so the `CONFIG` is null.  this cause the 
> `NullPointerException`  
> my english is bad, so , hope to understand what i mean
>  



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

[jira] [Comment Edited] (LOG4J2-2375) When KafkaAppender is used with other KafkaProducer, there is a problem.

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2375 at 7/21/18 4:41 PM:
---

PRs are welcome, with a unit tests of course ;) Also provide the stack trace.


was (Author: garydgregory):
PRs are welcome, with a unit tests of course ;)

> When KafkaAppender is used with other KafkaProducer, there is a problem.
> 
>
> Key: LOG4J2-2375
> URL: https://issues.apache.org/jira/browse/LOG4J2-2375
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.0
> Environment: scala 2.12.6 
> kafka 1.1.0 
> log4j2 2.11.0
>Reporter: zhangjk
>Priority: Critical
>
> hi:
> When i use the log4j2's KafkaAppender , I found a bug.  the property CONFIG 
> of the ProducerConfig is null.
> here's my code:
> log4j2.xml
> {code:java}
> 
> 
> 
> localhost:9092
> 
> 
> {code}
> the main class:
> {code:java}
> object KafkaTest extends App {
>   // this is scala code.
>   // create a KafkaProducer
>   val p = new Producer
> }
> {code}
> producer code:
> {code:java}
> class Producer {
>   val props = {
> val p = new Properties()
> 
> p
>   }
>   val producer = {
> val p = new KafkaProducer[Integer, String](props)
> p
>   }
> }
> {code}
> The reason for this BUG is that:  the `new Producer` is first initialized, 
> and the `ProducerConfig` has a static method block, and it called the 
> `CommonClientConfigs` class. in the `CommonClientConfigs` class,  it has a 
> static Log property, so, this will initialize the Log4j2's configuration, and 
> this will call a startup method of the Appender, it actually calls the 
> KafkaAppender's method. and then the method create a new `KafkaProducer`, 
> this will create a new `ProducerConfig` instance, but the static method block 
> is not completed, so the `CONFIG` is null.  this cause the 
> `NullPointerException`  
> my english is bad, so , hope to understand what i mean
>  



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

[jira] [Commented] (LOG4J2-2375) When KafkaAppender is used with other KafkaProducer, there is a problem.

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-2375:
--

PRs are welcome, with a unit tests of course ;)

> When KafkaAppender is used with other KafkaProducer, there is a problem.
> 
>
> Key: LOG4J2-2375
> URL: https://issues.apache.org/jira/browse/LOG4J2-2375
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.0
> Environment: scala 2.12.6 
> kafka 1.1.0 
> log4j2 2.11.0
>Reporter: zhangjk
>Priority: Critical
>
> hi:
> When i use the log4j2's KafkaAppender , I found a bug.  the property CONFIG 
> of the ProducerConfig is null.
> here's my code:
> log4j2.xml
> {code:java}
> 
> 
> 
> localhost:9092
> 
> 
> {code}
> the main class:
> {code:java}
> object KafkaTest extends App {
>   // this is scala code.
>   // create a KafkaProducer
>   val p = new Producer
> }
> {code}
> producer code:
> {code:java}
> class Producer {
>   val props = {
> val p = new Properties()
> 
> p
>   }
>   val producer = {
> val p = new KafkaProducer[Integer, String](props)
> p
>   }
> }
> {code}
> The reason for this BUG is that:  the `new Producer` is first initialized, 
> and the `ProducerConfig` has a static method block, and it called the 
> `CommonClientConfigs` class. in the `CommonClientConfigs` class,  it has a 
> static Log property, so, this will initialize the Log4j2's configuration, and 
> this will call a startup method of the Appender, it actually calls the 
> KafkaAppender's method. and then the method create a new `KafkaProducer`, 
> this will create a new `ProducerConfig` instance, but the static method block 
> is not completed, so the `CONFIG` is null.  this cause the 
> `NullPointerException`  
> my english is bad, so , hope to understand what i mean
>  



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

[jira] [Comment Edited] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2316 at 7/21/18 3:45 PM:
---

Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null {{LoggerConfig}} parent.

This leads me to ask: What is the difference between a null {{LoggerConfig}} 
and a {{LoggerConfig}} for the root logger ({{""}})?

As an experiment I changed LoggerConfig setParent() in git {{release-2.x}} to:
{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}} and not help us 
here.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Final question then: Should LoggerConfig allow a null parent?

Thoughts?


was (Author: garydgregory):
Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null {{LoggerConfig}} parent.

This leads me to ask: What is the difference between a null {{LoggerConfig}} 
and a {{LoggerConfig}} for the root logger ({{""}})?

As an experiment I changed LoggerConfig setParent to:
{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}} and not help us 
here.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Final question then: Should LoggerConfig allow a null parent?

Thoughts?

> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Comment Edited] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2316 at 7/21/18 3:44 PM:
---

Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null {{LoggerConfig}} parent.

This leads me to ask: What is the difference between a null {{LoggerConfig}} 
and a {{LoggerConfig}} for the root logger ({{""}})?

As an experiment I changed LoggerConfig setParent to:
{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}} and not help us 
here.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Final question then: Should LoggerConfig allow a null parent?

Thoughts?


was (Author: garydgregory):
Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ({{""}})?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}} and not help us 
here.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Final question then: Should LoggerConfig allow a null parent?

Thoughts?


> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Comment Edited] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2316 at 7/21/18 3:44 PM:
---

Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ({{""}})?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}} and not help us 
here.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Final question then: Should LoggerConfig allow a null parent?

Thoughts?



was (Author: garydgregory):
Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}} and not help us 
here.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Final question then: Should LoggerConfig allow a null parent?

Thoughts?


> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Comment Edited] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2316 at 7/21/18 3:44 PM:
---

Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}} and not help us 
here.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Final question then: Should LoggerConfig allow a null parent?

Thoughts?



was (Author: garydgregory):
Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}}.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Thoughts?


> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Comment Edited] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2316 at 7/21/18 3:43 PM:
---

Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem, probably.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}}.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Thoughts?



was (Author: garydgregory):
Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}}.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Thoughts?


> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Comment Edited] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2316 at 7/21/18 3:43 PM:
---

Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} succeeds but that means that we don't 
have the kind of test that duplicates the above problem.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}}.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Thoughts?



was (Author: garydgregory):
Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} but that means that we don't have the 
kind of test that duplicates the above problem.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}}.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Thoughts?


> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

[jira] [Commented] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-2316:
--

Question to the community:

In the method 
{{org.apache.logging.log4j.core.config.LoggerConfig.logParent(LogEvent, 
LoggerConfigPredicate)}} we check for a null parent which seems to mean that we 
allow for a null LoggerConfig parent.

This leads me to ask: What is the difference between a null LoggerConfig and a 
LoggerConfig for the root logger ("")?

As an experiment I changed LoggerConfig setParent to:

{code:java}
public void setParent(final LoggerConfig parent) {
 this.parent = Objects.requireNonNull(parent, "parent");
}
{code}
A full build with {{mvn clean install}} but that means that we don't have the 
kind of test that duplicates the above problem.

We could alternatively add a null check in 
{{org.apache.logging.log4j.core.config.LoggerConfig.getLevel()}} but that would 
only pass the buck on the NPE to call sites of {{getLevel()}}.

My inclination is to update LoggerConfig to not allow setParent to accept null 
and see what happens for [~Ranjit.Dsouza]; we should see a new NPE from where 
the null parent comes from...

Thoughts?


> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Commented] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-2316:
--

I see you wrote:

{quote}
Configurator.setLevel(className, levelToSet);//line where exception is thrown 
when levelToSet is null
{quote}

May you paste the exception here please?

Gary

> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Issue Comment Deleted] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-2316:
-
Comment: was deleted

(was: I see you wrote:
{quote}Configurator.setLevel(className, levelToSet);//line where exception is 
thrown when levelToSet is null
{quote}
If this is a different exception than May you paste the exception here please?

Gary)

> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

[jira] [Comment Edited] (LOG4J2-2316) NullPointerException while calling Configurator.setLevel()

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2316 at 7/21/18 3:02 PM:
---

I see you wrote:
{quote}Configurator.setLevel(className, levelToSet);//line where exception is 
thrown when levelToSet is null
{quote}
If this is a different exception than May you paste the exception here please?

Gary


was (Author: garydgregory):
I see you wrote:

{quote}
Configurator.setLevel(className, levelToSet);//line where exception is thrown 
when levelToSet is null
{quote}

May you paste the exception here please?

Gary

> NullPointerException while calling Configurator.setLevel()
> --
>
> Key: LOG4J2-2316
> URL: https://issues.apache.org/jira/browse/LOG4J2-2316
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Web/Servlet
>Affects Versions: 2.11.0
> Environment: webapplication running in tomcat 8.5
>Reporter: Ranjit Dsouza
>Priority: Major
>
> Hi I want to report an intermittent issue in my webapplication wherein log4j 
> throws an NPE.
> Here is the stack trace:
> java.lang.NullPointerException
>     at 
> org.apache.logging.log4j.core.config.LoggerConfig.getLevel(LoggerConfig.java:268)
>     at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.(Logger.java:384)
>     at 
> org.apache.logging.log4j.core.Logger.updateConfiguration(Logger.java:365)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:652)
>     at 
> org.apache.logging.log4j.core.LoggerContext.updateLoggers(LoggerContext.java:641)
>     at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:296)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:346)
>     at 
> com.netbackup.logging.util.DebugLoggerFactory.getLogger(DebugLoggerFactory.java:359)
>     at 
> com.netbackup.logging.util.WebServiceLoggerFactory.getLogger(WebServiceLoggerFactory.java:14)
>     at 
> com.netbackup.common.logging.LoggerFactory.getLogger(LoggerFactory.java:34)
>  
> Log4j code where the NPE occurs: (LoggerConfig.java)
>     /**
>   * Returns the logging Level.
>   *
>   * @return the logging Level.
>   */
>      public Level getLevel()
> {     return level == null ? parent.getLevel() : level;     } //This is 
> the line where the NPE gets thrown
>  
> Inference is parent(LoggerConfig) itself was null. When can this situation 
> arise?



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

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

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on H24 (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.GeneratedMethodAccessor125.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 
H24
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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[ASF subversion and git services (JIRA)]

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

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

Commit a630a15d11fbed7e205e9ff59bac1cee62bb5a78 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=a630a15 ]

[LOG4J2-2388] Thread indefinitely blocked when logging a message in an
interrupted thread.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[ASF subversion and git services (JIRA)]

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

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

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

[LOG4J2-2388] Thread indefinitely blocked when logging a message in an
interrupted thread.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Resolved] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LOG4J2-2388.
--
   Resolution: Fixed
Fix Version/s: 2.11.1
   3.0.0

Thank you for your report and PR.

Patch applied to git {{master}} and {{release-2.x}} (without lambdas). 

Please verify and close this and the PR.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
> Fix For: 3.0.0, 2.11.1
>
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[ASF subversion and git services (JIRA)]

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

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

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

[LOG4J2-2388] Thread indefinitely blocked when logging a message in an
interrupted thread.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-2388:
--

Fixed typos in title and description.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Commented] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[ASF subversion and git services (JIRA)]

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

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

Commit 12959208f17c6ac570f97a645d32416696e0295e 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=1295920 ]

[LOG4J2-2388] Thread indefinitely blocked when logging a message in an
interrupted thread.

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Updated] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-2388:
-
Summary: Thread indefinitely blocked when logging a message in an 
interrupted thread  (was: Thread undefinitely blocked when logging a message in 
an interrupted thread)

> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Updated] (LOG4J2-2388) Thread indefinitely blocked when logging a message in an interrupted thread

[Gary Gregory (JIRA)]

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

Gary Gregory updated LOG4J2-2388:
-
Description: 
Logging a message to the Flume appender in an interrupted thread undefinitely 
block the thread.

The thread is blocked in an infinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 

This test case allows to reproduce the problem (add the code below in 
FlumePersistentAppenderTest in log4j-flume-ng module):
{code:java}
    @Test
    public void testLogInterrupted() {
        ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        executor.shutdownNow();
        final Logger logger = LogManager.getLogger("EventLogger");
    final Marker marker = MarkerManager.getMarker("EVENT");
    logger.info(marker, "This is a test message");
    Assert.assertTrue("Interruption status not preserved",
            Thread.currentThread().isInterrupted());
    });
    }
{code}
 

  was:
Logging a message to the Flume appender in an interrupted thread undefinitely 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 

This test case allows to reproduce the problem (add the code below in 
FlumePersistentAppenderTest in log4j-flume-ng module):
{code:java}
    @Test
    public void testLogInterrupted() {
        ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        executor.shutdownNow();
        final Logger logger = LogManager.getLogger("EventLogger");
    final Marker marker = MarkerManager.getMarker("EVENT");
    logger.info(marker, "This is a test message");
    Assert.assertTrue("Interruption status not preserved",
            Thread.currentThread().isInterrupted());
    });
    }
{code}
 


> Thread indefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an infinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Commented] (LOG4J2-2388) Thread undefinitely blocked when logging a message in an interrupted thread

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-2388:
--

Dev Note: If you only apply the test part of the patch, running Maven hangs 
with {{mvn clean test -pl log4j-flume-ng}}

> Thread undefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

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

[Apache Jenkins Server]

See 

--
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.GeneratedMethodAccessor106.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.$Proxy117.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$AbstractBuildExecution.run(AbstractBuild.java:499)
at 

[jira] [Updated] (LOG4J2-2388) Thread undefinitely blocked when logging a message in an interrupted thread

[Failled (JIRA)]

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

Failled updated LOG4J2-2388:

Description: 
Logging a message to the Flume appender in an interrupted thread undefinitely 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 

This test case allows to reproduce the problem (add the code below in 
FlumePersistentAppenderTest in log4j-flume-ng module):
{code:java}
    @Test
    public void testLogInterrupted() {
        ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        executor.shutdownNow();
        final Logger logger = LogManager.getLogger("EventLogger");
    final Marker marker = MarkerManager.getMarker("EVENT");
    logger.info(marker, "This is a test message");
    Assert.assertTrue("Interruption status not preserved",
            Thread.currentThread().isInterrupted());
    });
    }
{code}
 

  was:
Logging a message to the Flume appender in an interrupted thread undefinitely 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 

This test case allow to reproduce the problem (add the code below in 
FlumePersistentAppenderTest):
{code:java}
    @Test
    public void testLogInterrupted() {
        ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        executor.shutdownNow();
        final Logger logger = LogManager.getLogger("EventLogger");
    final Marker marker = MarkerManager.getMarker("EVENT");
    logger.info(marker, "This is a test message");
    Assert.assertTrue("Interruption status not preserved",
            Thread.currentThread().isInterrupted());
    });
    }
{code}
 


> Thread undefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allows to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest in log4j-flume-ng module):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Updated] (LOG4J2-2388) Thread undefinitely blocked when logging a message in an interrupted thread

[Failled (JIRA)]

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

Failled updated LOG4J2-2388:

Summary: Thread undefinitely blocked when logging a message in an 
interrupted thread  (was: Thread undefinetly blocked when logging a message in 
an interrupted thread)

> Thread undefinitely blocked when logging a message in an interrupted thread
> ---
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allow to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Updated] (LOG4J2-2388) Thread undefinetly blocked when logging a message in an interrupted thread

[Failled (JIRA)]

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

Failled updated LOG4J2-2388:

Description: 
Logging a message to the Flume appender in an interrupted thread undefinitely 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 

This test case allow to reproduce the problem (add the code below in 
FlumePersistentAppenderTest):
{code:java}
    @Test
    public void testLogInterrupted() {
        ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        executor.shutdownNow();
        final Logger logger = LogManager.getLogger("EventLogger");
    final Marker marker = MarkerManager.getMarker("EVENT");
    logger.info(marker, "This is a test message");
    Assert.assertTrue("Interruption status not preserved",
            Thread.currentThread().isInterrupted());
    });
    }
{code}
 

  was:
Logging a message to the Flume appender in an interrupted thread undefinetly 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 

This test case allow to reproduce the problem (add the code below in 
FlumePersistentAppenderTest):
{code:java}
    @Test
    public void testLogInterrupted() {
        ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        executor.shutdownNow();
        final Logger logger = LogManager.getLogger("EventLogger");
    final Marker marker = MarkerManager.getMarker("EVENT");
    logger.info(marker, "This is a test message");
    Assert.assertTrue("Interruption status not preserved",
            Thread.currentThread().isInterrupted());
    });
    }
{code}
 


> Thread undefinetly blocked when logging a message in an interrupted thread
> --
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinitely 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allow to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Updated] (LOG4J2-2388) Thread undefinetly blocked when logging a message in an interrupted thread

[Failled (JIRA)]

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

Failled updated LOG4J2-2388:

Description: 
Logging a message to the Flume appender in an interrupted thread undefinetly 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 

This test case allow to reproduce the problem (add the code below in 
FlumePersistentAppenderTest):
{code:java}
    @Test
    public void testLogInterrupted() {
        ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        executor.shutdownNow();
        final Logger logger = LogManager.getLogger("EventLogger");
    final Marker marker = MarkerManager.getMarker("EVENT");
    logger.info(marker, "This is a test message");
    Assert.assertTrue("Interruption status not preserved",
            Thread.currentThread().isInterrupted());
    });
    }
{code}
 

  was:
Logging a message to the Flume appender in an interrupted thread undefinetly 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) : 

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 


> Thread undefinetly blocked when logging a message in an interrupted thread
> --
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinetly 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) :
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  
> This test case allow to reproduce the problem (add the code below in 
> FlumePersistentAppenderTest):
> {code:java}
>     @Test
>     public void testLogInterrupted() {
>         ExecutorService executor = Executors.newSingleThreadExecutor();
>     executor.execute(() -> {
>         executor.shutdownNow();
>         final Logger logger = LogManager.getLogger("EventLogger");
>     final Marker marker = MarkerManager.getMarker("EVENT");
>     logger.info(marker, "This is a test message");
>     Assert.assertTrue("Interruption status not preserved",
>             Thread.currentThread().isInterrupted());
>     });
>     }
> {code}
>  



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

[jira] [Commented] (LOG4J2-2388) Thread undefinetly blocked when logging a message in an interrupted thread

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LOG4J2-2388:


GitHub user failled opened a pull request:

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

Fix LOG4J2-2388 / Blocking thread when logging message in an interrup…

…ted thread

- Fix unfinite loop in 
org.apache.logging.log4j.flume.appender.FlumePersistentManager.send when the 
thread is interrupted (Note : The loop has been completely removed since it 
does not seems to serve any purpose)
- Preserve Thread interruption status on InterruptedException
- Add unit test for this case

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

$ git pull https://github.com/failled/logging-log4j2 LOG4J2-2388

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

https://github.com/apache/logging-log4j2/pull/196.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 #196


commit c27a545e52cf68b5503801a50ec5efb13c460e3e
Author: failled <23032941+failled@...>
Date:   2018-07-21T09:26:57Z

Fix LOG4J2-2388 / Blocking thread when logging message in an interrupted 
thread




> Thread undefinetly blocked when logging a message in an interrupted thread
> --
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: Failled
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinetly 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) 
> : 
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  



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

[GitHub] logging-log4j2 pull request #196: Fix LOG4J2-2388 / Blocking thread when log...

[failled]

GitHub user failled opened a pull request:

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

Fix LOG4J2-2388 / Blocking thread when logging message in an interrup…

…ted thread

- Fix unfinite loop in 
org.apache.logging.log4j.flume.appender.FlumePersistentManager.send when the 
thread is interrupted (Note : The loop has been completely removed since it 
does not seems to serve any purpose)
- Preserve Thread interruption status on InterruptedException
- Add unit test for this case

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

$ git pull https://github.com/failled/logging-log4j2 LOG4J2-2388

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

https://github.com/apache/logging-log4j2/pull/196.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 #196


commit c27a545e52cf68b5503801a50ec5efb13c460e3e
Author: failled <23032941+failled@...>
Date:   2018-07-21T09:26:57Z

Fix LOG4J2-2388 / Blocking thread when logging message in an interrupted 
thread




---

[jira] [Updated] (LOG4J2-2388) Thread undefinetly blocked when logging a message in an interrupted thread

[David Faillefer (JIRA)]

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

David Faillefer updated LOG4J2-2388:

Summary: Thread undefinetly blocked when logging a message in an 
interrupted thread  (was: Thread undefinetly blocked when logging message in an 
interrupted thread)

> Thread undefinetly blocked when logging a message in an interrupted thread
> --
>
> Key: LOG4J2-2388
> URL: https://issues.apache.org/jira/browse/LOG4J2-2388
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Reporter: David Faillefer
>Priority: Critical
>
> Logging a message to the Flume appender in an interrupted thread undefinetly 
> block the thread.
> The thread is blocked in an unfinite loop here :
> org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) 
> : 
>  
> {code:java}
> boolean interrupted = false;
> int ieCount = 0;
> do {
>     try {
>     future.get();
>     } catch (final InterruptedException ie) {
>     interrupted = true;
>     ++ieCount;
>     }
> } while (interrupted && ieCount <= 1);
> {code}
>  



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

[jira] [Created] (LOG4J2-2388) Thread undefinetly blocked when logging message in an interrupted thread

[David Faillefer (JIRA)]

David Faillefer created LOG4J2-2388:
---

 Summary: Thread undefinetly blocked when logging message in an 
interrupted thread
 Key: LOG4J2-2388
 URL: https://issues.apache.org/jira/browse/LOG4J2-2388
 Project: Log4j 2
  Issue Type: Bug
  Components: Flume Appender
Reporter: David Faillefer


Logging a message to the Flume appender in an interrupted thread undefinetly 
block the thread.

The thread is blocked in an unfinite loop here :

org.apache.logging.log4j.flume.appender.FlumePersistentManager.*send*(Event) : 

 
{code:java}
boolean interrupted = false;
int ieCount = 0;
do {
    try {
    future.get();
    } catch (final InterruptedException ie) {
    interrupted = true;
    ++ieCount;
    }
} while (interrupted && ieCount <= 1);
{code}
 



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