May 2018 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1407) Document when groovy support with Java 9+ is expected
by QOS.CH (JIRA) 31 May '18

31 May '18

Troy Daniels created LOGBACK-1407: ------------------------------------- Summary: Document when groovy support with Java 9+ is expected Key: LOGBACK-1407 URL: https://jira.qos.ch/browse/LOGBACK-1407 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.3.0-alpha4 Environment: Java 9 Reporter: Troy Daniels Assignee: Logback dev list The current logbook does not support groovy configuration files. This is fairly well documented. It also appears that this is temporary. I am unable to find any indication of when groovy support is expected to be restored. If it is expected to be in a week or two, I will wait for that and not rewrite by config file in XML. If it is months or years, I will need to rewrite them. It is certainly possible that restoring support requires an update to groovy. In that case, clear documentation of what changes are needed in groovy, ideally with links to the corresponding issues in the groovy project, would be helpful. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1406) Seems all threads blocked
by QOS.CH (JIRA) 31 May '18

31 May '18

Tony Zeng created LOGBACK-1406: ---------------------------------- Summary: Seems all threads blocked Key: LOGBACK-1406 URL: https://jira.qos.ch/browse/LOGBACK-1406 Project: logback Issue Type: Bug Components: logback-core Environment: Linux ubuntu-100 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) Reporter: Tony Zeng Assignee: Logback dev list Attachments: dump We are using `logback-core-1.1.11` as our logging framework, and recently we found sometimes our web application is blocked and no response. After thread dump, we found that most of web threads (and many, around 150) are waiting for a lock in `OutputStreamAppender` as following stacktrace show: {code:java} "qtp956480812-17384" #17384 prio=5 os_prio=0 tid=0x00007f667400e800 nid=0x43f3 waiting on condition [0x00007f652d4d0000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000843211e8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:210) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:414) at ch.qos.logback.classic.Logger.info(Logger.java:587) at cn.superid.auth.utils.PermissionUtil.hasPermission(PermissionUtil.java:31) {code} And following is the only thread which has the lock {code:java} "qtp956480812-17230" #17230 prio=5 os_prio=0 tid=0x00007f65c0017800 nid=0x4359 runnable [0x00007f65e5fe9000] java.lang.Thread.State: RUNNABLE at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) - locked <0x00000000830542d0> (a java.io.BufferedOutputStream) at java.io.PrintStream.write(PrintStream.java:480) - locked <0x00000000830542b0> (a java.io.PrintStream) at java.io.FilterOutputStream.write(FilterOutputStream.java:97) at ch.qos.logback.core.joran.spi.ConsoleTarget$1.write(ConsoleTarget.java:37) at ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:131) at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:187) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:414) at ch.qos.logback.classic.Logger.info(Logger.java:587) {code} >From the stacktrace, it seems no deadlock and application should not be blocked. But the actual phenomenon is no log, no response. So, what's the problem? If you need more info, let me know. Thanks. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 Early Access build 15 is available for download.
by Rory O'Donnell 29 May '18

29 May '18

Hi Ceki, **JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o http://jdk.java.net/11/changes *Notable changes in JDK 11 EA builds since last email:* * b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627> - Kerberos sequence number issues * b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146> - Removal of appletviewer launcher o deprecated in JDK 9 and has been removed in this release * b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793> - java.lang.ref.Reference does not support cloning ** ** JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC) 330: Launch Single-File Source-Code Programs <http://openjdk.java.net/jeps/330> JEPs targeted to JDK 11, so far 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309> 318: Epsilon: A No-Op Garbage Collector <http://openjdk.java.net/jeps/318> 320: Remove the Java EE and CORBA Modules <http://openjdk.java.net/jeps/320> 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321> 323: Local-Variable Syntax for Lambda Parameters <http://openjdk.java.net/jeps/323> 324: Key Agreement with Curve25519 and Curve448 <http://openjdk.java.net/jeps/324> 327: Unicode 10 <http://openjdk.java.net/jeps/327> 328: Flight Recorder <http://openjdk.java.net/jeps/328> 329: ChaCha20 and Poly1305 Cryptographic Algorithms <http://openjdk.java.net/jeps/329> Finally, Initial TLSv1.3 implementation Released to the Open Sandbox. Please note well: this branch is under very active development and is not final by any means. Also note: by releasing this code, we are not committing a specific release or timeframe. We will continue development and fixing bugs until the code is ready for inclusion in the JDK. We welcome your feedback, more info [1] Regards, Rory [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

