Hello
I've updated PAXLOGGING-244 issue and I'm just releasing pax-logging 1.10.7.
regards
Grzegorz Grzybek
wt., 5 maj 2020 o 21:13 Monica Ron napisał(a):
> Hi. The new checkin looks much better, and matches what I have from my
> patch.
>
> Please go ahead and release 1.10.7 with the updated
Hi. The new checkin looks much better, and matches what I have from my
patch.
Please go ahead and release 1.10.7 with the updated code. You might want to
mention in the Release Notes that PAXLOGGING-244 (the ThreadContext
problem) is now fixed on the 1.10.x branch (and/or update the "Fix
Hello again ;)
Thanks for detailed check! I confess - I wasn't able to do `git apply <
xxx.patch`, so I did it manually and:
- I forgot about changing the clear() to removal of "bundle.*" entries
- I didn't notice double put()
This time I did 2nd review and here's the result:
Hi.
I very much appreciate the update and the new release. Thank you. I'm glad
that the memory leak patch helped and that you could see from your updated
tests what I had seen regarding leaks.
*I hate to tell you this, but you'll need to make some fixes and release
1.10.x again.*
*First*, you
Good, thanks for the update.
Regards
JB
On Mon, May 4, 2020 at 10:43 AM Grzegorz Grzybek
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 ==
>
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
Hi Grzegorz,
Pax Logging 1.11.x is not impacted ?
Regards
JB
On Mon, May 4, 2020 at 10:40 AM Grzegorz Grzybek
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
>
>
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 napisał(a):
> Hello³
>
> And finally - many many thanks for your patch! I'm grateful because
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:
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
-
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 =
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 napisał(a):
> Thanks. I decided to change my approach. I am not using the previous patch
> anymore.
>
> I patched the ThreadContext (based on
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
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 napisał(a):
> I have a test that shows my groups usage. Should I just attach it as 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
It took me some time to figure out how to run the tests. For one thing, it
didn't like the fact that I wasn't using the default repository (I wasn't
using .m2/repository in my home directory). Eventually, I got it working by
using that default repository.
Anyway, I'm still working on writing a
Hello again
I've backported 3 "memory" tests from Pax Logging 1.11.x to
https://github.com/ops4j/org.ops4j.pax.logging/commits/pax-logging-1.10.x
The test (e.g., org.ops4j.pax.logging.it.Log4J2MemoryTest) does this:
@Test
public void memoryIssues() throws IOException {
LOG.info("Starting");
Thanks for the additional information.
We use pax-logging-log4j2-1.10.5.jar for the backend. I believe I did see
in my previous heap analysis investigations that the Log4J2
(pax-logging-log4j2-1.10.5.jar) was holding onto references as you
described, but my patch to pax-logging-api at least
Hello again
After little more investigation and careful usage of WeakHashMaps and
WeakReferences I managed to create 1M of unique loggers on -Xmx128M that
were correctly garbage collected in:
- pax-logging-log4j1
- pax-logging-log4j2 (after fixing the problem described in
Unfortunately I don't think there's much we can do...
http://logging.apache.org/log4j/2.x/manual/usage.html#StaticVsNonStatic
says:
*Once a Logger is created it will not be deleted until the LoggerContext it
> is associated with is deleted. Typically, this will only happen when the
> application
I've created https://ops4j1.jira.com/browse/PAXLOGGING-311 and I'm checking
it.
But simple switching org.ops4j.pax.logging.OSGIPaxLoggingManager#m_loggers
to WeakHashMap gave me OOME where the problem was not the order of
key-value in the map (TrackingLoggers were correctly disposed, as well as
I'm glad you can see what I saw. :)
I attached my patch to this post. I first downloaded the 1.10.x branch, and
made changes. The patch is the output from 'git diff'. To build what I have
using this patch, you can do the following:
git init
git remote add origin
Hello
I did simple test:
@Test
public void memoryIssues() throws IOException {
for (int i = 0; i < 1_000_000; i++) {
new MyClass().run();
}
LOG.info("Done");
}
private static class MyClass {
private Logger nonStaticLogger = LoggerFactory.getLogger(
Hello
Great analysis - as always. I'll have a look very soon!
regards
Grzegorz Grzybek
śr., 11 mar 2020 o 16:39 Monica Ron napisał(a):
> Hi. I know it's been a while since this was last sent. The change in order
> of the generic parameters of the WeakHashMap definitely caused a change in
>
Hello
sob., 4 sty 2020 o 02:58 Monica Ron napisał(a):
> The new code works for me. Once we deploy our wars, we don't generally
> re-deploy until we have a new release, and we usually shutdown the
> Glassfish/Payara domain to do that deployment. So, shutting down the JVM
> obviously clears all
The new code works for me. Once we deploy our wars, we don't generally
re-deploy until we have a new release, and we usually shutdown the
Glassfish/Payara domain to do that deployment. So, shutting down the JVM
obviously clears all memory.
I'm not really worried (I think our code should be
You're welcome. And maybe if we had kept our code and dependencies
up-to-date, the problem would have been noted 4 years ago when the "adding
generics" change was first made. ;)
Monica
On Friday, January 3, 2020 at 10:50:46 AM UTC-5, Grzegorz Grzybek wrote:
>
> Hello
>
> I'm glad it worked!
>
Hello
I'm glad it worked!
*Thank you very much. I spent many hours trying to figure out what was
> wrong with my updated POM files and Payara5 deployment before I finally
> realized that the problem was with Pax Logging, not with my own code. I am
> glad you were able to fix this and make a new
I downloaded the pax-logging-api-1.10.5.jar and
pax-logging-log4j2-1.10.5.jar from Maven Central, and deployed them in my
Payara glassfish/modules/autostart directory.
Now when I start Payara with the wars already deployed, it is properly
connecting to the pax-logging, and is respecting my
Hello Monica
I've fixed https://ops4j1.jira.com/browse/PAXLOGGING-307 and while
pax-logging 1.11.x and 2.0.x have proper tests, there are no such tests in
1.10.x. And also 1.10.x is not the version I was refactoring. So - may I
ask you kindly to check
Just checked new integration tests for 1.11.5-SNAPSHOT and 2.0.0-SNAPSHOT -
all is fine.
So I'm backporting this change to pax-logging 1.10.x (without tests...)
regards
Grzegorz Grzybek
czw., 2 sty 2020 o 17:42 Monica Ron napisał(a):
> I am glad you were able to reproduce the issue and see
I am glad you were able to reproduce the issue and see what I meant.
Yes, please backport the fix to 1.10.x. I tried the fix for PAXLOGGING-306
for getting the pax-logging-log4j2 in the 1.10.x branch to print stack
traces, and it worked--my stack traces were printed correctly. So, if this
Hello
Thanks for describing the problem in such details!
I reproduced the problem and indeed - simple:
Logger log1a = LoggerFactory.getLogger(this.getClass());
Logger log1b = LoggerFactory.getLogger(this.getClass());
(getting same logger twice), when pax-logging-api is not yet started gives
me
Hello
I created https://ops4j1.jira.com/browse/PAXLOGGING-307 to track this issue.
regards
Grzegorz Grzybek
pon., 9 gru 2019 o 22:35 Monica Ron napisał(a):
> Thanks. If you do change the code to fix my problem (e.g., swap order of
> the generic parameters, or whatever other way you fix it), I
Thanks. If you do change the code to fix my problem (e.g., swap order of
the generic parameters, or whatever other way you fix it), I hope you can
release a 1.10.x as well as fixing it on the newer 1.11.x, since I can't
use 1.11.x yet.
I can't even use 1.10.4, as I'm having trouble with a
Hello
Thank you for this analysis - you are correct.
The goal of removing map-per-logging facade was to unify logging behavior
and allowing two bundles to use two different loggers with the same name
(though now I think the problem was caused by this generification you've
mentioned).
There's
I got the tests to run, but I am still working on modifying them to
illustrate my problem. It is clear to me from studying the pax logging code
and observing its behavior that having the m_loggers maps (whether per
logging API or as a single global map) with key=name and value=logger is
wrong,
Hello
I'll run into the same issue I saw with the actual 1.10.4. When a second
> logger is registered in that global map with a name that already exists,
> the first logger will be lost
>
This was a case with previous (than 1.11.x) versions too and there was
respective PAXLOGGING issue for this:
Thanks.
I will write a bug in PAXLOGGING soon.
Version 1.11.3 doesn't run on Payara 5.192 (different OSGi version,
maybe?). Version 1.10.4 runs, but has the same issue I reported. I
downloaded 1.10.4 and swapped the order of the generic parameters to match
the original code (i.e., I made
Hello
I can't speak for this particular commit.
I can only try suggesting 1.11.3 version where I've done major refactoring.
See https://ops4j1.jira.com/browse/PAXLOGGING-252 for the issue and for new
and improved (IMHO) documentation:
40 matches
Mail list logo
