Hello again Without waiting, I've just released pax-logging 1.10.6 version - I hope it'll solve all your (Monica Ron) problems ;)
regards Grzegorz Grzybek pon., 4 maj 2020 o 09:10 Grzegorz Grzybek <[email protected]> napisał(a): > 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/CAAdXmhr2H_PvGJPSHJU%2B0k8NoV9aWbvGdowQcrWio%2Bdks%3DgE6w%40mail.gmail.com.
