April 2018 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1101) Unable to set string properties to json strings with nested nodes
by QOS.CH (JIRA) 30 Apr '18

30 Apr '18

1 0

[JIRA] (LOGBACK-1326) Allow LayoutWrappingEncoder to have a parent of a type other than Appender
by QOS.CH (JIRA) 30 Apr '18

30 Apr '18

1 0

[JIRA] (LOGBACK-990) NPE when coloring stack trace sub-pattern with evaluator
by QOS.CH (JIRA) 27 Apr '18

27 Apr '18

1 0

[JIRA] (LOGBACK-1397) SizeAndTimeBasedRollingPolicy Producing a large number of TMP cannot delete files，and size limited invalid
by QOS.CH (JIRA) 26 Apr '18

26 Apr '18

anjue created LOGBACK-1397: ------------------------------ Summary: SizeAndTimeBasedRollingPolicy Producing a large number of TMP cannot delete files，and size limited invalid Key: LOGBACK-1397 URL: https://jira.qos.ch/browse/LOGBACK-1397 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3, 1.1.7 Environment: linux Reporter: anjue Assignee: Logback dev list Priority: Critical Attachments: logback.xml, xxxxxxx.jpg  <appender name="svsNormalAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">  <layout class="ch.qos.logback.classic.PatternLayout"> <pattern> %d\{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger\{50} - %msg%n </pattern> </layout> <file>$\{logging_home}/svs-normal.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern> $\{logging_backup}/%d\{yyyy-MM-dd}/svs-normal.%d\{yyyyMMdd}.%i.log.zip </fileNamePattern> <maxFileSize>500MB</maxFileSize> <maxHistory>10</maxHistory> </rollingPolicy> </appender> -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1396) JVM fatal error with libzip.so
by QOS.CH (JIRA) 25 Apr '18

25 Apr '18

Mykhailo Osypov created LOGBACK-1396: ---------------------------------------- Summary: JVM fatal error with libzip.so Key: LOGBACK-1396 URL: https://jira.qos.ch/browse/LOGBACK-1396 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.2.3 Environment: os.name = Linux os.arch = amd64 os.version = 4.13.0-32-generic java.version = 1.8.0_161 java.runtime.version = 1.8.0_161-b12 java.class.version = 52.0 java.vm.name = Java HotSpot(TM) 64-Bit Server VM java.vm.vendor = Oracle Corporation java.vm.version = 25.161-b12 logback.xml {code:java} <appender name="???_APPENDER" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${logs.dir}/???.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>${logs.dir}/???_%d{yyyy-MM-dd}-%i.log.gz</fileNamePattern> <maxFileSize>100MB</maxFileSize> <maxHistory>14</maxHistory> <totalSizeCap>10GB</totalSizeCap> </rollingPolicy> <encoder> <pattern> %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n </pattern> </encoder> </appender> <appender name="???_ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <discardingThreshold>0</discardingThreshold> <queueSize>512</queueSize> <appender-ref ref="???_APPENDER"/> </appender>{code} Reporter: Mykhailo Osypov Assignee: Logback dev list {code:java} $ cat /home/???/hs_err_pid16492.log # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0x7) at pc=0x00007f4709ecd522, pid=16492, tid=0x00007f46ee849700 # # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build 1.8.0_161-b12) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libzip.so+0x12522] newEntry+0x62 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- T H R E A D --------------- Current thread (0x00007f4704319800): JavaThread "logback-1" daemon [_thread_in_native, id=16507, stack(0x00007f46ee749000,0x00007f46ee84a000)] siginfo: si_signo: 7 (SIGBUS), si_code: 2 (BUS_ADRERR), si_addr: 0x00007f46ee87d19d Registers: RAX=0x00007f46a800d390, RBX=0x00007f47041e8730, RCX=0x00007f46a8000020, RDX=0x00007f46a800d390 RSP=0x00007f46ee8462c0, RBP=0x00007f46ee846310, RSI=0x0000000000000ae0, RDI=0x00007f46ee846240 R8 =0x0000000000000000, R9 =0x00007f46ee846390, R10=0x00007f46f5175918, R11=0x000000076d60a248 R12=0x00007f46ee87d180, R13=0x00007f46a800d390, R14=0x000000005aef14d5, R15=0x00007f47041bbcb0 RIP=0x00007f4709ecd522, EFLAGS=0x0000000000010202, CSGSFS=0x002b000000000033, ERR=0x0000000000000004 TRAPNO=0x000000000000000e Top of Stack: (sp=0x00007f46ee8462c0) 0x00007f46ee8462c0: 00007f46ee8468e0 00007f4600000000 0x00007f46ee8462d0: 00000007c00007a8 00007f470bb4986e 0x00007f46ee8462e0: 00007f46a800d390 00007f47041e8730 0x00007f46ee8462f0: 00007f466423be70 00007f47041bbcb0 0x00007f46ee846300: 000000005aef14d5 000000000000002a 0x00007f46ee846310: 00007f46ee846370 00007f4709ecdc7f 0x00007f46ee846320: 00007f4704319800 01007f46ee846af0 0x00007f46ee846330: 00007f46ee846390 00007f46ee8463bb 0x00007f46ee846340: 00007f46ee8463b9 00007f46ee846390 0x00007f46ee846350: 000000000000002a 00007f47043199f8 0x00007f46ee846360: 00007f46ee8467e8 0000000000000001 0x00007f46ee846370: 00007f46ee8467d0 00007f4709ebeec0 0x00007f46ee846380: 0000000000000138 00007f47041bbcb0 0x00007f46ee846390: 6c2f736f712f6863 632f6b636162676f 0x00007f46ee8463a0: 6566694c2f65726f 6e614d656c637943 0x00007f46ee8463b0: 616c632e72656761 00007f4600007373 0x00007f46ee8463c0: 00000027ee84783c 00007f46ee846b90 0x00007f46ee8463d0: 00000000000000d0 00007f46ee848454 0x00007f46ee8463e0: 0000000000000138 00007f46ee847c0c 0x00007f46ee8463f0: 00000027ee847c00 00007f46ee846bc0 0x00007f46ee846400: 00007f46ee847bf8 00007f46ee847bfc 0x00007f46ee846410: 0000000000000138 00007f46ee848464 0x00007f46ee846420: 00000030ee847d40 00007f46ee847d40 0x00007f46ee846430: 00007f46ee847c20 00007f46ee847c20 0x00007f46ee846440: 0000001aee847bd8 00007f46ee846c10 0x00007f46ee846450: 00000027ee848470 00007f46ee846c20 0x00007f46ee846460: 00000000000000d0 00007f46ee847bcc 0x00007f46ee846470: 0000000000000138 00007f46ee847bc4 0x00007f46ee846480: 00007f46ee847bb8 00007f46ee847bbc 0x00007f46ee846490: 00007f46ee848480 00007f46ee848484 0x00007f46ee8464a0: 00007f46ee847ba8 00007f46ee847bac 0x00007f46ee8464b0: 00007f46ee847ba0 00007f46ee847ba4 Instructions: (pc=0x00007f4709ecd522) 0x00007f4709ecd502: 00 48 c7 40 28 00 00 00 00 41 80 7f 30 00 0f 84 0x00007f4709ecd512: 8a 02 00 00 4c 8b 63 08 4d 2b 67 28 4d 03 67 18 0x00007f4709ecd522: 41 0f b6 5c 24 1d 41 0f b6 44 24 1c c1 e3 08 09 0x00007f4709ecd532: c3 41 0f b6 44 24 1e 88 45 bd 41 0f b6 54 24 20 Register to memory mapping: RAX=0x00007f46a800d390 is an unknown value RBX=0x00007f47041e8730 is an unknown value RCX=0x00007f46a8000020 is an unknown value RDX=0x00007f46a800d390 is an unknown value RSP=0x00007f46ee8462c0 is pointing into the stack for thread: 0x00007f4704319800 RBP=0x00007f46ee846310 is pointing into the stack for thread: 0x00007f4704319800 RSI=0x0000000000000ae0 is an unknown value RDI=0x00007f46ee846240 is pointing into the stack for thread: 0x00007f4704319800 R8 =0x0000000000000000 is an unknown value R9 =0x00007f46ee846390 is pointing into the stack for thread: 0x00007f4704319800 R10=0x00007f46f5175918 is at entry_point+88 in (nmethod*)0x00007f46f5175750 R11=0x000000076d60a248 is an oop {code} I dont have reproducible example, that has just happened -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1395) Logback date output is in GMT and not in the default timezone of the host Java platform is used
by QOS.CH (JIRA) 24 Apr '18

