Good, thanks for the update. Regards JB
On Mon, May 4, 2020 at 10:43 AM Grzegorz Grzybek <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/ops4j/CAAdXmhoYZpbcW5jZg0FCqr4SSKNhA%2B-_SeCLERVrHw0S64tNNQ%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/CAB8EV3SrctYkysL6K4qtNqTH%2BNJdOYNhsSPi1ssC6cTjDJqjNA%40mail.gmail.com.
