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/CAAdXmhrEQb%2BRG8F1SAfpL6cLDHHaOi-tQAc4xE5MqYOQAmeotg%40mail.gmail.com.
