There are JVM properties to reduce both the number of slot of the ring
buffer, and the maximum size of the StringBuilder used inside each slot.
Tuning these should help to lower the extra memory footprint. I don't
remember them (and cannot do the search right now) but they are documented
on log4j
des valuable and
> expected information.
>
> Best,
> -Carter
>
> On Mon, Mar 15, 2021, at 09:08, Anthony Maire wrote:
> > Hello
> >
> > The issue here is that you are trying to log from the thread. Since this
> > thread is the only one that consume event fr
Hello
The issue here is that you are trying to log from the thread. Since this
thread is the only one that consume event from the disruptor, is the buffer
is full, it deadlocks itself.
It is not really a disruptor bug, it is an inappropriate usage of it which
leads to this behavior.
In this threa
Hi John
If you have this stack trace in the threads that are producing messages,
then your disruptor is full because the appender is not capable of writing
fast enough.
Since you have a single appender, it might be useful to switch
to RollingRandomAccessFileAppender which can batch writes to disc
d handle this but it is based on
> Quartz’ CronExpression which doesn’t support randomizing fields. I was
> confused because Jenkins supports this and I had thought it was using
> Quartz. Apparently not.
>
> Ralph
>
>
> > On Mar 24, 2017, at 10:15 AM, Anthony Maire
&
gh values to spread the rolling over a larger
amount of time. The available CPU is then quickly drain out. In my opinion,
it's better to configure the several rollings to be delayed, meaning that
JVM1 rolls at 12:00, JVM2 rolls at 12:01, ...
>>>
>>> Cheers, Dominik
>>>
https://issues.apache.org/jira/browse/LOG4J2-1855
https://github.com/apache/logging-log4j2/pull/68
Let me know if you want me to do some changes
Regards,
Anthony
2017-03-23 13:15 GMT+01:00 Anthony Maire :
> Ok, I will open a jira ticket and provide a PR.
>
> Thanks for your input.
o
> the randomization affects when the _sequence_ is triggered, not just one
> part of the sequence. Makes sense.
>
> Sent from my iPhone
>
> > On Mar 23, 2017, at 16:28, Anthony Maire
> wrote:
> >
> > Hi Remko
> >
> > My first idea was to have the rol
some property on the timed base
triggering policy and let that class handle all the logic and delay the
triggering itself instead of the compression.
Are you OK with that?
Anthony
Le 23 mars 2017 00:24, "Remko Popma" a écrit :
> On Mar 23, 2017, at 1:06, Anthony Maire wrote:
>
&
or you use case you could inject a
> > single thread executor, so only one thread is ever compressing at a time.
> >
> > Just a thought, anyway,
> >
> > Greg
> >
> > On 22 March 2017 at 13:47, Anthony Maire
> wrote:
> >
> >> Hi
> >&g
Hi
We are currently using another logging framework in production, but I'm
pushing to change it for log4j2.
One common issue we have with that framework (and I assume we can have the
same with log4j2) is that all of our JVMs (we can have more than 50 JVMs on
the same server in production) roll th
Another possible way to investigate is to wrap your RollingFile appender in
an Async appender. Since there is only one thread that outputs, if it is a
thread local related issue, it should disappear (and it may be use as a
workaround until the next release)
2016-07-02 16:10 GMT+02:00 Remko Popma :
In my opinion:
- rolling is an issue
- not using an OS-wide lock is an issue, because the behavior can be
OS-dependant and/or FS-dependant (NFS doesn't natively support append as
far as I know so it will be racy at least on NFS)
It can be possible to do a modified version of a standard appender th
I succeed to reproduce the issue I was suspecting to happen :
https://issues.apache.org/jira/browse/LOG4J2-1441
2016-06-17 15:11 GMT+02:00 Anthony Maire :
> Hello
>
> As suggested in AsyncLogger javadoc, I made some performance tests on my
> application with (Rolling)RandomAccessFi
Hello
As suggested in AsyncLogger javadoc, I made some performance tests on my
application with (Rolling)RandomAccessFile appenders configured with
immediateFlush = false to take advantage of the potential I/O batching, and
the results are very good :)
However I have a question about the flush on
egory :
> On Mon, Jun 13, 2016 at 9:51 PM, Anthony Maire
> wrote:
>
> > Basically you want a logging framework to have as little impact as
> possible
> > on the application. That's why the sleeping strategy is a good
> > general-purpose choice : no allocation, no loc
Basically you want a logging framework to have as little impact as possible
on the application. That's why the sleeping strategy is a good
general-purpose choice : no allocation, no lock for the application
threads, and a CPU consumption when "idle" that will stay pretty low on
most OS (it roughly
Done : https://issues.apache.org/jira/browse/LOG4J2-1421
2016-06-10 13:49 GMT+02:00 Remko Popma :
> I would prefer a Jira ticket because email quickly drops below the
> horizon...
>
> Sent from my iPhone
>
> > On 2016/06/10, at 17:02, Anthony Maire wrote:
> >
> >
meal is a bit tough.
>
> Ralph
>
> > On Jun 9, 2016, at 10:47 AM, Anthony Maire
> wrote:
> >
> > I made a simplified example (cf attached files)
> > My log4j2.xml starts with:
> >
> >
> > And my application main method with :
> &
Hello
I'm trying to test some custom filters/layout with an existing application.
When I use them in a dummy test application launched from eclipse,
everything if fine, they are correctly loaded if I specify a "packages"
property in the configuration
However, when packaging the plugin classes in
20 matches
Mail list logo
