Hello,
I have an application in which I'm using all async loggers. When I stop the
LoggerContext, there're still some events waiting in disruptor's buffer and
when it tries to execute them the context is already closed and thus those
events are lost.
Is there some kind of hook, callback or
/19, at 22:01, Mariano Gonzalez mariano.l.gonza...@gmail.com
wrote:
Hello,
I have an application in which I'm using all async loggers. When I stop
the
LoggerContext, there're still some events waiting in disruptor's buffer
and
when it tries to execute them the context is already closed
Hello,
I've been taking a look at LoggerContext#stop() and for what I see there's
code to prevent disruptor to take new messages but there's nothing making
sure that the ring buffer is empty before actually closing up.
I did a simple test with an Appender wrapper like this:
final class
Hello,
I'm progamatically creating an appender with the following code:
private static final String PATTERN_LAYOUT = %-5p %d [%t] %c: %m%n;
private RollingFileAppender createRollingFileAppender(String logFilePath,
String filePattern, String appenderName, Configuration configuration)
{
, Dec 2, 2014 at 12:57 PM, Gary Gregory garydgreg...@gmail.com
wrote:
Can you try version 2.1?
Gary
On Tue, Dec 2, 2014 at 12:46 PM, Mariano Gonzalez
mariano.l.gonza...@gmail.com wrote:
Hello,
I'm progamatically creating an appender with the following code:
private static
forever.
That part of the code was probably changed as part of fixing LOG4J2-832.
Gary
On Tue, Dec 2, 2014 at 1:16 PM, Mariano Gonzalez
mariano.l.gonza...@gmail.com wrote:
Hello Gary,
Thank you for your response. 2.1 does fix the issue, is it mandatory to
upgrade? was it a logic error
Hello,
Could you explain what's the purpose of this thread? It seems to keep on
running when my application is undeployed.
I looked at the code and it seems to be a thread responsible for
dispatching events to Disruptor, but if that's the case then the name may
not be very descriptive IMHO. Can
:
The built-in rollover only moves/renames but never deletes files. (We
actually have outstanding enhancement request to add some auto-delete
function.)
Sent from my iPhone
On 2014/07/31, at 4:30, Mariano Gonzalez mariano.l.gonza...@gmail.com
wrote:
Hello,
I'm configuring
.
Feel free to submit a patch.
Gary
div Original message /divdivFrom: Mariano
Gonzalez
mariano.l.gonza...@gmail.com /divdivDate:07/22/2014 11:18
(GMT-05:00) /divdivTo: Log4J Users List
log4j-user@logging.apache.org /divdivSubject: Disruptor 3.2.x
/divdiv
Hello,
According to the manual, async loggers require Disruptor 3.0. However, the
3.2.x series of disruptor is available. Have you tried this version? Are
you recommending 3.0 because you found issues with other versions or is it
just in your TODO list to give 3.2 a ride and/or update the manual?
loggers?
On Sun, Jul 20, 2014 at 7:45 AM, Mariano Gonzalez
mariano.l.gonza...@gmail.com wrote:
Hello Remko,
Thanks for the insight. I guess my case falls into the wrong end of the
pareto law. My project is a low latency application container, so I need
to
have:
- low latency
flavors of Async Loggers in your application?
On Mon, Jul 21, 2014 at 11:10 PM, Mariano Gonzalez
mariano.l.gonza...@gmail.com wrote:
Hello Remko,
I think I found the difference. AsyncLoggerContextSelector always returns
the same instance of AsyncLoggerContext, which in turns always
registry that can be looked up dynamically
such as through reflection of the caller stack and other fun design
problems. :)
On 21 July 2014 09:35, Mariano Gonzalez mariano.l.gonza...@gmail.com
wrote:
Hello Remko,
I'm still a couple of days away from starting my own performance
:57 PM, Mariano Gonzalez
mariano.l.gonza...@gmail.com wrote:
Hello,
According to the performance charts in the documentation, log4j2 has a
significantly higher throughput when using AsyncLoggerContextSelector
than
when using all async loggers with any different selector.
Why
Hello,
According to the performance charts in the documentation, log4j2 has a
significantly higher throughput when using AsyncLoggerContextSelector than
when using all async loggers with any different selector.
Why is that? Is it just because the same context is always reused and
there's no
Hello all,
I'm part of the development team of a popular middleware product that acts
as an application container. I'm working in moving from log4j 1.2 to 2.0
for our next release.
We noticed that most of our users use a log4j.properties file to configure
logging in their applications. To make
16 matches
Mail list logo
