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/CAAdXmhrHcmzoadTz-a%2Bxm7x64bCC4zQ5ci0W8-GETktkuZH6NA%40mail.gmail.com.
