- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1392) Improve support for the JANSI library in ConsoleAppender
by QOS.CH (JIRA) 24 Mar '18

24 Mar '18

Alexandre Dutra created LOGBACK-1392: ---------------------------------------- Summary: Improve support for the JANSI library in ConsoleAppender Key: LOGBACK-1392 URL: https://jira.qos.ch/browse/LOGBACK-1392 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.2.3 Reporter: Alexandre Dutra Assignee: Logback dev list Priority: Minor The JANSI library provides an {{AnsiPrintStream}} that intercepts ANSI sequences and allows the application to react to them accordingly. Jansi is compatible with a variety of terminals, including xterm-like terminals for Windows like Mintty and MinGW. Jansi has a good algorithm to detect whether or not ANSI sequences will be correctly interpreted or not, and if not, its default behavior is to filter out such sequences. Logback's {{ConsoleAppender}} has a {{withJansi}} option. Unfortunately, Logback bypasses Jansi's detection algorithm and boldly assumes that if the OS is Windows, then the terminal is a DOS prompt. So while DOS prompts get colored, terminals like Mintty or MinGW not only lose their coloring but are sent DOS escape sequences that they can't interpret. We could improve support for JANSI with the following ideas: * Amend {{ConsoleAppender}} so that when {{withJansi}} is {{true}}, then all {{OutputStream}}s are wrapped in an {{AnsiPrintStream}}, effectively delegating to the JANSI library the decision to filter out ANSI escape sequences or not, depending on the terminal capability. This also allows users to disable or customize the coloring behavior by using system properties recognized by JANSI, such as {{jansi.skip}}. * Amend the documentation and stress that the JANSI library is the recommended solution for Windows systems, as well as for cross-platform deployments that include a mix of Windows and non-Windows systems. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/logback] 55a0b4: fix javadoc issue
by Ceki Gulcu 23 Mar '18

23 Mar '18

Branch: refs/heads/configModel Home: https://github.com/qos-ch/logback Commit: 55a0b46bbb9b292b7a2dc3cc143ef5def2d1c3b8 https://github.com/qos-ch/logback/commit/55a0b46bbb9b292b7a2dc3cc143ef5def2… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2018-03-23 (Fri, 23 Mar 2018) Changed paths: M logback-classic/src/main/java/ch/qos/logback/classic/util/LogbackMDCAdapter.java Log Message: ----------- fix javadoc issue

1 0

[JIRA] (LOGBACK-1391) indefinite wait on AsyncAppenderBase.stop
by QOS.CH (JIRA) 22 Mar '18

22 Mar '18

Jamie created LOGBACK-1391: ------------------------------ Summary: indefinite wait on AsyncAppenderBase.stop Key: LOGBACK-1391 URL: https://jira.qos.ch/browse/LOGBACK-1391 Project: logback Issue Type: Bug Components: logback-classic, logback-core Affects Versions: 1.2.3 Environment: Linux Reporter: Jamie Assignee: Logback dev list We have a multitenant application. When one "instance" is shutdown, it called logbackLogger.detactAndStopAllAppenders(). This function appears to wait indefinitely. See stack trace further below. public static synchronized void removeAndStopAllAppenders(String loggerName) \{ ch.qos.logback.classic.Logger logbackLogger = getLogger(loggerName); if (logbackLogger != null) \{ logbackLogger.detachAndStopAllAppenders(); loggers.clear(); } } ool-98202-thread-7 - priority:5 - threadId:0x000000001c4b5000 - nativeId:0x2090 - state:TIMED_WAITING stackTrace: java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.$$YJP$$wait(Native Method) at java.lang.Object.wait(Object.java) at java.lang.Thread.join(Thread.java:1257) - locked <0x00000004f21db758> (a ch.qos.logback.core.AsyncAppenderBase$Worker) at ch.qos.logback.core.AsyncAppenderBase.stop(AsyncAppenderBase.java:133) at ch.qos.logback.core.spi.AppenderAttachableImpl.detachAndStopAllAppenders(AppenderAttachableImpl.java:107) at ch.qos.logback.classic.Logger.detachAndStopAllAppenders(Logger.java:206) at com.stimulus.util.av.b(MailArchiva:67) - locked <0x00000004ef6271d8> (a java.lang.Class for com.stimulus.util.av) at com.stimulus.archiva.domain.ba.ae(MailArchiva:943) at com.stimulus.archiva.domain.ba.e(MailArchiva:209) at com.stimulus.archiva.domain.Application.al(MailArchiva:776) at com.stimulus.archiva.domain.Application.ae(MailArchiva:691) at com.stimulus.archiva.domain.j$a.run(MailArchiva:493) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Release Announcement: General Availability of JDK 10
by Rory O'Donnell 21 Mar '18

