May 2017 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-995) Standalone rollover gets exception
by QOS.CH (JIRA) 19 May '17

19 May '17

1 0

[JIRA] (LOGBACK-995) Standalone rollover gets exception
by QOS.CH (JIRA) 19 May '17

19 May '17

1 0

[JIRA] (LOGBACK-995) Standalone rollover gets exception
by QOS.CH (JIRA) 19 May '17

19 May '17

1 0

JDK 9 EA Build 170 is available on jdk.java.net
by Rory O'Donnell 19 May '17

19 May '17

Hi Ceki, * JDK 9 Early Access* build 170 is available at the new location : - jdk.java.net/9/ A summary of all the changes in this build are listed here <http://download.java.net/java/jdk9/changes/jdk-9+170.html>. Changes which were introduced since the last availability email that may be of interest : * b168 - JDK-8175814: Update default HttpClient protocol version and optional request version o related to JEP 110 : HTTP/2 Client. * b169 - JDK-8178380 : Module system implementation refresh (5/2017) o changes in command line options * b170 - JDK-8177153 : LambdaMetafactory has default constructorIncompatible change, o release note: JDK-8180035 *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev mailing list *[1] * Proposal: Allow illegal reflective access by default in JDK 9 In short, the existing "big kill switch" of the `--permit-illegal-access` option [1] will become the default behavior of the JDK 9 run-time system, though without as many warnings. The current behavior of JDK 9, in which illegal reflective-access operations from code on the class path are not permitted, will become the default in a future release. Nothing will change at compile time. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1301) update from 1.1.6 to 1.1.7 version cause "WARNING Couldn't destroy threadgroup" during run by exec-maven-plugin
by QOS.CH (JIRA) 18 May '17

18 May '17

Roman created LOGBACK-1301: ------------------------------ Summary: update from 1.1.6 to 1.1.7 version cause "WARNING Couldn't destroy threadgroup" during run by exec-maven-plugin Key: LOGBACK-1301 URL: https://jira.qos.ch/browse/LOGBACK-1301 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.1.7 Environment: $ mvn -version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: /opt/maven/default Java version: 1.8.0_121, vendor: Oracle Corporation Java home: /opt/jdk1.8.0_121/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.13.0-101-generic", arch: "amd64", family: "unix" Reporter: Roman Assignee: Logback dev list There is java maven project that do logging {code} ... <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.1.6</version> </dependency> ... {code} it works fine by itself, and it is executed by exec-maven-plugin in another project, works fine. On upgrade of project to 1.1.7 version , following WARNING appear during run by exec-maven-plugin {code} ... [INFO] --- exec-maven-plugin:1.4.0:java (default-cli) @ rdbds-xe-builder --- [WARNING] thread Thread[logback-1,5,com.mycompany.job.ApplyMultipleScriptsRunner] was interrupted but is still alive after waiting at least 15000msecs [WARNING] thread Thread[logback-1,5,com.mycompany.job.ApplyMultipleScriptsRunner] will linger despite being asked to die via interruption [WARNING] NOTE: 1 thread(s) did not finish despite being asked to via interruption. This is not a problem with exec:java, it is a problem with the running code. Although not serious, it should be remedied. [WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=com.mycompany.job.ApplyMultipleScriptsRunner,maxpri=10] java.lang.IllegalThreadStateException at java.lang.ThreadGroup.destroy(ThreadGroup.java:778) at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS .... {code} Unfortunately I can not share projects, but I could provide more details on request. It is not clear why version bump cause such problem, any advices on how to investigate problem or what could cause it are appreciated. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1300) logback-access: log HttpSession attributes
by QOS.CH (JIRA) 18 May '17

18 May '17

Nikita Akhnin created LOGBACK-1300: -------------------------------------- Summary: logback-access: log HttpSession attributes Key: LOGBACK-1300 URL: https://jira.qos.ch/browse/LOGBACK-1300 Project: logback Issue Type: New Feature Components: logback-access Reporter: Nikita Akhnin Assignee: Logback dev list It seems that logback-access can't log HttpSession attributes for now while JULI can do it with %\{xxx}s pattern code. Implementing this feature could increase compability with JULI and make migration from JUI to logback-access easier -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

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

17 May '17

1 0

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

10 May '17

1 0

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

10 May '17

