Hello³ And finally - many many thanks for your patch! I'm grateful because after applying your patch without changes, my Memory tests (extended to cover all remaining logging APIs/facades) pass without memory leaks on -Xmx64m.
The change is: https://github.com/ops4j/org.ops4j.pax.logging/commit/665cf32d53c9c0ea3316b9ab15a36a909bac78ad Now the last thing is - if you want a release 1.10.6, just let me know. kind regards Grzegorz Grzybek pon., 4 maj 2020 o 08:43 Grzegorz Grzybek <[email protected]> napisał(a): > 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/CAAdXmhqvo%2BYvhogRSoM9oD1ptGb3PT6fU-XHy7qSQpn9hZ1jMg%40mail.gmail.com.