21 Mar '18

Hi Ceki, A number of items to share with you today : *1) JDK 10 General Availability * JDK 10, the first release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. We've identified no P1 bugs since we promoted build 46 almost two weeks ago, so that is the official GA release, ready for production use. GPL'd binaries from Oracle are available here: http://jdk.java.net/10 This release includes twelve features: * 286: Local-Variable Type Inference <http://openjdk.java.net/jeps/286> * 296: Consolidate the JDK Forest into a Single Repository <http://openjdk.java.net/jeps/296> * 304: Garbage-Collector Interface <http://openjdk.java.net/jeps/304> * 307: Parallel Full GC for G1 <http://openjdk.java.net/jeps/307> * 310: Application Class-Data Sharing <http://openjdk.java.net/jeps/310> * 312: Thread-Local Handshakes <http://openjdk.java.net/jeps/312> * 313: Remove the Native-Header Generation Tool (javah) <http://openjdk.java.net/jeps/313> * 314: Additional Unicode Language-Tag Extensions <http://openjdk.java.net/jeps/314> * 316: Heap Allocation on Alternative Memory Devices <http://openjdk.java.net/jeps/316> * 317: Experimental Java-Based JIT Compiler <http://openjdk.java.net/jeps/317> * 319: Root Certificates <http://openjdk.java.net/jeps/319> * 322: Time-Based Release Versioning <http://openjdk.java.net/jeps/322> *2) JDK 11 EA build 5, under both the GPL and Oracle EA licenses, are now available at **http://jdk.java.net/11**.* * 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/5/jdk-11+5.html *3) The Z Garbage Collector Project, early access builds available : * The first EA binary from from The Z Garbage Collector Project, also known as ZGC, is now available. ZGC is a scalable low latency garbage collector. For information on how to enable and use ZGC, please see the project wiki. * Project page: http://openjdk.java.net/projects/zgc/ * Wiki: https://wiki.openjdk.java.net/display/zgc/Main *4) Quality Outreach Report for **March 2018 **is available * * https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March… *5) **Java Client Roadmap Update * * We posted a blog [3] and related white paper [4] detailing our plans for the Java Client. Rgds,Rory [1] https://mreinhold.org/blog/forward-faster [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3] Blog: https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other… [4] Whitepaper: http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018ma… -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1390) When using hourly rolling policy, first cleanup after restart does nothing
by QOS.CH (JIRA) 19 Mar '18

19 Mar '18

1 0

[JIRA] (LOGBACK-1390) When using hourly rolling policy, first cleanup after restart does nothing
by QOS.CH (JIRA) 19 Mar '18

19 Mar '18

