Hi,
What would be the best way to implement the following:
1. Always roll log file once on JVM startup (and only on JVM startup). - This
could be done with implementing another OnStartupTriggeringPolicy (the one from
2.6.1+ doesn't roll empty files anymore).
2. Log an entry in the new log file
of properties.
>
> Actually, the triggering policy could write to the file since it has access
> to the Manager.
>
> Ralph
>
>
>
> > On Jun 15, 2016, at 8:17 AM, Leon Finker wrote:
> >
> > Hi,
> >
> > What would be the best way to
Goers wrote:
> >
> > Yes, the drain method should write whatever is in the ByteBuffer to the
> file.
> >
> > Ralph
> >
> >> On Jun 15, 2016, at 9:34 AM, Leon Finker wrote:
> >>
> >> An option to roll even empty files would be great. Because
That would be nice. Also, I confirmed and drain(ByteBuffer) works in my
case.
On Jun 15, 2016 8:24 PM, "Remko Popma" wrote:
> Ralph, any objection to making the write methods public?
>
> Sent from my iPhone
>
> > On 2016/06/16, at 9:05, Leon Finker wrote:
> &
ite to the file since it has
> access to the Manager.
>
> Ralph
>
>
>
> > On Jun 15, 2016, at 8:17 AM, Leon Finker wrote:
> >
> > Hi,
> >
> > What would be the best way to implement the following:
> > 1. Always roll log file once on JVM startup (a
Hi,
Using log4j2 runtime args with 2.6.1:
-DAsyncLogger.RingBufferSize=512
-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
On CentOS 6.7 and Java 1.8.0_60.
We noticed that at some point the process has stopped logging to the log file
(during startup). When
This looks similar:
http://stackoverflow.com/questions/15543521/mixed-usage-of-log4j-and-commons-logging-causes-a-class-loading-deadlock
But we don't use any other logging framework besides slf4j, log4j2 and log4j2
bridges.
On 2016-07-05 15:14 (-0400), "Leon Finker" wrote:
&
y that you are logging an exception. But I donât know why you
> > would be getting stuck in there. While formatting the exception is slow, it
> > shouldnât be that slow.
> >
> > Ralph
> >
> >> On Jul 5, 2016, at 2:03 PM, Leon Finker wrote:
> >>
t;
> > On 2016/07/06, at 23:06, Leon Finker wrote:
> >
> > Based on google searches, it turns out to be a classic class loading
> > deadlock. I found one thread that was inside the class' static initializer:
> > , which then eventually ended up logging
Hi,
Use case: provide log4j2 logging in Felix OSGi application. Nothing OSGi
specific as far as logging concerned. Simply need to log all logging events to
configured log file for the application. Using async logging.
If we run log4j2 (any current version) with default context selector, then we
t; couldn’t say. If we need a context selector specifically for OSGi
> environments that can certainly be implemented, but we would have to know
> what the expected behavior is. Of course, you can always implement it and
> submit it as a patch to a Jira issue.
>
> Ralph
>
> >
le application per JVM.
>
> On Wed, 25 Jul 2018 at 12:23, Leon Finker wrote:
>
> > For our use case BasicContextSelector works as expected. We really don't
> > need one async logger, disruptor, thread, etc per class loader.
> >
> > On Wed, Jul 25, 2018, 1
HI,
Using log4j2 1.13.1 with disruptor 3.4.2. Linux CentOS. JRE 11.0.5
Using the following JRE args:
-DAsyncLogger.RingBufferSize=32768
-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
-Dlog4j.configurationFile=...
The disruptor queue has filled up. And we've
x/log4j-core/apidocs/org/apache/logging/log4j/core/async/AsyncQueueFullPolicy.html>.
> > Note that option 2 above (synchronous) is only used by Log4j in certain
> > circumstances and there isn’t an option to specify that, so the only real
> > options are the default behav
hat indexes based on event timestamp. The funny thing is that I haven't seen
> any occurrences of this behavior since switching the queue-full policy to
> synchronous rather than enqueue, so I'm inclined to believe there's a
> disruptor bug somewhere, but I could be wrong.
>
.com/LMAX-Exchange/disruptor/issues/307
> > > > I ended up switching my services to log synchronously rather than
> > enqueue
> > > > when the buffer is full, which
> > > > can produce events out of order, however we log into a structured
> >
r 16, 2021 at 7:28 AM Leon Finker wrote:
>
> > We are using default TimeoutBlockingWaitStrategy. I doubt it will
> > reproduce again. We have been using 1.13.1 since October 2020 and this
> > never happened till now (been using log4j2 since the beginning on
> > various ver
17 matches
Mail list logo
