- logback-dev - mailman3.qos.ch

[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

[JIRA] (LOGBACK-1400) Let ResilientOutputStreamBase.openNewOutputStream() be override from outside the package
by QOS.CH (JIRA) 18 May '18

18 May '18

Peter Storch created LOGBACK-1400: ------------------------------------- Summary: Let ResilientOutputStreamBase.openNewOutputStream() be override from outside the package Key: LOGBACK-1400 URL: https://jira.qos.ch/browse/LOGBACK-1400 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.3.0-alpha4 Reporter: Peter Storch Assignee: Logback dev list Priority: Minor Let ResilientOutputStreamBase.openNewOutputStream() be override from outside the package. This method is currently package protected which means only subclasses in the same package can override this method. When other frameworks like Dropwizard want to provide their own implementation of a ResilientOutputStream they have to put their class in the ch.qos.logback.core.recovery package. Which causes a split package problem when using Java 9 modules: [https://github.com/dropwizard/dropwizard/issues/2312] If this method is meant to be overridden from outside logback-core, a "protected" modifier should be added. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Regarding logback help
by Md. Hasan Basri 17 May '18

17 May '18

Dear Concern, I'm a developer. One of my application is based on Jdk8, groovy 2.4 as language and on the top of Spring Framework. As a logger I'm using 'logback' dependencies. (*group: 'ch.qos.logback', name: 'logback-classic', version: '1.1.8'*). Basically, RollingFileAppender is working fine for me, But currently. For an example, Suppose the specific logger function is invoked at *2018-05-16 11:08:50*, A record entered into error.log and no rolling file is created. Well, when the next execution occurs approximately after 6 minutes at *2018-05-16 11:15:05*, A fresh file is created *error.2018-05-16-11-08.log* and *error.log* file is refreshed with only the new message. This behavior is as per the documentation. But currently, I'm in need of instant creation of log file as soon as the rolling complete. In that case, the new file *error.2018-05-16-11-08.log* which is created actually at *2018-05-16 11:15:05*, I need to create the same file actually at *2018-05-16 11:09:00* (means as soon as the minute based rolling is complete). <appender name="ERROR_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/error.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs/error_log/error.%d{yyyy-MM-dd-HH-mm}.log </fileNamePattern> <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS}\t%msg%n</pattern> </encoder> </appender> Through my investigation, The purpose is partially resolved by removing the below property. <file>logs/error.log</file> But, I also need to produce "/logs/error.log" file. So, is there any way to satisfy my first criteria without impacting error.log file. Please, feel free to ask me anything regarding this issue. Best Regards, Md. Hasan Basri

1 0

[JIRA] (LOGBACK-1399) Percentage char in fileNamePattern in FixedWindowRollingPolicy
by QOS.CH (JIRA) 11 May '18

11 May '18

Vitaliy created LOGBACK-1399: -------------------------------- Summary: Percentage char in fileNamePattern in FixedWindowRollingPolicy Key: LOGBACK-1399 URL: https://jira.qos.ch/browse/LOGBACK-1399 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.1 Reporter: Vitaliy Assignee: Logback dev list I could not use fileNamePattern with the percentage charge in directory name. Example: {code:java} <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <maxIndex>2</maxIndex> <FileNamePattern>dev%fzp/file.log.%i</FileNamePattern> </rollingPolicy> {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 Early Access build 12 available
by Rory O'Donnell 08 May '18

08 May '18

Hi Ceki, **JDK 11 EA build 12 , *****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 https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html *Notable changes in JDK 11 EA builds since last email:* * Build 11 - see Release Notes for details. o JDK-8201315 : SelectableChannel.register may be invoked while a selection operation is in progress * Build 10 - see Release Notes for details. o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class o JDK-8189997 (not public) : Enhanced KeyStore Mechanisms o JDK-8175075 (not public) : 3DES Cipher Suites Disabled * Build 9: - see Release Notes for details. o JDK-8200152 : KerberosString uses UTF-8 encoding by default o JDK-8200458 : Readiness information previously recorded in SelectionKey ready set not preserved ** *Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1] * This draft JEP [2] proposes to deprecate the pack200 APIs and tools in the JDK. As outlined in the JEP, the usefulness of this technology have diminishing returns, the components using them are being removed and connectivity speeds have improved by leaps and bounds, since its inception. Feedback appreciated via http://mail.openjdk.java.net/pipermail/jdk-dev Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html [2] https://bugs.openjdk.java.net/browse/JDK-8200752 Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0