[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15476303#comment-15476303
]
Steffen Offermann edited comment on LOG4J2-1259 at 9/9/16 8:48 AM:
-------------------------------------------------------------------
The field "layout" seems to be required for
{code:xml}
<Console name="myConsole" target="SYSTEM_OUT" />
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
According to the current documentation this is a bug:
||Parameter Name||Type|| Description||
| layout | Layout | The Layout to use to format the LogEvent. If no layout is
supplied the default pattern layout of "%m%n" will be used.
With this configuration it works:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" packages="com.aixigo.tec.logging">
<Appenders>
<Console name="myConsole" target="SYSTEM_OUT">
<DetailsLayout/>
</Console>
<Async name="myConsoleAsync">
<AppenderRef ref="myConsole" />
</Async>
</Appenders>
<Loggers>
<AsyncRoot level="info" />
</Loggers>
</Configuration>
{code}
I'll report this as a new issue.
was (Author: steffeno):
The field "layout" seems to be required for
{code:xml}
<Console name="myConsole" target="SYSTEM_OUT" />
{code}
now, and that causes the error. Unfortunately the error log is useless as it
does not name the cause. I could only find this using the debugger.
According to the current documentation this is a bug:
||Parameter Name||Type|| Description||
| layout | Layout | The Layout to use to format the LogEvent. If no layout is
supplied the default pattern layout of "%m%n" will be used.
With this configuration it works:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" packages="com.aixigo.tec.logging">
<Appenders>
<Console name="myConsole" target="SYSTEM_OUT">
<DetailsLayout/>
</Console>
<Async name="myConsoleAsync">
<AppenderRef ref="myConsole" />
</Async>
</Appenders>
<Loggers>
<AsyncRoot level="info" />
</Loggers>
</Configuration>
{xml}
I'll report this as a new issue.
> Log4j threads are leaking on tomcat shutdown
> --------------------------------------------
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.5
> Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