[JIRA] (LOGBACK-1405) Ability to truncate existing files in SizeAndTimeBasedRollingPolicy
by QOS.CH (JIRA) 29 May '18

29 May '18

Gili created LOGBACK-1405: ----------------------------- Summary: Ability to truncate existing files in SizeAndTimeBasedRollingPolicy Key: LOGBACK-1405 URL: https://jira.qos.ch/browse/LOGBACK-1405 Project: logback Issue Type: Improvement Components: logback-core Reporter: Gili Assignee: Logback dev list Priority: Minor When debugging my software I want to flush log files on every run. Consider adding an "append" option to {{SizeAndTimeBasedRollingPolicy}} with the same meaning as "append" found in {{FileAppender.}} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1396) JVM fatal error with libzip.so
by QOS.CH (JIRA) 29 May '18

29 May '18

1 0

[JIRA] (LOGBACK-1404) SizeAndTimeBasedRollingPolicy discards log data
by QOS.CH (JIRA) 25 May '18

25 May '18

Anton Wiedermann created LOGBACK-1404: ----------------------------------------- Summary: SizeAndTimeBasedRollingPolicy discards log data Key: LOGBACK-1404 URL: https://jira.qos.ch/browse/LOGBACK-1404 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: Windows 10 64bit org.slf4j:slf4j-api:1.7.25 ch.qos.logback:logback-classic:1.2.3 Reporter: Anton Wiedermann Assignee: Logback dev list Attachments: logback.xml, Rotfail.java RollingFileAppender when used with SizeAndTimeBasedRollingPolicy disards during log rotation first file that should have been archived. This happens only if file rotates by time before first rotating by date Attached is app that simply does some info and debug logging and logback config file that logs everything to one file and info to other. Logs rotate at 100kB or after a minute. fast log keeps exceeding file size limit so it is archived properly. slow log does not exceed the file size limit and when minute changes it simply gets deleted and starts fresh. With next minute change it is properly archived though. Since log rotation is usually set for a day this can mean loss of day worth of logging. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1403) Security Vulnerabilities in logback
by QOS.CH (JIRA) 23 May '18

23 May '18

Olga Barinova created LOGBACK-1403: -------------------------------------- Summary: Security Vulnerabilities in logback Key: LOGBACK-1403 URL: https://jira.qos.ch/browse/LOGBACK-1403 Project: logback Issue Type: Bug Components: logback-classic, logback-core Reporter: Olga Barinova Assignee: Logback dev list Priority: Critical I would like to report the details of two critical vulnerabilities in logback. Could you please provide the contact, which is responsible for that, to disclose it properly? Regards, Olga lb.synack(a)gmail.com -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1402) SocketAppender not detecting dirty TCP disconnect. Log events go missing.
by QOS.CH (JIRA) 23 May '18

23 May '18

Charles Loots created LOGBACK-1402: -------------------------------------- Summary: SocketAppender not detecting dirty TCP disconnect. Log events go missing. Key: LOGBACK-1402 URL: https://jira.qos.ch/browse/LOGBACK-1402 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: I have set up several processes instances, each using logback. The instances are meant to be containerized in docker and scale out. The instances (senders) use SocketAppender to centralize log events to a different container, where a process (receiver) runs with logback with a ServerSocketReceiver. At this single instance i am able to further deal with the log events in a central place. The setup works perfectly with one exception. When the receiver container is shut down, the senders are not aware of the disconnect and take about 10 minutes to become aware of the problem with the socket, despite nearly constant logging taking place. Only at this point to they reconnect. Reporter: Charles Loots Assignee: Logback dev list It would appear that a remote container shutdown results in a dirty TCP disconnect. The remote TCP server disappears abruptly, leaving the client side with the socket in CLOSE_WAIT state. While this is the case the client side is happily appending events to the SocketAppender which in turn seems to be writing this to the socket (the Send-Q on the socket keeps growing) without detecting any errors. This keeps going for several minutes (between 7 and 12 in my tests) during which log events go missing. Only at this very late point is an error raised and the reconnect logic triggered. I found that the *AbstractLogstashTcpSocketAppender* from the logstash project encountered and fixed this same problem. [https://github.com/logstash/logstash-logback-encoder/issues/76] [https://github.com/logstash/logstash-logback-encoder/issues/85] They effectively fixed the problem by attempting a read from the socket (with short read timeout) which results in a much more timely detection of the disconnect . This could take place on a separate watchdog thread to detect the problem. [https://github.com/logstash/logstash-logback-encoder/blob/master/src/main/j…] The call() method tries to constantly read from the socket. The expected outcome is that -1 bytes were read within the read timeout period, and this is where an exception will be much more reliably triggered when the socket is no longer available. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1401) Logback creating .tmp file
by QOS.CH (JIRA) 22 May '18

