July 2023 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1754) OverlappingFileLockException when using prudent mode
by logback developers list 07 Jul '23

07 Jul '23

1 0

[JIRA] (LOGBACK-1754) OverlappingFileLockException when using prudent mode
by logback developers list 07 Jul '23

07 Jul '23

1 0

[JIRA] (LOGBACK-1756) Change LoggerContext to use MDCAdapter instead of LogbackMDCAdapter
by logback developers list 07 Jul '23

07 Jul '23

1 0

[JIRA] Updates for LOGBACK-1756: Change LoggerContext to use MDCAdapter instead of LogbackMDCAdapter
by logback developers list 07 Jul '23

07 Jul '23

logback / LOGBACK-1756 [Open] Change LoggerContext to use MDCAdapter instead of LogbackMDCAdapter ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1756 ============================== Issue created ------------------------------ Jim Talbut created this issue on 07/Jul/23 16:42 Summary: Change LoggerContext to use MDCAdapter instead of LogbackMDCAdapter Issue Type: Improvement Affects Versions: 1.4.8 Assignee: Logback dev list Components: logback-core Created: 07/Jul/23 16:42 Environment: Currently LoggerContext uses LogbackMDCAdapter. There doesn't seem to be much need for it to do that rather than just using the MDCAdapter interface. Using LogbackMDCAdapter ties it to the implementation and makes it difficult to replace, whereas using the interface would make it easy to replace. As a Vertx user the thread-local storage of MDCAdapter isn't a useful implementation for me, so I'd like to be able to replace it. Priority: Minor Reporter: Jim Talbut ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for LOGBACK-1755: potential resource leak bug in test code
by logback developers list 07 Jul '23

07 Jul '23

