Hello² In Pax Logging 1.10.x it's not that good.
- org.ops4j.pax.logging.log4jv2.Log4jv2Logger - 10001 instances - ok - org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl - 10010 instances - ok - org.apache.logging.log4j.core.Logger - 10010 instances - ok - org.ops4j.pax.logging.internal.TrackingLogger - 60011 instances - ok - org.apache.log4j.logger - 185599 instances - not ok - org.ops4j.pax.logging.avalon.AvalongLogger - 185599 instances - not ok - org.apache.commons.logging.internal.JclLogger - 185600 instances - not ok - org.apache.juli.logging.internal.JuliLogger - 185600 instances - not ok SLF4J, JBossLogging seems to be properly GCed. Log4j2 loggers are ok. Log4j1, Avalon, JCL and JULI are broken in Pax Logging 1.10.x Checking your patches now ;) regards Grzegorz Grzybek pon., 4 maj 2020 o 08:02 Grzegorz Grzybek <[email protected]> napisał(a): > Hello > > FYI, I've changed the memory tests to do logging via 7 "frontends" for > each of 3 "backends". These frontends are: > > org.slf4j.Logger slf4jLogger = org.slf4j.LoggerFactory.getLogger(name); > slf4jLogger.trace("TRACE through SLF4J"); > > org.apache.commons.logging.Log commonsLogger = > org.apache.commons.logging.LogFactory.getLog(name); > commonsLogger.trace("TRACE through Apache Commons Logging"); > > org.apache.juli.logging.Log juliLogger = > org.apache.juli.logging.LogFactory.getLog(name); > juliLogger.trace("TRACE through JULI Logging"); > > org.apache.avalon.framework.logger.Logger avalonLogger = > org.ops4j.pax.logging.avalon.AvalonLogFactory.getLogger(name); > avalonLogger.debug("DEBUG through Avalon Logger API"); > > org.jboss.logging.Logger jbossLogger = > org.jboss.logging.Logger.getLogger(name); > jbossLogger.trace("TRACE through JBoss Logging Logger API"); > > org.apache.log4j.Logger log4j1Logger = > org.apache.log4j.Logger.getLogger(name); > log4j1Logger.trace("TRACE through Log41 v2 API"); > > org.apache.logging.log4j.Logger log4j2Logger = > org.apache.logging.log4j.LogManager.getLogger(name); > log4j2Logger.trace("TRACE through Log4J v2 API"); > > Tests with -Xmx64M run like this: > > [INFO] Running org.ops4j.pax.logging.it.Log4J1MemoryIntegrationTest > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 65.928 s - in org.ops4j.pax.logging.it.Log4J1MemoryIntegrationTest > [INFO] Running org.ops4j.pax.logging.it.Log4J2MemoryIntegrationTest > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 73.524 s - in org.ops4j.pax.logging.it.Log4J2MemoryIntegrationTest > [INFO] Running org.ops4j.pax.logging.it.LogbackMemoryIntegrationTest > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 68.748 s - in org.ops4j.pax.logging.it.LogbackMemoryIntegrationTest > > and in memory dump I saw exactly 70016 instances of PaxLoggerImpl and > TrackingLogger - which perfectly match what I wanted to achieve with 2.0.x > and 1.11.x > > Now I'll check these tests with 1.10.x. > > regards > Grzegorz Grzybek > > śr., 22 kwi 2020 o 06:46 Grzegorz Grzybek <[email protected]> > napisał(a): > >> Thanks! Definitely I'll use these patches to fix it in the project. >> >> regards and stay healthy! >> Grzegorz Grzybek >> >> wt., 21 kwi 2020 o 14:30 Monica Ron <[email protected]> napisał(a): >> >>> Thanks. I decided to change my approach. I am not using the previous >>> patch anymore. >>> >>> I patched the ThreadContext (based on PAXLOGGING-244), reworked my code >>> to use the ThreadContext instead of modifying the logger name, and also >>> made some changes to the pax-logging-api to fix some of the leak issues and >>> to address inconsistencies between the various logging implementations. For >>> my pax-logging-api changes, some of it follows what was done in the 1.11.x >>> branch for PAXLOGGING-307. I no longer swap the order of the WeakHashMap >>> parameters back to the original <Logger, String>. My patch keeps it with >>> the new <String, Logger> parameters, but does not store Logger >>> implementations in the map if the Pax Logging Manager is already created >>> (as mentioned earlier, SLF4J already had this check, but Log4J1 did not). >>> >>> I attached my two patches and the instructions I wrote so that my >>> teammates could build the new jars. Feel free to use them or modify them as >>> needed. >>> >>> Monica >>> >>> >>> On Tuesday, April 21, 2020 at 2:48:57 AM UTC-4, Grzegorz Grzybek wrote: >>>> >>>> Hello >>>> >>>> Sorry for big delay... I still remember about this issue and I think I >>>> can do something about it soon. Just a little bit patience please ;) >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> śr., 18 mar 2020 o 22:47 Monica Ron <[email protected]> napisał(a): >>>> >>>>> I have a test that shows my groups usage. Should I just attach it as a >>>>> part of a post to this forum? It definitely behaves differently with the >>>>> 1.10.5 vs. with my patch, with regards to how many logger instances get >>>>> stored in m_loggers (especially if I use Log4J1 vs. Log4J2 as my API). >>>>> >>>>> I use the Log4J2 API in my real code, as I've stated before (but >>>>> third-party code we use uses SLF4J or JCL, and maybe others). I tried to >>>>> use the ThreadContext in my code (instead of the Markers that Ralph >>>>> mentioned), and ran into trouble, because I ran into the problem described >>>>> in https://ops4j1.jira.com/browse/PAXLOGGING-244 , for which the fix >>>>> was not applied to the 1.10.5 branch. Once I backported that fix to the >>>>> 1.10.5 branch (making a new pax-logging-api and new pax-logging-log4j2, >>>>> the >>>>> ThreadContext worked, and I could re-use logger names and still see which >>>>> "group" my log statements were from. >>>>> >>>>> Even if I change my code to use ThreadContext, the memory behavior of >>>>> 1.10.5 with regards to m_loggers is still a leak compared to the old 1.6.1 >>>>> we were using, as I have been stating all along. >>>>> >>>>> I think the inconsistencies with regard to the following two items >>>>> (mentioned in my previous post) is also an issue: >>>>> 1. storing values in the m_loggers maps when m_paxLogging is non-null ( >>>>> *only* SLF4J API in pax-logging-api 1.10.5 does **not** store it if >>>>> m_paxLogging is non-null), and >>>>> 2. getting a new logger even if a name is reused vs. re-using the old >>>>> logger (*only* Log4J2 API in pax-logging-api 1.10.5 reuses the logger >>>>> if the name was already used--other implementations just keep creating new >>>>> loggers for the same name, and store all of those loggers in m_loggers) >>>>> >>>>> Because of #1 and #2, if I was using Log4J1 API in pax-logging-api >>>>> 1.10.5, then even if I re-used the name for a non-static logger, the >>>>> m_loggers just keeps growing. At least with Log4J2, if I re-use the name >>>>> for a non-static logger, the m_loggers does not grow. >>>>> >>>>> Thanks again, >>>>> Monica >>>>> >>>>> -- >>>>> -- >>>>> ------------------ >>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OPS4J" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/ops4j/e6783b83-bc0c-4d98-aae3-d28e72949c2b%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/ops4j/e6783b83-bc0c-4d98-aae3-d28e72949c2b%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> -- >>> ------------------ >>> OPS4J - http://www.ops4j.org - [email protected] >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OPS4J" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ops4j/60e642dd-33d3-4249-beb4-87d2b65d7944%40googlegroups.com >>> <https://groups.google.com/d/msgid/ops4j/60e642dd-33d3-4249-beb4-87d2b65d7944%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhrNbC-kcnS%2BYAJDCyZ0%3DyqXy5XsTbWA4w6gwxm%2Bf%2BYppg%40mail.gmail.com.