22 May '18

Mahtab Alam created LOGBACK-1401: ------------------------------------ Summary: Logback creating .tmp file Key: LOGBACK-1401 URL: https://jira.qos.ch/browse/LOGBACK-1401 Project: logback Issue Type: Bug Environment: Below is the logback.xml , which is generating weird log files e.g. im.log2323744883452020.tmp. I was expecting to write im-2018-05-23-0.log.zip , im-2018-05-23-1.log.zip, im-2018-05-23-2.log.zip logback version is 1.1.0 I have read many other issues where logback is generating .tmp files, but none of them matched my problem. Can you help me with that? {code:java} <?xml version="1.0" encoding="UTF-8"?> <configuration scan="true" scanPeriod="60 seconds">  <property name="LOG_PATH" value="${catalina.base}/logs/" />  <property name="LOG_PATTERN" value="%d [%X{username}] [%level] [%logger{0}:%line] - %msg%n" /> <property name="LOG_MAX_HISTORY" value="1" />  <property name="LOG_MAX_FILE_SIZE" value="500KB" /> <property name="LOG_FILE" value="${LOG_PATH}/im.log" /> <property name="LOG_FILE_ARCHIVE" value="${LOG_PATH}/im-%d{yyyy-MM-dd}-%i.log.zip" /> <property name="LOG_SLOW_METHOD_PATTERN" value="${LOG_PATTERN}" /> <property name="LOG_SLOW_METHOD_MAX_HISTORY" value="${LOG_MAX_HISTORY}" />  <property name="LOG_SLOW_METHOD_MAX_FILE_SIZE" value="${LOG_MAX_FILE_SIZE}" /> <property name="LOG_SLOW_METHOD_FILE" value="${LOG_PATH}/im-slow-methods.log" /> <property name="LOG_SLOW_METHOD_FILE_ARCHIVE" value="${LOG_PATH}/im-slow-methods.%d{yyyy-MM-dd}-%i.log.zip" />  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <charset>utf-8</charset> <pattern>${LOG_PATTERN}</pattern> </encoder> </appender>  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${LOG_FILE}</File> <encoder> <charset>utf-8</charset> <pattern>${LOG_PATTERN}</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_FILE_ARCHIVE}</fileNamePattern> <maxHistory>${LOG_MAX_HISTORY}</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>${LOG_MAX_FILE_SIZE}</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> </appender> <appender name="SLOW_METHOD" class="ch.qos.logback.core.FileAppender"> <File>${LOG_SLOW_METHOD_FILE}</File> <encoder> <charset>utf-8</charset> <pattern>${LOG_SLOW_METHOD_PATTERN}</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_SLOW_METHOD_FILE_ARCHIVE}</fileNamePattern> <maxHistory>${LOG_SLOW_METHOD_MAX_HISTORY}</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>${LOG_SLOW_METHOD_MAX_FILE_SIZE}</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> </appender> <appender name="MM_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.base}/logs/dhap-metrics-manager.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>${catalina.base}/logs/dhap-metrics-manager_%d{yyyy-MM-dd}.%i.log </fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">  <maxFileSize>10MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy>  <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <charset>utf-8</charset> <pattern>%msg%n</pattern> </encoder> </appender>    <root level="INFO"> <appender-ref ref="FILE" /> </root>   <logger name="com.lifetech.ga.app" level="INFO"> </logger> <logger name="metricsManagerLogger" level="INFO"> <appender-ref ref="MM_FILE" /> </logger>  <logger name="com.lifetech.apps.security" level="WARN"> </logger> <logger name="com.lifetech.ga.core.aspect.MethodProfiler" level="INFO" additivity="false"> <appender-ref ref="CONSOLE" /> <appender-ref ref="SLOW_METHOD" /> </logger> </configuration> {code} Reporter: Mahtab Alam Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1348) SizeAndTimeBasedRollingPolicy on Windows sometimes exceeds maxFileSize and file counter explodes
by QOS.CH (JIRA) 18 May '18

18 May '18

1 0