June 2019 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1472) RollingFileAppender unable to keep appending to current file when rollover failed
by QOS.CH (JIRA) 29 Jun '19

29 Jun '19

Bertrand Renuart created LOGBACK-1472: ----------------------------------------- Summary: RollingFileAppender unable to keep appending to current file when rollover failed Key: LOGBACK-1472 URL: https://jira.qos.ch/browse/LOGBACK-1472 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Reporter: Bertrand Renuart Assignee: Logback dev list It may happen the {{RollingFileAppender}} becomes unable to keep appending events into the current file when {{rollover()}} failed. The {{RollingFileAppender#rollover()}} method looks as follows: {code:java} public void rollover() { lock.lock(); try { this.closeOutputStream(); attemptRollover(); attemptOpenFile(); } finally { lock.unlock(); } }{code} The method starts by closing the current output stream which sets the {{outputStream}} protected field to {{null}} until the file is reopened again. It then tries to rotate and reopen the file before exiting. However, if one of these two methods throw an unexpected exception, the {{outputStream}} field is left to {{null}}. This field is also left to {{null}} if the {{attemptOpenFile()}} method fails to reopen the new current file as returned by the rolling policy. This can happen if, for instance, the file system is not available (remote fs?), or if the policy returns a file located somewhere we don't have enough permissions, etc... The next time an event is received, the {{writeBytes}} method will throw a {{NullPointerException}}. *Unfortunately, this case is not expected and there is nothing to attempt to recover from it. The appender now starts dropping all events until the triggeringPolicy asks for a new rollover.* Comments in the {{attemptRollover}} method say that in case of exception, it should keep the same file but in append mode since it is safer to keep appending in an _outdated_ file instead of dropping events. Unfortunately, as mentioned above, the file output stream as been closed already, and an attempt is made to reopen it under the _new_ filename instead. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1471) ResilientFileOutputStream looses buffer size setting when reopened
by QOS.CH (JIRA) 28 Jun '19

28 Jun '19

Bertrand Renuart created LOGBACK-1471: ----------------------------------------- Summary: ResilientFileOutputStream looses buffer size setting when reopened Key: LOGBACK-1471 URL: https://jira.qos.ch/browse/LOGBACK-1471 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Reporter: Bertrand Renuart Assignee: Logback dev list Method {{ResilientFileOutputStream#openNewOutputStream()}} does not take {{bufferSize}} into account when creating a new buffered output stream. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1470) Logback scan not work when springProperty changes
by QOS.CH (JIRA) 27 Jun '19

27 Jun '19

elliot created LOGBACK-1470: ------------------------------- Summary: Logback scan not work when springProperty changes Key: LOGBACK-1470 URL: https://jira.qos.ch/browse/LOGBACK-1470 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.1.11 Environment: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> <version>1.5.9.RELEASE</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.2.3</version> </dependency> Reporter: elliot Assignee: Logback dev list Priority: Minor Scan not working and did not reload logback-spring.xml when the value of springProperty in cofig files changes in runtime. It seems like the scan function only compare the last modified timestamp. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1279) Async appenders do not scale well across multiple threads
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

1 0

JDK 13 enters Rampdown Phase One
by Rory O'Donnell 16 Jun '19

16 Jun '19