Dmitry Mikhaylov created LOGBACK-1390: ----------------------------------------- Summary: When using hourly rolling policy, first cleanup after restart does nothing Key: LOGBACK-1390 URL: https://jira.qos.ch/browse/LOGBACK-1390 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.1.11 Environment: AWS, Ubuntu 14.04, Java 8. Not really relevant here. :-) Reporter: Dmitry Mikhaylov Assignee: Logback dev list {code:java} <appender class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>./logs/access_log2</file>  <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>./logs/access_log2.%d{yyyyMMddHH}</fileNamePattern> <maxHistory>8</maxHistory> <cleanHistoryOnStart>true</cleanHistoryOnStart> </rollingPolicy> <encoder class="server.core.AccessLogEncoder"/> </appender> {code} Sometimes results in: {code:java} dmitry@prod-empires-alt02:/var/log/empires_alt$ ls -l access_log2* -rw-r--r-- 1 sgg-app sgg-app 11615 Mar 19 14:19 access_log2 -rw-r--r-- 1 sgg-app sgg-app 36639 Jan 31 01:59 access_log2.2018013101 -rw-r--r-- 1 sgg-app sgg-app 35973 Jan 31 02:59 access_log2.2018013102 -rw-r--r-- 1 sgg-app sgg-app 35235 Jan 31 07:01 access_log2.2018013106 -rw-r--r-- 1 sgg-app sgg-app 31038 Feb 1 00:01 access_log2.2018013123 -rw-r--r-- 1 sgg-app sgg-app 32906 Feb 1 01:00 access_log2.2018020100 -rw-r--r-- 1 sgg-app sgg-app 36420 Feb 2 01:01 access_log2.2018020200 -rw-r--r-- 1 sgg-app sgg-app 33444 Feb 7 07:59 access_log2.2018020707 -rw-r--r-- 1 sgg-app sgg-app 40003 Feb 9 01:01 access_log2.2018020900 -rw-r--r-- 1 sgg-app sgg-app 37604 Feb 14 06:59 access_log2.2018021406 -rw-r--r-- 1 sgg-app sgg-app 34582 Feb 15 04:02 access_log2.2018021503 -rw-r--r-- 1 sgg-app sgg-app 36082 Feb 16 01:01 access_log2.2018021600 -rw-r--r-- 1 sgg-app sgg-app 36266 Feb 16 01:59 access_log2.2018021601 -rw-r--r-- 1 sgg-app sgg-app 37487 Feb 19 01:00 access_log2.2018021900 -rw-r--r-- 1 sgg-app sgg-app 35538 Feb 19 03:00 access_log2.2018021902 -rw-r--r-- 1 sgg-app sgg-app 34022 Feb 20 06:59 access_log2.2018022006 -rw-r--r-- 1 sgg-app sgg-app 622323 Feb 21 03:00 access_log2.2018022102 -rw-r--r-- 1 sgg-app sgg-app 1597083 Feb 21 06:00 access_log2.2018022105 -rw-r--r-- 1 sgg-app sgg-app 2492269 Feb 22 01:00 access_log2.2018022200 -rw-r--r-- 1 sgg-app sgg-app 5160030 Feb 22 09:00 access_log2.2018022208 -rw-r--r-- 1 sgg-app sgg-app 9266590 Feb 22 11:00 access_log2.2018022210 -rw-r--r-- 1 sgg-app sgg-app 12357461 Feb 22 13:00 access_log2.2018022212 -rw-r--r-- 1 sgg-app sgg-app 20258598 Feb 22 15:00 access_log2.2018022214 -rw-r--r-- 1 sgg-app sgg-app 18564007 Feb 23 00:00 access_log2.2018022223 -rw-r--r-- 1 sgg-app sgg-app 15944536 Feb 23 01:00 access_log2.2018022300 -rw-r--r-- 1 sgg-app sgg-app 14619064 Feb 23 03:00 access_log2.2018022302 -rw-r--r-- 1 sgg-app sgg-app 38179 Feb 27 15:00 access_log2.2018022714 -rw-r--r-- 1 sgg-app sgg-app 38860 Feb 28 01:00 access_log2.2018022800 -rw-r--r-- 1 sgg-app sgg-app 38600 Feb 28 02:02 access_log2.2018022801 -rw-r--r-- 1 sgg-app sgg-app 35114 Feb 28 03:00 access_log2.2018022802 -rw-r--r-- 1 sgg-app sgg-app 35161 Feb 28 04:02 access_log2.2018022803 -rw-r--r-- 1 sgg-app sgg-app 33622 Feb 28 04:57 access_log2.2018022804 -rw-r--r-- 1 sgg-app sgg-app 38933 Feb 28 06:00 access_log2.2018022805 -rw-r--r-- 1 sgg-app sgg-app 32738 Feb 28 07:00 access_log2.2018022806 -rw-r--r-- 1 sgg-app sgg-app 38040 Feb 28 08:00 access_log2.2018022807 -rw-r--r-- 1 sgg-app sgg-app 38591 Feb 28 10:02 access_log2.2018022809 -rw-r--r-- 1 sgg-app sgg-app 33940 Mar 2 14:01 access_log2.2018030213 -rw-r--r-- 1 sgg-app sgg-app 35253 Mar 6 02:01 access_log2.2018030601 -rw-r--r-- 1 sgg-app sgg-app 33353 Mar 7 06:01 access_log2.2018030705 -rw-r--r-- 1 sgg-app sgg-app 34459 Mar 9 00:59 access_log2.2018030900 -rw-r--r-- 1 sgg-app sgg-app 10552521 Mar 11 12:00 access_log2.2018031111 -rw-r--r-- 1 sgg-app sgg-app 13693556 Mar 11 13:00 access_log2.2018031112 -rw-r--r-- 1 sgg-app sgg-app 36288 Mar 13 02:00 access_log2.2018031301 -rw-r--r-- 1 sgg-app sgg-app 38856 Mar 13 08:00 access_log2.2018031307 -rw-r--r-- 1 sgg-app sgg-app 36734 Mar 14 11:00 access_log2.2018031410 -rw-r--r-- 1 sgg-app sgg-app 36588 Mar 15 07:59 access_log2.2018031507 -rw-r--r-- 1 sgg-app sgg-app 36579 Mar 15 09:01 access_log2.2018031508 -rw-r--r-- 1 sgg-app sgg-app 34449 Mar 16 07:01 access_log2.2018031606 -rw-r--r-- 1 sgg-app sgg-app 36237 Mar 16 13:01 access_log2.2018031612 -rw-r--r-- 1 sgg-app sgg-app 34586 Mar 17 14:00 access_log2.2018031713 -rw-r--r-- 1 sgg-app sgg-app 29670 Mar 19 06:59 access_log2.2018031906 -rw-r--r-- 1 sgg-app sgg-app 36119 Mar 19 08:02 access_log2.2018031907 -rw-r--r-- 1 sgg-app sgg-app 34581 Mar 19 09:00 access_log2.2018031908 -rw-r--r-- 1 sgg-app sgg-app 36901 Mar 19 10:02 access_log2.2018031909 -rw-r--r-- 1 sgg-app sgg-app 35474 Mar 19 11:01 access_log2.2018031910 -rw-r--r-- 1 sgg-app sgg-app 35497 Mar 19 12:02 access_log2.2018031911 -rw-r--r-- 1 sgg-app sgg-app 30756 Mar 19 13:00 access_log2.2018031912 -rw-r--r-- 1 sgg-app sgg-app 36397 Mar 19 14:00 access_log2.2018031913 dmitry@prod-empires-alt02:/var/log/empires_alt$ date Mon Mar 19 14:21:30 UTC 2018 {code} As you can see, most of the logs are cleaned properly, but sometimes there is one or two left. Since this pattern is the same across all instance in our cluster, we suspected that the problem is related to restart. Debugging first cleanup after restart yielded this little [gem|https://github.com/qos-ch/logback/blob/5bae54c53ac3cc429d29e3b782054b1b…] On the first cleanup after app start, diff is 2768400000 (derived from INACTIVITY_TOLERANCE_IN_MILLIS), and somehow after this conversion it ends up being -424 periods. In any case this conversion seems to be completely arbitrary, so suggested fix is just to remove it. I'll submit pull request shortly. Because of legacy code, we are stuck with 1.1.x in this project, so I'd be very grateful if you could put up another official 1.1.x release. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-747) maxHistory doesnot normally work in SizeAndTimeBasedFNATP
by QOS.CH (JIRA) 14 Mar '18

