rded messages,
> so you get notified immediately whenever a discard event occurs?
For my use-case, no, periodic reporting is fine, but I'm happy to do the
batching on my end.
-Adam
On 4/12/24, 2:50 PM, "Piotr P. Karwasz" mailto:piotr.karw...@gmail.com>> wrote:
Hi Adam,
On F
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
ontext`
2. Reflectively extract the `AsyncLoggerContext#loggerDisruptor`
3. Reflectively extract the `AsyncLoggerDisruptor#asyncQueueFullPolicy`
4. Call `DiscardingAsyncQueueFullPolicy.getDiscardCount()` on the policy
instance
Kind regards.
On Wed, Apr 10, 2024 at 12:11 AM Thomas, Adam
wrote:
I created a
10:42 AM, "Piotr P. Karwasz" mailto:piotr.karw...@gmail.com>> wrote:
Hi Adam,
On Wed, 10 Apr 2024 at 19:03, Thomas, Adam mailto:adamt...@amazon.com.inva>lid> wrote:
> I would do this if I had control of the end user's logging setup.
> Unfortunately, I vend an i
ce thousands of developers to change their system properties.
-Adam
On 4/9/24, 4:02 PM, "Piotr P. Karwasz" mailto:piotr.karw...@gmail.com>> wrote:
Hi Adam,
On Wed, 10 Apr 2024 at 00:11, Thomas, Adam mailto:adamt...@amazon.com.inva>lid> wrote:
> I created a pull request[1] late l
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
