- logback-dev - mailman3.qos.ch

[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

JDK 12 Early Access build 26 & JDK 13 Early Access builds available
by Rory O'Donnell 04 Jan '19

04 Jan '19

Hi Ceki, Happy New Year! *OpenJDK builds *- JDK 12 Early Access build 26 is available at http://jdk.java.net/12/ * 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 since last email o Distrust TLS server certificates anchored by Symantec Root CAs (JDK-8207258 <https://bugs.openjdk.java.net/browse/JDK-8207258>) o Customizing the generation of a PKCS12 keystore (JDK-8076190 <https://bugs.openjdk.java.net/browse/JDK-8076190>) o Compact Number Formatting Support (JDK-8177552 <https://bugs.openjdk.java.net/browse/JDK-8177552>) *OpenJDK builds *- JDK 13 - Early Access build 2 is available at http://jdk.java.net/13/ * 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 <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B1%22%3A%3A…> *jpackage EA builds* * This is an early access build of JEP 343: Packaging Tool <https://openjdk.java.net/jeps/343>, aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> *Quality Outreach report for December 2018* * The report for December 2018 is available here <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+for+D…> Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1225) LogbackMDCAdapter.getCopyOfContextMap() can return null which setContextMap() is not prepared to accept
by QOS.CH (JIRA) 03 Jan '19

03 Jan '19

1 0

[JIRA] (LOGBACK-1448) Please update or qualify your statements
by QOS.CH (JIRA) 03 Jan '19

03 Jan '19

Björn Kautler created LOGBACK-1448: -------------------------------------- Summary: Please update or qualify your statements Key: LOGBACK-1448 URL: https://jira.qos.ch/browse/LOGBACK-1448 Project: logback Issue Type: Task Reporter: Björn Kautler Assignee: Logback dev list On [https://logback.qos.ch/reasonsToSwitch.html] you state "Logback ships with detailed and constantly updated documentation.", but even that page itself is outdated. And besides that on [https://logback.qos.ch/documentation.html] alone there is a huge amount of dead or bad links. I clicked 5 links. 1 worked, 3 were dead and 1 lead to a scum page with history manipulation loop from which you have a hard time to come back except with closing the tab and re-opening the page you were at. Also "Automatic reloading of configuration files" is not an up-to-date argument, as log4j supports this the same. Maybe not in milliseconds range, but who needs that. Which other points are also not valid anymore? (serious question) Maybe you should specify from when this information is respectively against what log4j version this compares. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1447) Logback occasionally repeats printing logs
by QOS.CH (JIRA) 02 Jan '19

02 Jan '19

GUKUN created LOGBACK-1447: ------------------------------ Summary: Logback occasionally repeats printing logs Key: LOGBACK-1447 URL: https://jira.qos.ch/browse/LOGBACK-1447 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.1.7 Environment: *List of log jars in my project：* springframework-3.1.1-RELEASE slf4j-api-1.7.25 jcl-over-slf4j-1.7.25（Used to replace commons-logging-1.0.3） log4j-over-slf4j-1.7.25（Used to replace log4j-1.2.15） logback-core-1.1.7 logback-classic-1.1.7 *logback.xml：* <?xml version="1.0" encoding="UTF-8"?> <configuration debug="false"> <contextName>my-test</contextName> <appender name="logFile" class="ch.qos.logback.core.rolling.RollingFileAppender"> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>INFO</level> </filter> <encoder charset="UTF-8"> <ImmediateFlush>false</ImmediateFlush> <pattern>%d\{yyyy-MM-dd HH:mm:ss.SSS} [%-5level] %X\{threadId:--}%X\{clientIp} %c\{0}:%L: %m%n</pattern> </encoder> <File>c:/test.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>c:/test.log%d\{yyyyMMdd}</fileNamePattern> <maxHistory>2</maxHistory> </rollingPolicy> </appender> <appender name="asyncLogFile" class="ch.qos.logback.classic.AsyncAppender"> <discardingThreshold>0</discardingThreshold> <neverBlock>true</neverBlock> <queueSize>2048</queueSize> <includeCallerData>true</includeCallerData> <appender-ref ref="logFile" /> </appender> <appender name="errorLogFile" class="ch.qos.logback.core.rolling.RollingFileAppender"> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>ERROR</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <encoder charset="UTF-8"> <ImmediateFlush>false</ImmediateFlush> <pattern>%d\{yyyy-MM-dd HH:mm:ss.SSS} [%-5level] %X\{threadId:--}%X\{clientIp} %c\{0}:%L: %m%n</pattern> </encoder> <File>c:/error.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>c:/error.log%d\{yyyyMMdd}</fileNamePattern> <maxHistory>2</maxHistory> </rollingPolicy> </appender> <appender name="asyncErrorLogFile" class="ch.qos.logback.classic.AsyncAppender"> <discardingThreshold>0</discardingThreshold> <neverBlock>true</neverBlock> <queueSize>2048</queueSize> <includeCallerData>true</includeCallerData> <appender-ref ref="errorLogFile" /> </appender> <logger name="RocketmqClient" level="error" /> <logger name="RocketmqRemoting" level="error" /> <logger name="com.ibatis" level="INFO" /> <logger name="java.sql.Connection" level="INFO" /> <logger name="java.sql.Statement" level="INFO" /> <logger name="java.sql.PreparedStatement" level="INFO" /> <root level="INFO"> <appender-ref ref="asyncLogFile" /> <appender-ref ref="asyncErrorLogFile" /> </root> </configuration> Reporter: GUKUN Assignee: Logback dev list Priority: Blocker Hello，good programmers！ When high concurrency, the log will be printed twice： like this： 2019-01-01 14:11:55.*766* [INFO ] <T=L0MW82ZxY002Fupw><IP=10.55.63.113> GSOneAuthSource:111: loginName=testetsss,auth in redis,authResult=true 2019-01-01 14:11:55.*767* [INFO ] <T=L0MW82ZxY002Fupw><IP=10.55.63.113> GSOneAuthSource:111: loginName=testetsss,auth in redis,authResult=true I need your help to solve this problem. thanks! -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1372) SizeAndTimeBasedRollingPolicy can't remove old logs files
by QOS.CH (JIRA) 19 Dec '18

19 Dec '18

1 0

JDK 12 enters Rampdown Phase One
by Rory O'Donnell 14 Dec '18

14 Dec '18

Hi Ceki, *JDK 12 Early Access build **is now available **at : - jdk.java.net/12/* * Per the JDK 12 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. o We’ve forked the main-line source repository, jdk/jdk, to the JDK 12 stabilization repository. Changes since the last availability email * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) <http://openjdk.java.net/jeps/189> moved to *Targeted*. * JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334> moved to *Targeted*. * JEP 344: Abortable Mixed Collections for G1 <http://openjdk.java.net/jeps/344> moved to *Targeted*. * JEP 346: Promptly Return Unused Committed Memory from G1 <http://openjdk.java.net/jeps/346> to *Targeted*. * JEP 326: Raw String Literals <https://openjdk.java.net/jeps/326> (Preview) *Proposed to drop from JDK 12* o link to proposal on jdk-dev <https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html> Bug fixes reported by Open Source Projects : o JDK-8211051 - fixed in b22 - reported by JUnit5 o JDK-8211422 - fixed in b23 - reported by Apache Batik The Java Crypto Roadmap <https://java.com/cryptoroadmap> has been updated with the following target: * With the 2019-04-16 CPU, o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7 o Distrust TLS server certificates anchored by Symantec Root CAs. Oracle Java SE 8 Release Updates [3] * Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license. Rgds, Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html [3] https://java.com/en/download/release_notice.jsp -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0