logback / LOGBACK-1755 [Open] potential resource leak bug in test code ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1755 ============================== Issue created ------------------------------ Alfusainey Jallow created this issue on 07/Jul/23 12:55 Summary: potential resource leak bug in test code Issue Type: Bug Assignee: Logback dev list Components: logback-core Created: 07/Jul/23 12:55 Priority: Minor Reporter: Alfusainey Jallow Description: There is a potential resource leak bug in the implementation of the CompressTest{{{}#copy(){}}} method. This method copies the contents of one file to another. However, the input and output streams will not be closed if an exception is thrown during the {{write}} operation. One solution is to use try-with-resources so that it is guaranteed that the streams will be close in the event an exception is thrown. {code:java} public static void copy(File src, File dst) throws IOException { try (InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(dst)) { // Transfer bytes from in to out byte[] buf = new byte[1024]; int len; while ((len = in.read(buf)) > 0) { out.write(buf, 0, len); } } } {code} The priority for this issue is minor since it affects only test code. Can someone kindly confirm if this is an issue? *Context* We came across this issue while investigating open-source projects to see if they contain code that is similar to (or reused from) Stack Overflow and whether the code on Stack Overflow underwent any bug or security fixes. We found that the code in the {{{}CompressTest{}}}{{{}{}}}{{{}#copy(){}}} method is somewhat similar to the one in the first version of [this answer|https://stackoverflow.com/revisions/9293885/1] The issue was subsequently fixed in the [second version|https://stackoverflow.com/revisions/9293885/2] however, the fix is not reflected in this method. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1754) OverlappingFileLockException when using prudent mode
by logback developers list 07 Jul '23

07 Jul '23

1 0

[JIRA] (LOGBACK-1754) OverlappingFileLockException when using prudent mode
by logback developers list 07 Jul '23

07 Jul '23

1 0

Re: [logback-dev] regarding LOGBACK-1746
by logback developers list 05 Jul '23

05 Jul '23

Ceki has this behavior been intentionally changed between 1.2 and 1.4? BR, Richard On 6/21/2023 2:35:36 PM, Richard Sand <rsand(a)idfconnect.com> wrote: Hi all, Has anyone else encountered this issue with the change in when resolution of a JNDI variable occurs? Or is there an alternative configuration that can still achieve what was working in 1.2? Basically I'm using a JNDI variable to define the path to a config file to include: <configuration scan="true"> <insertFromJNDI env-entry-name="java:comp/env/appHome" as="appHome" /> <include file="${appHome}/conf/logback-ssorest.xml"/> </configuration> The logback logs show: 11:12:45,716 |-INFO in ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.4.6 11:12:45,776 |-INFO in ch.qos.logback.core.joran.util.ConfigurationWatchListUtil@354c986c - Adding file:/D:/IDFC/SSORest-3.1-casso/tomcat/bin/appHome_IS_UNDEFINED/conf/logback-ssorest.xml to configuration watch list. 11:12:45,776 |-WARN in ch.qos.logback.core.joran.action.IncludeAction - Failed to open file:/D:/IDFC/SSORest-3.1-casso/tomcat/bin/appHome_IS_UNDEFINED/conf/logback-ssorest.xml 11:12:45,823 |-INFO in ch.qos.logback.core.model.processor.InsertFromJNDIModelHandler - Setting variable [appHome] to [../..] in [LOCAL] scope Any thoughts? BR, Richard [431881a4-a923-4738-a6fe-3a9eece779d9]

1 0

[JIRA] (LOGBACK-1754) OverlappingFileLockException when using prudent mode
by logback developers list 04 Jul '23

04 Jul '23

1 0

[JIRA] Updates for LOGBACK-1754: OverlappingFileLockException when using prudent mode
by logback developers list 04 Jul '23

04 Jul '23

logback / LOGBACK-1754 [Open] OverlappingFileLockException when using prudent mode ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1754 ============================== Issue created ------------------------------ Christian Habermehl created this issue on 04/Jul/23 11:19 Summary: OverlappingFileLockException when using prudent mode Issue Type: Bug Affects Versions: 1.4.8 Assignee: Logback dev list Components: logback-core Created: 04/Jul/23 11:19 Environment: Windows 10 openjdk version "17.0.5" 2022-10-18 OpenJDK Runtime Environment JBR-17.0.5+1-653.14-jcef (build 17.0.5+1-b653.14) OpenJDK 64-Bit Server VM JBR-17.0.5+1-653.14-jcef (build 17.0.5+1-b653.14, mixed mode) Debian openjdk version "17.0.2" 2022-01-18 OpenJDK Runtime Environment (build 17.0.2+8-86) OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing) Priority: Major Reporter: Christian Habermehl Description: Hi, after moving from logback 1.2.12 to 1.4.8 I ran into OverlappingFileLockExceptions when using prudent mode. {code:java} ERROR in ch.qos.logback.core.rolling.RollingFileAppender[GENERAL] - Appender [GENERAL] failed to append. java.nio.channels.OverlappingFileLockException at java.nio.channels.OverlappingFileLockException at at java.base/sun.nio.ch.FileLockTable.checkList(FileLockTable.java:229) at at java.base/sun.nio.ch.FileLockTable.add(FileLockTable.java:123) at at java.base/sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1276) at at java.base/java.nio.channels.FileChannel.lock(FileChannel.java:1089) at at ch.qos.logback.core.FileAppender.safeWrite(FileAppender.java:254) at at ch.qos.logback.core.FileAppender.writeOut(FileAppender.java:279) at at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:228) at at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:253) at at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) at at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85) at at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) at at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) at at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:426) at at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:386) at at ch.qos.logback.classic.Logger.info(Logger.java:584) at at LogbackTest$LoggerThread.run(LogbackTest.java:47) {code} This is my logback.xml {code:xml} <?xml version="1.0" encoding="UTF-8"?> <configuration debug="true"> <appender name="GENERAL" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>applog/my-log-%d\{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>120</maxHistory> </rollingPolicy> <encoder> <pattern>%date\{HH:mm:ss.SSS} [%level] %logger\{0} [%thread] [%class\{3}:%line] : %msg%n</pattern> </encoder> <prudent>true</prudent> </appender> <root level="debug"> <appender-ref ref="GENERAL" /> </root> </configuration> {code} and this is my test class: {code:java} import java.util.ArrayList; import java.util.List; import java.util.concurrent.CountDownLatch; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class LogbackTest { private static final int THREADS = 20; private void runTest() { CountDownLatch latch = new CountDownLatch(THREADS); List<Thread> threads = new ArrayList<>(THREADS); for (int i = 0; i < THREADS; i++) { LoggerThread thread = new LoggerThread(latch, "message from thread " + i); thread.start(); threads.add(thread); } for (Thread thread : threads) { try { thread.join(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(e); } } } public static void main(String... args) { new LogbackTest().runTest(); } private static final class LoggerThread extends Thread { private static final Logger LOG = LoggerFactory.getLogger(LoggerThread.class); private final CountDownLatch latch; private final String message; LoggerThread(CountDownLatch latch, String message) { setDaemon(false); this.latch = latch; this.message = message; } @Override public void run() { latch.countDown(); LOG.info(message); } } } {code} I never had this problems with logback 1.2 (the test class runs without problems when using 1.2). I didn't change the logback.xml and the jvm is the same. Here is a stack trace when the RollingFileAppender is called with 1.2.12: {code:java} at ch.qos.logback.core.recovery.ResilientOutputStreamBase.write(ResilientOutputStreamBase.java:52) at java.io.OutputStream.write(OutputStream.java:127) at ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:199) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:231) at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:235) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) 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_0_Or3Plus(Logger.java:383) at ch.qos.logback.classic.Logger.info(Logger.java:579) at LogbackTest$LoggerThread.run(LogbackTest.java:47) {code} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0