This setup should work for us. While we don’t control logging initialization,
we will reliably be present on the classpath at initialization time, and
ServiceLoader should have no problems finding our implementation.
> You probably want to implement a "push" counter for the discarded messages,
Hi Adam,
On Fri, 12 Apr 2024 at 21:42, Thomas, Adam wrote:
> That sounds appealing, but do you have to have this hook registered by the
> time the disruptor is set up? That's my fundamental concern with a lot of
> these interception strategies - if your library/framework is called (which
>
Matt,
That sounds appealing, but do you have to have this hook registered by the time
the disruptor is set up? That's my fundamental concern with a lot of these
interception strategies - if your library/framework is called (which ours is),
instead of being the entry point (as many others often
We’ve got a new proposal from Piotr on this front now which sort of emulates
his suggestion for 3.x but applied to 2.x (since that doesn’t have the DI
system). I like the approach there as it provides enough of a hook for users to
customize whatever metrics library they wish to enhance some
Hi Volkan,
On Thu, 11 Apr 2024 at 21:26, Volkan Yazıcı wrote:
> *Slightly longer answer:* Log4j has never had a holistic observability view
> to its internals. We need something new (if not, from scratch), and
> preferably, applicable to not only async. logging, but all components
> wherever
trol.
>
> -Adam
>
>
> From: Volkan Yazıcı
> Date: Thursday, April 11, 2024 at 4:09 AM
> To: Adam Thomas
> Cc: "dev@logging.apache.org"
> Subject: RE: Monitoring discards from async logging
>
>
> Hello Adam,
>
> I am very sorry for the frus
uple to a
non-public API (such as reflecting into private fields), and doubly so when it
is code I do not control.
-Adam
From: Volkan Yazıcı
Date: Thursday, April 11, 2024 at 4:09 AM
To: Adam Thomas
Cc: "dev@logging.apache.org"
Subject: RE: Monitoring discards from async logging
Hello Adam,
I am very sorry for the frustrating experience. I can certainly see you do
an excellent job in getting engaged with the project to get this feature
request rolling. Thank you so much for that.
I read your conversation with Piotr and I get your point – yes, neither
migration to Log4j
> All you need is a `log4j2.component.properties` file in your library.
It is very common practice here to explicitly specify the discard policy as a
system property, as it was recommended to teams moving from log4j1 to log4j2.
Adding this would have very little impact.
> Until then I am
Hi Adam,
On Wed, 10 Apr 2024 at 19:03, Thomas, Adam wrote:
> I would do this if I had control of the end user's logging setup.
> Unfortunately, I vend an internal library that is used by a lot of different
> teams. By the time my code is invoked, AsyncLoggerDisruptor has already read
> the
> What version of Java are you using? If it is Java 17
Unfortunately, I need to support Java 8 and 11.
> you can still configure Log4j Core to use your own implementation of
> `AsyncQueueFullPolicy` by setting the `log4j2.asyncQueueFullPolicy` system
> property
I would do this if I had
Hi Adam,
On Wed, 10 Apr 2024 at 00:11, Thomas, Adam wrote:
> I created a pull request[1] late last year for this, and was encouraged to
> start a discussion on the dev list at the time.
Be reassured that we didn't forget about your PR, we just have a lot
of changes going on to publish Log4j
I created a pull request[1] late last year for this, and was encouraged to
start a discussion on the dev list at the time.
We run log4j2 on a lot of hosts that are operated by different teams. By
default, our users use async logging and use the Discard asyncQueueFullPolicy.
As far as I can
13 matches
Mail list logo
