We use AsyncAppenders in our WebSphere AppServer 8.5 ND environment.

When an application starts, that uses logback, threads are created with name AsyncAppender-Worker-Thread-XXX for every defined async appender, as they should.

But we noticed, that when the application is stopped, these threads do not dissapear. And when the application is started again, the previously created threads all stay there, and new ones are created, and old threads never die. With a couple of application restarts, it's easy to get to houndreds of running worker threads, in the end, exhausting the native heap and killing the server.

Originally we used logback 1.0.7, now we tried it with 1.0.13, but it's the same.

Websphere Application Server 8.5.0.1 Network Deployment

this causes logging inside applets to fail with the following exception:

Unexpected exception
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun.reflect")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPackageAccess(Unknown Source)
at sun.plugin2.applet.SecurityManagerHelper.checkPackageAccessHelper(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPackageAccess(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at ch.qos.logback.classic.spi.PackagingDataCalculator.<clinit>(PackagingDataCalculator.java:42)
at ch.qos.logback.classic.spi.ThrowableProxy.getPackagingDataCalculator(ThrowableProxy.java:135)
...

using sun* classes may also cause problems when using a different VM!?

SMTPAppender places a great deal of the stack trace into the subject line. If the line contains a newline, and further data, Amazon interprets this data as email headers and rejects the email because it contains illegal headers.

Suggested fix is to truncate the email subject line at the first EOL character. See http://mailman.qos.ch/pipermail/logback-user/2013-May/003929.html

I'm hitting the following OverlappingFileLockException in LogBack.
Is there any know issues with prudent mode in this version of Logback.

logback-classic 1.0.7
logback-core 1.0.7
slf4j-api 1.7.2
slf4j-ext 1.7.2

11:16:59,252 |-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[FILE_LOG] - Appender [FILE_LOG] failed to append. java.nio.channels.OverlappingFileLockException at java.nio.channels.OverlappingFileLockException at at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) at at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152) at at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:972) at at java.nio.channels.FileChannel.lock(FileChannel.java:1052) at at ch.qos.logback.core.FileAppender.safeWrite(FileAppender.java:187) at at ch.qos.logback.core.FileAppender.writeOut(FileAppender.java:204) at at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) at at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:148) at at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103) at at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88) at at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) at at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:280) at at ch.qos.logback.classic.Logger.callAppenders(Logger.java:267) at at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:449) at at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:403) at at ch.qos.logback.classic.Logger.log(Logger.java:803) at at org.slf4j.ext.LoggerWrapper.info(LoggerWrapper.java:490)

<appender name="FILE_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
<prudent>true</prudent>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>C:/MyLog-%d

.%i.log</fileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>100MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
<maxHistory>10</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%d

[%-20.20(%thread)] %-6level %-30.30logger

- [%-12.12(S:%mdc

]) %msg%n</pattern>
</encoder>
</appender>

Windows 7 Enterprise 64-bit

java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

I try to use logback in a portlet app with the Liferay portal, whose new version (6.2.0) let administrators set up the java security management dynamically.

When the portlet app starts up (in the Liferay environment), the property "java.security.policy" is always null, and System.getSecurityManager() returns the current manager (null if no set, not null if set).

Logback always breaks in PackagingDataCalculator.getCodeLocation(Class) and PackagingDataCalculator.populateFrameStack(StackTraceElementProxy[]) because it calls Class<T>.getProtectionDomain() and Class<T>.getClassLoader().

java 6 / MacOSX 10.7