Hi Grzegorz, Pax Logging 1.11.x is not impacted ?
Regards JB On Mon, May 4, 2020 at 10:40 AM Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: > 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 <gr.grzy...@gmail.com> > 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 <gr.grzy...@gmail.com> >> 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 <gr.grzy...@gmail.com> >>> 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 <gr.grzy...@gmail.com> >>>> 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 <monica...@gmail.com> 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 <moni...@gmail.com> 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 - op...@googlegroups.com >>>>>>>> >>>>>>>> --- >>>>>>>> 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 op...@googlegroups.com. >>>>>>>> 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 - ops4j@googlegroups.com >>>>>> >>>>>> --- >>>>>> 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 ops4j+unsubscr...@googlegroups.com. >>>>>> 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 - ops4j@googlegroups.com > > --- > 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 ops4j+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/CAAdXmhr2H_PvGJPSHJU%2B0k8NoV9aWbvGdowQcrWio%2Bdks%3DgE6w%40mail.gmail.com > <https://groups.google.com/d/msgid/ops4j/CAAdXmhr2H_PvGJPSHJU%2B0k8NoV9aWbvGdowQcrWio%2Bdks%3DgE6w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- 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 ops4j+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAB8EV3RqgmqJEu5tCgiWVK%3Dk6ejcqvWtvTTdTiK%2BveRuLtQEYA%40mail.gmail.com.
