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

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

17 Jan '19

1 0

[JIRA] (LOGBACK-1421) Logback 1.2.3 threads getting deadlocked at CachingDateFormatter
by QOS.CH (JIRA) 17 Jan '19

17 Jan '19

1 0

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

17 Jan '19

Mickael Marrache created LOGBACK-1454: ----------------------------------------- Summary: StackOverflow error Key: LOGBACK-1454 URL: https://jira.qos.ch/browse/LOGBACK-1454 Project: logback Issue Type: Bug Affects Versions: 1.2.3 Reporter: Mickael Marrache Assignee: Logback dev list I just encountered the following error: {code:java} 2019-01-17 16:40:00.048 WARN 5845 --- [p1932274274-291] o.e.j.u.thread.strategy.EatWhatYouKill : java.lang.StackOverflowError: null at java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:72) ~[na:1.8.0_171] at sun.reflect.GeneratedMethodAccessor230.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_171] at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_171] at ch.qos.logback.classic.spi.ThrowableProxy.<init>(ThrowableProxy.java:66) ~[logback-classic-1.2.3.jar!/:na] at ch.qos.logback.classic.spi.ThrowableProxy.<init>(ThrowableProxy.java:60) ~[logback-classic-1.2.3.jar!/:na] at ch.qos.logback.classic.spi.ThrowableProxy.<init>(ThrowableProxy.java:60) ~[logback-classic-1.2.3.jar!/:na] at ch.qos.logback.classic.spi.ThrowableProxy.<init>(ThrowableProxy.java:72) ~[logback-classic-1.2.3.jar!/:na] .............. [the constructor appearing hundreds of time in the stack trace] {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1453) Let us default to ALL when no keys are specified - ResponseHeaderConverter
by QOS.CH (JIRA) 17 Jan '19

17 Jan '19

이경욱 created LOGBACK-1453: ---------------------------- Summary: Let us default to ALL when no keys are specified - ResponseHeaderConverter Key: LOGBACK-1453 URL: https://jira.qos.ch/browse/LOGBACK-1453 Project: logback Issue Type: Improvement Components: logback-access Reporter: 이경욱 Assignee: Logback dev list Priority: Minor RequestHeaderConverter is work, but ResponseHeaderConvert is not. [https://github.com/qos-ch/logback/commit/e5345c42a9404590b0e095a027b536af9e…] [https://github.com/qos-ch/logback/blob/4dd08e68321548cd85251ec389f5a832505e…] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1452) stackoverflow cause logback die
by QOS.CH (JIRA) 16 Jan '19

16 Jan '19

xiezhaoodong created LOGBACK-1452: ------------------------------------- Summary: stackoverflow cause logback die Key: LOGBACK-1452 URL: https://jira.qos.ch/browse/LOGBACK-1452 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: jdk 1.8 Reporter: xiezhaoodong Assignee: Logback dev list Priority: Blocker Attachments: image-2019-01-16-15-37-57-659.png execute arraybloking put method ,if happend stackoverflow error ,may be cause finally block ```lock.unlock()``` can not executed。 all thread print log will be hang forever look this: 937 thread are waiting lock,but owner thread is termernal !image-2019-01-16-15-37-57-659.png! -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1451) Logger for a file is not getting created with logback version 1.1.7
by QOS.CH (JIRA) 16 Jan '19

16 Jan '19

David Prasad created LOGBACK-1451: ------------------------------------- Summary: Logger for a file is not getting created with logback version 1.1.7 Key: LOGBACK-1451 URL: https://jira.qos.ch/browse/LOGBACK-1451 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.1.7 Environment: Production Reporter: David Prasad Assignee: Logback dev list Priority: Blocker Hello All, We have upgraded our logback version from 1.1.3 to 1.1.7, and facing this problem of logs are not getting written to files for specific adapter code, which will create a file name called "adapter.log". We also observed the application logs are written properly to "app.log", but adapter logs are not being written to adapter log file properly. Kindly help us to understand what is causing v1.1.7 to not update the custom adapter log files. Thanks, David -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1450) Logback leaving .tmp files with multiple instances in Jboss with springBoot
by QOS.CH (JIRA) 15 Jan '19

