- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-469) Potential memory leaks if there is no underlying implementation
by QOS.CH (JIRA) 16 Dec '19

16 Dec '19

[ https://jira.qos.ch/browse/SLF4J-469?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-469. ------------------------------ Resolution: Fixed Fixed in [commit 306d8fd2|https://github.com/qos-ch/slf4j/commit/306d8fd23d89b0a] on master and in [commit c6c7a98a7ee1|https://github.com/qos-ch/slf4j/commit/c6c7a98a7ee1e7138] on the 1.7 maintenance branch. > Potential memory leaks if there is no underlying implementation > --------------------------------------------------------------- > > Key: SLF4J-469 > URL: https://jira.qos.ch/browse/SLF4J-469 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.7.26 > Environment: java 8 > slf4j 1.7.26 > > Reporter: yu > Assignee: Ceki Gülcü > Priority: Critical > Labels: logging, substitution > Fix For: 2.0.0-alpha2, 1.7.30 > > > > *If I don't have 'logback' 'log4j'...... Implementation class* > The problem lies in the method > *public static ILoggerFactory getILoggerFactory()* > first Thread1: > {code:java} > if (INITIALIZATION_STATE == UNINITIALIZED) { > init..... > } > {code} > secode Thread2: > {code:java} > case ONGOING_INITIALIZATION: > return SUBST_FACTORY;{code} > obtained "SUBST_FACTORY"， > and obtained "SubstituteLogger" > > third: > Thread1: > {code:java} > //init failed cache "NoClassDefFoundError" > INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION; > {code} > *The SubstituteLogger obtained by Thread2 will always output the log to the queue until the memory overflows.* > {code:java} > // code placeholder > synchronized public Logger getLogger(String name) { > SubstituteLogger logger = loggers.get(name); > if (logger == null) { > logger = new SubstituteLogger(name, eventQueue, postInitialization); > loggers.put(name, logger); > } > return logger; > } > public void info(String msg) { > delegate().info(msg); > } > Logger delegate() { > if(_delegate != null) { //_delegate== null forever > return _delegate; > } > if(createdPostInitialization) { createdPostInitialization == false forever > return NOPLogger.NOP_LOGGER; > } else { > return getEventRecordingLogger(); > } > } > {code} > > > > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] 0b97c4: move to 1.7.30
by Ceki Gulcu 16 Dec '19

16 Dec '19

Branch: refs/heads/1.7-maintenance Home: https://github.com/qos-ch/slf4j Commit: 0b97c416e42a184ff9728877b461c616187c58f7 https://github.com/qos-ch/slf4j/commit/0b97c416e42a184ff9728877b461c616187c… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-12-16 (Mon, 16 Dec 2019) Changed paths: M integration/pom.xml M jcl-over-slf4j/pom.xml M jul-to-slf4j/pom.xml M log4j-over-slf4j/pom.xml M osgi-over-slf4j/pom.xml M pom.xml M slf4j-android/pom.xml M slf4j-api/pom.xml M slf4j-ext/pom.xml M slf4j-jcl/pom.xml M slf4j-jdk14/pom.xml M slf4j-log4j12/pom.xml M slf4j-migrator/pom.xml M slf4j-nop/pom.xml M slf4j-simple/pom.xml M slf4j-site/pom.xml Log Message: ----------- move to 1.7.30

1 0

[qos-ch/slf4j] c6c7a9: fix SLF4J-469
by Ceki Gulcu 16 Dec '19

16 Dec '19

Branch: refs/heads/1.7-maintenance Home: https://github.com/qos-ch/slf4j Commit: c6c7a98a7ee1e71382348ae3e41ff7818dfafd65 https://github.com/qos-ch/slf4j/commit/c6c7a98a7ee1e71382348ae3e41ff7818dfa… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-12-16 (Mon, 16 Dec 2019) Changed paths: M integration/build.xml A integration/src/test/java/org/slf4j/helpers/LoggerAccessingThread2.java A integration/src/test/java/org/slf4j/helpers/NoBindingMultithreadedInitializationTest2.java M slf4j-api/src/main/java/org/slf4j/LoggerFactory.java M slf4j-api/src/test/java/org/slf4j/helpers/MultithreadedInitializationTest.java Log Message: ----------- fix SLF4J-469

1 0

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

14 Dec '19

Hi Ceki, *Per the JDK 14 schedule , we are now in Rampdown Phase One* *Please advise if you have found any issues while testing the latest Early Access build. * * Schedule for JDK 14 o *2019/12/12 Rampdown Phase One* o 2020/01/16 Rampdown Phase Two o 2020/02/06 Initial Release Candidate o 2020/02/20 Final Release Candidate o 2020/03/17 General Availability * The overall feature set is frozen. o No further JEPs will be targeted to this release o For more details , see Mark Reinhold's email to jdk-dev mailing list [1] * Features included in JDK 14:. o JEP 305: Pattern Matching for instanceof (Preview) <http://openjdk.java.net/jeps/305> o JEP 343: Packaging Tool (Incubator) <http://openjdk.java.net/jeps/343> o JEP 345: NUMA-Aware Memory Allocation for G1 <http://openjdk.java.net/jeps/345> o JEP 349: JFR Event Streaming <http://openjdk.java.net/jeps/349> o JEP 352: Non-Volatile Mapped Byte Buffers <http://openjdk.java.net/jeps/352> o JEP 358: Helpful NullPointerExceptions <https://openjdk.java.net/jeps/358> o JEP 359: Records (Preview) <http://openjdk.java.net/jeps/359> JEP 359: Records (Preview) <http://openjdk.java.net/jeps/359> o JEP 361: Switch Expressions (Standard) <http://openjdk.java.net/jeps/361> o JEP 362: Deprecate the Solaris and SPARC Ports <https://openjdk.java.net/jeps/362> o JEP 363: Remove the Concurrent Mark Sweep Garbage Collector <http://openjdk.java.net/jeps/363> o JEP 364: ZGC on macOS <http://openjdk.java.net/jeps/364> o JEP 365 ZGC on Windows <https://openjdk.java.net/jeps/365> o JEP 366: Deprecate ParallelScavenge SerialOld GC Combination <http://openjdk.java.net/jeps/366> o JEP 367: Remove the Pack200 Tools and API <http://openjdk.java.net/jeps/367> o JEP 368: Text Blocks (Second Preview) <http://openjdk.java.net/jeps/368> o JEP 370: Foreign-Memory Access API (Incubator) <https://openjdk.java.net/jeps/370> *JDK 14 **Early Access build 27 **is available**at : - jdk.java.net/14/* * Release notes o https://jdk.java.net/14/release-notes * Recent fixes that might be of interest o Build 27: + JDK-8212780: Packaging Tool Implementation + JDK-8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports + JDK-8190492: Remove SSLv2Hello and SSLv3 from default enabled TLS protocols + JDK-8214481: freetype path does not disable TrueType hinting with AA+FM hints + JDK-8234076: JVM crashes on Windows 10 using --module=NAME + JDK-8222756: Plural support in CompactNumberFormat + JDK-8234211: allow discoverable javac plugins to be invoked by default o Build 26: + JDK-8233223: Add Amazon Root CA certificates + JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions + JDK-8234893: ARM32: build failure after JDK-8234387 Rgds, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003795.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[qos-ch/slf4j] 2ac2e8: minor refactoring, docs
by Ceki Gulcu 10 Dec '19

10 Dec '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 2ac2e807ea498524fc946baae1fde94b3552435c https://github.com/qos-ch/slf4j/commit/2ac2e807ea498524fc946baae1fde94b3552… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-12-10 (Tue, 10 Dec 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/LoggerFactory.java M slf4j-api/src/test/java/org/slf4j/NoBindingMultithreadedInitializationTest.java M slf4j-api/src/test/java/org/slf4j/testHarness/MultithreadedInitializationTest.java Log Message: ----------- minor refactoring, docs

1 0

[qos-ch/slf4j] 27358d: Fix NOP fallback memory leak
by Ceki Gulcu 10 Dec '19

10 Dec '19

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 27358d395c8b1f47a9c13ca47bbff33e75dd1fa3 https://github.com/qos-ch/slf4j/commit/27358d395c8b1f47a9c13ca47bbff33e75dd… Author: David Harsha <davishmcclurg(a)gmail.com> Date: 2019-12-09 (Mon, 09 Dec 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/LoggerFactory.java A slf4j-api/src/test/java/org/slf4j/NoBindingMultithreadedInitializationTest.java M slf4j-api/src/test/java/org/slf4j/testHarness/MultithreadedInitializationTest.java Log Message: ----------- Fix NOP fallback memory leak Substitute loggers are not getting "fixed" when no SLF4J provider is found, which means `SUBST_PROVIDER` will add messages to its `LinkedBlockingQueue` until the process runs out of memory. `NoBindingMultithreadedInitializationTest` doesn't contain any assertions of its own because `MultithreadedInitializationTest` already asserts loggers are fixed in `assertAllSubstLoggersAreFixed`. https://jira.qos.ch/browse/SLF4J-469 Commit: 306d8fd23d89b0ad510172c7a15d10175efe691d https://github.com/qos-ch/slf4j/commit/306d8fd23d89b0ad510172c7a15d10175efe… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2019-12-10 (Tue, 10 Dec 2019) Changed paths: M slf4j-api/src/main/java/org/slf4j/LoggerFactory.java A slf4j-api/src/test/java/org/slf4j/NoBindingMultithreadedInitializationTest.java M slf4j-api/src/test/java/org/slf4j/testHarness/MultithreadedInitializationTest.java Log Message: ----------- Merge pull request #228 from davishmcclurg/SLF4J-469 Fix NOP fallback memory leak Compare: https://github.com/qos-ch/slf4j/compare/9a3f1f4928ab...306d8fd23d89

1 0

[JIRA] (SLF4J-469) Potential memory leaks if there is no underlying implementation
by QOS.CH (JIRA) 10 Dec '19

10 Dec '19

[ https://jira.qos.ch/browse/SLF4J-469?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-469: ---------------------------------- [PR 228| https://github.com/qos-ch/slf4j/pull/228] looks very good. > Potential memory leaks if there is no underlying implementation > --------------------------------------------------------------- > > Key: SLF4J-469 > URL: https://jira.qos.ch/browse/SLF4J-469 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.7.26 > Environment: java 8 > slf4j 1.7.26 > > Reporter: yu > Assignee: Ceki Gülcü > Priority: Critical > Labels: logging, substitution > Fix For: 2.0.0-alpha2, 1.7.29 > > > > *If I don't have 'logback' 'log4j'...... Implementation class* > The problem lies in the method > *public static ILoggerFactory getILoggerFactory()* > first Thread1: > {code:java} > if (INITIALIZATION_STATE == UNINITIALIZED) { > init..... > } > {code} > secode Thread2: > {code:java} > case ONGOING_INITIALIZATION: > return SUBST_FACTORY;{code} > obtained "SUBST_FACTORY"， > and obtained "SubstituteLogger" > > third: > Thread1: > {code:java} > //init failed cache "NoClassDefFoundError" > INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION; > {code} > *The SubstituteLogger obtained by Thread2 will always output the log to the queue until the memory overflows.* > {code:java} > // code placeholder > synchronized public Logger getLogger(String name) { > SubstituteLogger logger = loggers.get(name); > if (logger == null) { > logger = new SubstituteLogger(name, eventQueue, postInitialization); > loggers.put(name, logger); > } > return logger; > } > public void info(String msg) { > delegate().info(msg); > } > Logger delegate() { > if(_delegate != null) { //_delegate== null forever > return _delegate; > } > if(createdPostInitialization) { createdPostInitialization == false forever > return NOPLogger.NOP_LOGGER; > } else { > return getEventRecordingLogger(); > } > } > {code} > > > > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 14 - Early Access build 25 is available
by Rory O'Donnell 29 Nov '19

29 Nov '19

Hi Ceki, *OpenJDK builds - JDK 14 *- Early Access build 25 is available at http://jdk.java.net/14/ 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>. * *Next Milestone* ** o ** *12-Dec-2019 Rampdown Phase One.* * Release notes o https://jdk.java.net/14/release-notes * JEP proposed to target JDK 14 o JEP 365 ZGC on Windows <https://openjdk.java.net/jeps/365> * JEPs targeted to JDK 14, so far: o JEP 305: Pattern Matching for instanceof (Preview) <http://openjdk.java.net/jeps/305> was proposed to target. o JEP 343: Packaging Tool (Incubator) <http://openjdk.java.net/jeps/343> was proposed to target. o JEP 345: NUMA-Aware Memory Allocation for G1 <http://openjdk.java.net/jeps/345> was integrated. o JEP 349: JFR Event Streaming <http://openjdk.java.net/jeps/349> was integrated. o JEP 352: Non-Volatile Mapped Byte Buffers <http://openjdk.java.net/jeps/352> was targeted. o JEP 358: Helpful NullPointerExceptions <https://openjdk.java.net/jeps/358> was integrated. o JEP 359: Records (Preview) <http://openjdk.java.net/jeps/359> JEP 359: Records (Preview) <http://openjdk.java.net/jeps/359> was proposed to target. o JEP 361: Switch Expressions (Standard) <http://openjdk.java.net/jeps/361> was intergrated. o JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector <http://openjdk.java.net/jeps/363> was targeted. o JEP 364: ZGC on macOS <http://openjdk.java.net/jeps/364> was targeted. o JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination <http://openjdk.java.net/jeps/366> was proposed to target. o JEP 367: Remove the Pack200 Tools and API <http://openjdk.java.net/jeps/367> was targeted to JDK 14. o JEP 368: Text Blocks (Second Preview) <http://openjdk.java.net/jeps/368> was proposed to target. * Recent Bug fixes of Interest * Build 25: o JDK-8233301: Implementation of JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination o JDK-8233296: The behavior of MulticastSocket getOption/setOption for IP_MULTICAST_LOOP is changed to conform the specification of StandardSocketOptions.IP_MULTICAST_LOOP * Build 24: o JDK-8233141 :DatagramSocket.send and MulticastSocket.send throw IllegalArgumentException when the socket is not connected and the packet doesn't contain any address ) o JDK-8214024: Remove the default keytool -keyalg value o JDK-8232019: Add LuxTrust certificate updates to the existing root program * Build 23 o JDK 8232365: Implementation for JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector o JDK 8224817: Implementation of JEP 364: ZGC on macOS * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B24%22%3A%3…> *jpackage EA -* Build 14-jpackage+1-70 (2019/11/12) * 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. * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html> * Build is now available http://jdk.java.net/jpackage/ * Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> Rgds,Rory** ** -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (SLF4J-477) Add New Exception for Stack Trace Dumps
by QOS.CH (JIRA) 22 Nov '19

22 Nov '19

[ https://jira.qos.ch/browse/SLF4J-477?page=com.atlassian.jira.plugin.system.… ] DAVID MOLLITOR commented on SLF4J-477: -------------------------------------- Alternatively, provide some sort of static token or marker that produces a stack trace so that the stack trace is only collected if the logging level is enabled. > Add New Exception for Stack Trace Dumps > --------------------------------------- > > Key: SLF4J-477 > URL: https://jira.qos.ch/browse/SLF4J-477 > Project: SLF4J > Issue Type: New Feature > Reporter: DAVID MOLLITOR > Assignee: SLF4J developers list > > I have seen many examples where developers want to dump a stack trace to the log system simply to track the execution path of the Thread and not associated with any real issue. > {code:java} > LOG.trace("Stack Trace Dump", new Exception()); > {code} > The output is something like: > {code:none} > 2019-11-19T08:13:31,392 TRACE [Logger] Class: Stack Trace Dump > java.lang.Exception: null > at > ... > {code} > > I would like to propose that SLF4J ships with an {{Exception}} class specific to this scenario. A user could easily mistake this as logging as being related to a real error condition instead of its intended informational purpose because it has the word 'Exception' in it and may be interpreted as being related to an erroneous 'null' value. > > {code:java} > LOG.trace("Stack Trace Dump", new StackTraceDump()); > 2019-11-19T08:13:31,392 TRACE [Logger] Class: Stack Trace Dump > ch.qos.slf4f.StackTraceDump: Dumping stack trace > at > ... > {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-477) Add New Exception for Stack Trace Dumps
by QOS.CH (JIRA) 20 Nov '19

20 Nov '19

DAVID MOLLITOR created SLF4J-477: ------------------------------------ Summary: Add New Exception for Stack Trace Dumps Key: SLF4J-477 URL: https://jira.qos.ch/browse/SLF4J-477 Project: SLF4J Issue Type: New Feature Environment: I have seen many examples where developers want to dump a stack trace to the log system simply to track the execution path of the Thread and not associated with any real issue. {code:java} LOG.trace("Stack Trace Dump", new Exception()); {code} The output is something like: {code:none} 2019-11-19T08:13:31,392 TRACE [Logger] Class: Stack Trace Dump java.lang.Exception: null at ... {code} I would like to propose that SLF4J ships with an {{Exception}} class specific to this scenario. A user could easily mistake this as logging as being related to a real error condition instead of its intended informational purpose because it has the word 'Exception' in it and may be interpreted as being related to an erroneous 'null' value. {code:java} LOG.trace("Stack Trace Dump", new StackTraceDump()); 2019-11-19T08:13:31,392 TRACE [Logger] Class: Stack Trace Dump ch.qos.slf4f.StackTraceDump: Dumping stack trace at ... {code} Reporter: DAVID MOLLITOR Assignee: SLF4J developers list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0