- logback-dev - mailman3.qos.ch

[JIRA] Updates for LOGBACK-1738: Some flaky tests
by logback developers list 12 May '23

12 May '23

logback / LOGBACK-1738 [Open] Some flaky tests ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1738 ============================== Issue created ------------------------------ Agor Malon created this issue on 12/May/23 20:07 Summary: Some flaky tests Issue Type: Bug Affects Versions: 1.4.7 Assignee: Logback dev list Components: logback-classic, logback-core Created: 12/May/23 20:07 Labels: Tests Priority: Major Reporter: Agor Malon Description: Hello, We tried running your project and discovered that it contains some flaky tests (i.e., tests that nondeterministically pass and fail). We found these tests to fail more frequently when running them on certain machines of ours. To prevent others from running this project and its tests in machines that may result in flaky tests, we suggest adding information to the README.md file indicating the minimum resource configuration for running the tests of this project as to prevent observation of test flakiness. If we run this project in a machine with 1cpu and 1gb ram, we observe flaky tests. We found that the tests in this project did not have any flaky tests when we ran it on machines with 2cpu and 2gb ram. Here is a list of the tests we have identified and their likelihood of failure on a system with less than the recommended 2 CPUs and 2 GB RAM. # org.apache.shardingsphere.elasticjob.error.handler.wechat.WechatJobErrorHandlerTest#assertHandleExceptionWithNotifySuccessful ( 4 out 10 ) # org.apache.shardingsphere.elasticjob.cloud.scheduler.mesos.MesosStateServiceTest#assertExecutors (1 out 10) # org.apache.shardingsphere.elasticjob.error.handler.wechat.WechatJobErrorHandlerTest#assertHandleExceptionWithWrongToken (1 out 10) # org.apache.shardingsphere.elasticjob.http.executor.HttpJobExecutorTest#assertProcessWithGet (1 out 10) # org.apache.shardingsphere.elasticjob.lite.spring.namespace.job.OneOffJobSpringNamespaceWithTypeTest#jobScriptWithJobTypeTest (1 out 10) Please let me know if you would like us to create a pull request on this matter (possibly to the readme of this project). Thank you for your attention to this matter. We hope that our recommendations will be helpful in improving the quality and performance of your project, especially for others to use h3. Reproducing Dockerfile {code:java} FROM maven:3.5.4-jdk-11 WORKDIR /home/ RUN git clone https://github.com/apache/shardingsphere-elasticjob && \ cd shardingsphere-elasticjob && \ git checkout 2bfce1ebc39475e1b8eda456b673ab9431c0f270 WORKDIR /home/shardingsphere-elasticjob RUN mvn install -DskipTests ENTRYPOINT ["mvn", "test", "-fn"] {code} Build the image: {code:java} $> mkdir tmp $> cp Dockerfile tmp $> cd tmp $> docker build -t elasticjob . # estimated time of build 3m {code} Running: this configuration likely prevents flakiness (no flakiness in 10 runs) {code:java} $> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 elasticjob | tee output.txt $> grep "Failures:" output.txt # checking results {code} this other configuration -similar to the previous- can't prevent flaky tests (observation in 10 runs) {code:java} $> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 elasticjob | tee output2.txt $> grep "Failures:" output2.txt # checking results{code} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1738) Some flaky tests
by logback developers list 12 May '23

12 May '23

1 0

Announcing investment by the Sovereign Tech Fund
by logback developers list 12 May '23

12 May '23

Hello all, In addition to preexisting support from companies such as Google, Exolab and Spotify R&D, we are excited to announce a sustained and multi-year investment from the Sovereign Tech Fund (STF) for the maintenance and improvement of logback, SLF4J and reload4j projects [1]. In 2006, we founded the SLF4J and logback projects and continue to maintain them until this day. Cumulatively, the artifacts of these two projects are downloaded over 4 billion times per year. Given the sheer volume of users, maintaining the SLF4J and logback projects can be rather time consuming. In 2022, we started the reload4j project with the goal of fixing critical security issues in log4j 1.x. We wish to continue providing the most reliable, fast and flexible logging framework for Java developers and heartily thank the STF for choosing to invest in our projects. The Sovereign Tech Fund supports the development, improvement and maintenance of digital infrastructure. Their goal is to sustainably strengthen the open source ecosystem, with a focus on security, resilience, technological diversity, and the people behind the projects. As Cailean Osborne aptly put it [2]: “As one of the first governmental funds dedicated to OSS, the STF is spearheading a critical shift in how governments invest in the long-term viability of OSS and digital public goods." In our own experience, even the tiniest token of support counts. It goes without saying that a larger multi-year investment counts all the more. We would like to express our gratitude to the Sovereign Tech Fund for their support and for paving the way for this historical change. [1] https://tinyurl.com/stfLogback [2] https://tinyurl.com/stfCaileanOsborne -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

[JIRA] (LOGBACK-212) Add a layout that produces JSON
by logback developers list 11 May '23

11 May '23

1 0

[JIRA] (LOGBACK-1711) Deadlock when using Virtual Threads
by logback developers list 06 May '23

06 May '23

1 0

[JIRA] (LOGBACK-1737) NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code
by logback developers list 02 May '23

02 May '23

1 0

[JIRA] Updates for LOGBACK-1737: NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code
by logback developers list 02 May '23

02 May '23

logback / LOGBACK-1737 [Open] NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1737 ============================== Issue created ------------------------------ WFR created this issue on 02/May/23 9:29 Summary: NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code Issue Type: Bug Affects Versions: 1.3.7 Assignee: Logback dev list Components: logback-core Created: 02/May/23 9:29 Environment: Java 8 Priority: Critical Reporter: WFR Description: Changes in https://jira.qos.ch/browse/LOGBACK-1595 (in detail [https://github.com/qos-ch/logback/blob/f93f3bbe643d3859cc18cb4ee8829d9c26e8…] fail on Java 8 (empty orElseThrow()-Method has only been added in Java 10 (see [https://bugs.openjdk.org/browse/JDK-8140281).|https://bugs.openjdk.org/brow…1) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1736) Make OSGi service-loader requirement for spi.Configurator optional
by logback developers list 25 Apr '23

25 Apr '23

1 0

[JIRA] Updates for LOGBACK-1736: Make OSGi service-loader requirement for spi.Configurator optional
by logback developers list 25 Apr '23

25 Apr '23

logback / LOGBACK-1736 [Open] Make OSGi service-loader requirement for spi.Configurator optional ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1736 ============================== Issue created ------------------------------ Hannes Wellmann created this issue on 25/Apr/23 18:02 Summary: Make OSGi service-loader requirement for spi.Configurator optional Issue Type: Sub-task Affects Versions: 1.3.7, 1.4.7 Assignee: Logback dev list Components: logback-classic Created: 25/Apr/23 18:02 Priority: Critical Reporter: Hannes Wellmann Description: For LOGBACK-1729 the OSGi Service Loader Mediator Manifest entries were enhanced to be able to load logback {{Configurator}} services provided by other OSGi bundles. Unintentionally this requirement was only specified with {{cardinality:=multiple}} and without {{{}resolution:=optional{}}}, which means that at least one bundle providing a {{Configurator}} service is required (but multiple are possible). But having no provided {{Configurator}} at all is also a valid scenario and the code is prepared for that. Therefore the corresponding Service Loader Mediator requirement should be marked as optional ({{{}resolution:=optional{}}}) in order to allow zero up to arbitrary many provided {{Configurator}} services{{{}.{}}} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1734) Add support for NDJSON / structured logging - popular log collector/shipper format
by logback developers list 20 Apr '23

20 Apr '23

1 0