15 Jan '19

Rishy created LOGBACK-1450: ------------------------------ Summary: Logback leaving .tmp files with multiple instances in Jboss with springBoot Key: LOGBACK-1450 URL: https://jira.qos.ch/browse/LOGBACK-1450 Project: logback Issue Type: Task Components: logback-classic, logback-core Affects Versions: 1.1.11 Environment: In linux with Jboss as an application server with SpringBoot (1.5.10) and java 1.8 Reporter: Rishy Assignee: Logback dev list Priority: Blocker We are deploying the application with multiple instances in JBoss. We log back with version 1.1.11 and spring-boot 1.5.10. When log back is trying to append the log file and rolling back as a .zip file it's leaving .tmp files. Below is the scenario When the application is running in three instances, it's appending only one instance logs into the zip leaving other two instances as .tmp files, which actually should be appended under the same zip file. This is a blocker in our production, with this behavior we are unable to trace out the issue. Below is the Logback.xml: <configuration> <property resource="bootstrap.yml" /> <springProperty name="appName" source="spring.application.name"/> <springProperty name="loglevel" source="logging.level.com.some.package"/> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{ISO8601} %-5p [%c{3}] [%t] %m%n</pattern> </encoder> </appender> <appender name ="APPLICATION" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/appllogs/spp/${appName}.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/appllogs/backup/${appName}/%d{yyyy-MM-dd}%i.log.zip</fileNamePattern> <maxHistory>7</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>500MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> <totalSizeCap>1GB</totalSizeCap> </rollingPolicy> <encoder> <pattern>%d %-5p %m%n</pattern> </encoder> </appender> <logger name="com.some.package" level="${loglevel}" additivity="false"> <appender-ref ref="CONSOLE" /> <appender-ref ref="APPLICATION"/> </logger> <root level="${loglevel}" > <appender-ref ref="CONSOLE" /> <appender-ref ref="APPLICATION"/> </root> </configuration> -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1449) SocketAppender reset timestamp during serialization log event
by QOS.CH (JIRA) 11 Jan '19

11 Jan '19

Jan created LOGBACK-1449: ---------------------------- Summary: SocketAppender reset timestamp during serialization log event Key: LOGBACK-1449 URL: https://jira.qos.ch/browse/LOGBACK-1449 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.3.0-alpha4 Environment: The roblem will probably be at LoggingEventVO.java:74 ledo.timeStamp = le.getSequenceNumber(); Reporter: Jan Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

why ayncAppender not use mutil threads to consume blocking queue in the logback v_1.3.0-alpha4
by KnightWu 11 Jan '19

11 Jan '19

hello, the version is logback v_1.3.0-alpha4, maybe i dont understand all, so i have a couple of stupid questions. 1. AsyncAppenderBase.java , line 57 , i only see a worker (a thread) to consume blocking queue, is there any configuration to change to mutil threads? Or , why not use mutil threads to consume, i think it may improve performance . 2. OutputStreamAppender.java , line 217, judge whether started or not, but this line is before the write lock . OutputStreamAppender.java , line 197, is it possible that the outputstream is already closed , but some write threads are still waiting for the write lock in line 297, then write to stream that are already closed? 3. OutputStreamAppender , line 141, why not immediately flush the outputstream after writing footer bytes? thank to you , first. Can anyone give me answer? -- Sent from: http://logback.10977.n7.nabble.com/Developer-f3683.html

1 0

[JIRA] (LOGBACK-1338) SizeAndTimeBasedRollingPolicy do not delete the old files
by QOS.CH (JIRA) 09 Jan '19

09 Jan '19

1 0