Hi Ceki, *JDK 13 Early Access build **25 is now available **at : - jdk.java.net/13/* * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. * Changes in this build 25 [4] *Request for feedback on JEP 353 integrated in b24 * JEP 353: Reimplement the Legacy Socket API" has been integrated into jdk-13+24. It would be very useful if applications or libraries using java.net.Socket or java.net.ServerSocket APIs could test with this build and report any issues found. The JEP provides information on the system property that can be used to switch back to the old implementation and that may be useful to check for behavior differences between the old and new implementation. It would be very useful to get feedback via the OpenJDK net-dev mailing list, bugs via the usual channel. *Updates to Release Notes since last email* * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032 <https://bugs.openjdk.java.net/browse/JDK-8215032>) * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 <https://bugs.openjdk.java.net/browse/JDK-8222145>) * b24 - Reimplement the Legacy Socket API(JDK-8221481 <https://bugs.openjdk.java.net/browse/JDK-8221481>) o see above request for feedback * b24 - Deprecated rmic tool For Removal(JDK-8217412 <https://bugs.openjdk.java.net/browse/JDK-8217412>) * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 <https://bugs.openjdk.java.net/browse/JDK-8224767>) * b23 - Support for Unicode 12.1 (JDK-8221431 <https://bugs.openjdk.java.net/browse/JDK-8221431>) * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 <https://bugs.openjdk.java.net/browse/JDK-8221432>) *OpenJDK 14 **Early Access build 1 **is now available **at : - jdk.java.net/14/* * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build [5] ** Rgds, Rory [1] http://openjdk.java.net/projects/jdk/13/#Schedule <http://openjdk.java.net/projects/jdk/12/#Schedule> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html [3] http://jdk.java.net/13/release-notes [4] JDK 13 - Changes in b25 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3…> [5] JDK 14 - Changes in b1 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A…> -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

[JIRA] (LOGBACK-1424) high contention at ch.qos.logback.core.AsyncAppenderBase.putUninterruptibly
by QOS.CH (JIRA) 14 Jun '19

14 Jun '19

1 0

[JIRA] (LOGBACK-1469) AsycAppender defined in configuration but not used in any logger is not stopping by shutdown hook
by QOS.CH (JIRA) 14 Jun '19

14 Jun '19

Alexandr Bolbat created LOGBACK-1469: ---------------------------------------- Summary: AsycAppender defined in configuration but not used in any logger is not stopping by shutdown hook Key: LOGBACK-1469 URL: https://jira.qos.ch/browse/LOGBACK-1469 Project: logback Issue Type: Improvement Components: logback-classic, logback-core Affects Versions: 1.2.3 Environment: Any environment Reporter: Alexandr Bolbat Assignee: Logback dev list Priority: Critical If we define 3 async appenders: {code:java} <appender name="ConsoleInfoAppenderAsync" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>5000</queueSize> <discardingThreshold>0</discardingThreshold> <appender-ref ref="ConsoleInfoAppender" /> <includeCallerData>true</includeCallerData> </appender> <appender name="ConsoleDebugAppenderAsync" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>5000</queueSize> <discardingThreshold>0</discardingThreshold> <appender-ref ref="ConsoleDebugAppender" /> <includeCallerData>true</includeCallerData> </appender> <appender name="ConsoleTraceAppenderAsync" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>5000</queueSize> <discardingThreshold>0</discardingThreshold> <appender-ref ref="ConsoleTraceAppender" /> <includeCallerData>true</includeCallerData> </appender> ...{code} Then define loggers: {code:java} <logger name="some.package" level="DEBUG" additivity="true"> <appender-ref ref="ConsoleDebugAppenderAsync" /> <appender-ref ref="ConsoleInfoAppenderAsync" /> </logger> <root level="INFO"> <appender-ref ref="ConsoleInfoAppenderAsync" /> </root> {code} And shutdown hook: {code:java} <shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook" /> {code} On application shutdown we will have executed stop for 2 appenders: {code:java} ConsoleDebugAppenderAsync ConsoleInfoAppenderAsync {code} And related threads would be stopped. But shutdown for third appender will be ignored (or just not executed): {code:java} ConsoleTraceAppenderAsync {code} In result their thread will exist and still working: {code:java} AsyncAppender-Worker-ConsoleTraceAppenderAsync {code} In case of web application deployed to tomcat we will see warning about this: {code:java} 14-Jun-2019 18:03:43.568 WARNING [Thread-19] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [AsyncAppender-Worker-ConsoleTraceAppenderAsync] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11/jdk.internal.misc.Unsafe.park(Native Method) java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) java.base@11/java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:417) ch.qos.logback.core.AsyncAppenderBase$Worker.run(AsyncAppenderBase.java:289) {code} Would be nice to improve graceful shutdown process for this case. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1027) Circular Referenced Suppressed Exception Throws StackOverflowError
by QOS.CH (JIRA) 13 Jun '19

13 Jun '19

1 0

[JIRA] (LOGBACK-1454) StackOverflow error
by QOS.CH (JIRA) 13 Jun '19

13 Jun '19

1 0

[JIRA] (LOGBACK-1454) StackOverflow error
by QOS.CH (JIRA) 13 Jun '19

13 Jun '19

1 0