24 Apr '18

Nimrod_G created LOGBACK-1395: --------------------------------- Summary: Logback date output is in GMT and not in the default timezone of the host Java platform is used Key: LOGBACK-1395 URL: https://jira.qos.ch/browse/LOGBACK-1395 Project: logback Issue Type: Bug Affects Versions: 1.1.9 Environment: We have 2 services which every one of them include logback.xml configuration file and run on the same JVM. In one of them we have an issue that the date timestamp include in the log is displayed with GMT timestamp, while on the other service the timestamp is correct as the local host time. This is issued appender: {code:java} <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${HOME:-..}/myLog.log</file> <encoder>  <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [thread_id=%t] %-5level %logger{50} - %msg%n</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">  <fileNamePattern>${HOME:-..}/%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern> <maxFileSize>1GB</maxFileSize> <maxHistory>10</maxHistory> <totalSizeCap>10GB</totalSizeCap> <cleanHistoryOnStart>true</cleanHistoryOnStart> </rollingPolicy> </appender> {code} The pattern {code:java} <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} {code} doesn't include any timezone parameter and by default should present the default timezone of the host Java platform is used (which in this case on the tested machine is GMT+3). Why it's presented in GMT? Reporter: Nimrod_G Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1356) Have ILoggingEvent implementations include extra arguments to Logger methods
by QOS.CH (JIRA) 13 Apr '18

13 Apr '18

1 0

JDK 11 Early Access build 8 available
by Rory O'Donnell 12 Apr '18

12 Apr '18

Hi Ceki, **JDK 11 EA build 8, *****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/8/jdk-11+8.html *Notable changes in JDK 11 EA builds since last email:* * Build 8: o If you have a library that uses the Selector API heavily then now would be a good time to test it out. [1] * Build 7 o The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and will be removed in a future release. * Build 6: o JDK-8193033 : remove terminally deprecated sun.misc.Unsafe.defineClass. Users should use the public replacement `java.lang.invoke.MethodHandles.Lookup.defineClass` which was added in Java SE 9. [2] ** *SURVEY: The HotSpot Serviceability Agent (SA) *[3] * If you have used, or have (support) processes that utilize the Serviceability Agent or related APIs, then we would definitely appreciate if you would complete this survey: https://www.surveymonkey.com/r/CF3MYDL Regards, Rory [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-April/004964.html [2] https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lo… [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001052.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1297) Logback fails to roll once the file count exceeds 1000
by QOS.CH (JIRA) 10 Apr '18

10 Apr '18

1 0

[JIRA] (LOGBACK-1362) NullPointerException in OutputStreamAppender on logback reconfiguratiuon
by QOS.CH (JIRA) 09 Apr '18

09 Apr '18

1 0