14 Mar '18

1 0

[JIRA] (LOGBACK-1389) OnConsoleStatusListener example does not start
by QOS.CH (JIRA) 11 Mar '18

11 Mar '18

Hontvári József created LOGBACK-1389: ---------------------------------------- Summary: OnConsoleStatusListener example does not start Key: LOGBACK-1389 URL: https://jira.qos.ch/browse/LOGBACK-1389 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Reporter: Hontvári József Assignee: Logback dev list Priority: Minor The example in https://logback.qos.ch/manual/configuration.html#statusListener is missing an OnConsoleStatusListener::start call. Without that it will not print anything to the console. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1388) ServerSocketReceiver adds an unnecessary error status
by QOS.CH (JIRA) 11 Mar '18

11 Mar '18

Hontvári József created LOGBACK-1388: ---------------------------------------- Summary: ServerSocketReceiver adds an unnecessary error status Key: LOGBACK-1388 URL: https://jira.qos.ch/browse/LOGBACK-1388 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Reporter: Hontvári József Assignee: Logback dev list Priority: Minor If ConcurrentServerRunner stopped it correctly closes the listening socket. This causes a "listener: jjava.net.SocketException: Socket closed" internal status error message. The message is reported from the run method. The exception may indeed indicate a problem, but in case of shutdown it is expected, so it should not be reported as an error during shutdown.. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1219) logback-access exceptions during logout
by QOS.CH (JIRA) 10 Mar '18

10 Mar '18

1 0