Hello Nope, it's not. Though I've enhanced the memory-related tests. And I'll prepare new 1.11.x/2.0.x releases too, because of https://ops4j1.jira.com/browse/PAXLOGGING-312 == https://issues.apache.org/jira/browse/LOG4J2-2819 == CVE-2020-9488 soon.
regards Grzegorz Grzybek pon., 4 maj 2020 o 10:41 Jean-Baptiste Onofré <[email protected]> napisał(a): > Hi Grzegorz, > > Pax Logging 1.11.x is not impacted ? > > Regards > JB > > On Mon, May 4, 2020 at 10:40 AM Grzegorz Grzybek <[email protected]> > 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 <[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 >> <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 - [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/CAB8EV3RqgmqJEu5tCgiWVK%3Dk6ejcqvWtvTTdTiK%2BveRuLtQEYA%40mail.gmail.com > <https://groups.google.com/d/msgid/ops4j/CAB8EV3RqgmqJEu5tCgiWVK%3Dk6ejcqvWtvTTdTiK%2BveRuLtQEYA%40mail.gmail.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/CAAdXmhoYZpbcW5jZg0FCqr4SSKNhA%2B-_SeCLERVrHw0S64tNNQ%40mail.gmail.com.