Jason Flores created LOGBACK-1297: ------------------------------------- Summary: Logback fails to roll once the file count exceeds 1000 Key: LOGBACK-1297 URL: https://jira.qos.ch/browse/LOGBACK-1297 Project: logback Issue Type: Bug Affects Versions: 1.2.3 Environment: Windows Server 2012 R2 Processor: Intel Xeon CPU E5-2676 v3 @ 2.40GHz Memory: 4Gb Reporter: Jason Flores Assignee: Logback dev list Attachments: logqueue-rolling-0.png, logqueue-rolling-1.png Using the configuration below, copied from Chapter 4: Appenders, of the Logback Manual I've modified the maxFileSize, maxHistory, and totalSizeCap values. {{<?xml version="1.0" encoding="UTF-8"?>}} {{}} {{<configuration scan='true' scanPeriod='30 seconds'>}}{{<appender name='FILE' class='ch.qos.logback.core.rolling.RollingFileAppender'>}} {{ <file>3mlogqueueforwardservice.log</file>}} {{ <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">}} {{ }} {{ <fileNamePattern>3mlogqueueforwardservice-%d\{yyyy-MM-dd}.%i.log</fileNamePattern>}} {{ }} {{ <maxFileSize>20MB</maxFileSize>}} {{ }} {{ <maxHistory>2</maxHistory>}} {{ }} {{ <totalSizeCap>100MB</totalSizeCap>}} {{ </rollingPolicy>}} {{ <encoder>}} {{ <charset>UTF-8</charset>}} {{ <pattern>%date %level [%thread] %logger\{10} [%file:%line] %msg%n</pattern>}} {{ </encoder>}} {{ </appender>}}{{<logger name="com.mmm.his" level='info' additivity='false'>}} {{ <appender-ref ref='FILE' />}} {{ </logger>}} {{ <root level='warn'>}} {{ <appender-ref ref='FILE' />}} {{ </root>}} {{</configuration>}} For this configuration I should only ever have 5 files of ~20mb. The rolling functionality appears to work fine when the index %i is < 1000, after which the totalSizeCap fails and files are endlessly written at ~20mb until all the available space on the machine is consumed. The log files contain no indication of Logback failing... The two images attached show the log file rolling successfully and then failing to remove files as the index increases > 1000. I've replicated this several times, but only by watching the logs grow and inspecting the contents of the log; our application collects and logs rather quickly. Is there an interim solution? We're stucking restarting and deleting each time the problem occurs. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1296) Compute hash value from exception stacks
by QOS.CH (JIRA) 05 May '17

05 May '17

Pierre Smeyers created LOGBACK-1296: --------------------------------------- Summary: Compute hash value from exception stacks Key: LOGBACK-1296 URL: https://jira.qos.ch/browse/LOGBACK-1296 Project: logback Issue Type: New Feature Components: logback-classic Affects Versions: 1.3.0 Reporter: Pierre Smeyers Assignee: Logback dev list Priority: Minor Comparing two stack traces can be somewhat painful if you want to check whether two errors are - or not - occurrences of the same error. This new feature aims at computing a hash (hexadecimal integer) for each individual error stack trace, and inline them in the stack trace and/or output it as an individual conversion word. Ex: {{{color:#ff0000}#07e70d1e{color}> com.xyz.MyApp$MyClient$MyClientException: An error occurred while getting the things}} {{ at com.xyz.MyApp$MyClient.getTheThings(MyApp.java:26)}} {{ at com.xyz.MyApp.test_logging(MyApp.java:16)}} {{ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)}} {{ at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)}} {{ at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)}} {{ at java.lang.reflect.Method.invoke(Method.java:498)}} {{ at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)}} {{ at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)}} {{ ...}} {{Caused by: {color:#ff0000}#393b506a{color}> com.xyz.MyApp$HttpStack$HttpError: I/O error on GET request for http://dummy/things}} {{ at com.xyz.MyApp$HttpStack.get(MyApp.java:40)}} {{ at com.xyz.MyApp$MyClient.getTheThings(MyApp.java:24)}} {{ ... 23 common frames omitted}} {{Caused by: {color:#ff0000}#d6db326f{color}> java.net.SocketTimeoutException: Read timed out}} {{ at com.xyz.MyApp$HttpStack.get(MyApp.java:38)}} {{ ... 24 common frames omitted}} Those hash will help you detect several occurrences of the same error, as it is highly probable that two errors with the same hash will be - indeed - occurrences of the same error. I've already open-sourced this feature in a separate library (see [https://github.com/Orange-OpenSource/orange-mathoms-logging] ). It is very useful (especially when indexing this hash into Elasticsearch, to track the error history, frequency, ...) and quite used internally at Orange, and I though it would be nice to contribute to Logback... An implementation proposal is ready in my GitHub account See: [https://github.com/pismy/logback/tree/stack-hash] Let me know if I should create a PR now or start a discussion about the design. Thanks, Pierre. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0