Hi Mikael,
Unfortunately it is not working in my setup to include the
log4j2.component.properties file.
I am not possible at the moment to configure the another asyncQueueFullPolicy.
I tried the following ways: (we are using Hybris)
First Try:
1. Configure the asynclogger with xml configuration which resides in classpath
2. Add the following values to local.properties file
a. log4j2.config.xml=hybris-log4j2.xml
b. log4j2.asyncLoggerRingBufferSize=260000
c. log4j2.asyncQueueFullPolicy=Discard
d. log4j2.discardThreshold=DEBUG
Second Try:
1. Configure the asynclogger with xml configuration which resides in classpath
2. Add the following values to log4j2.component.properties which resides in
same classpath
a. log4j2.config.xml=hybris-log4j2.xml
b. log4j2.asyncLoggerRingBufferSize=260000
c. log4j2.asyncQueueFullPolicy=Discard
d. log4j2.discardThreshold=DEBUG
In both solutions, I get this in TRACE console log, so it seems that the
default configuration will be loaded:
INFO | jvm 1 | main | 2018/01/16 16:31:54.014 | 2018-01-16 16:31:53,913
lidl-shop.com-startStop-4 DEBUG Configuration XmlConfiguration[location=stream
(14883 bytes, unknown location)] initialized
INFO | jvm 1 | main | 2018/01/16 16:31:54.015 | 2018-01-16 16:31:53,914
lidl-shop.com-startStop-4 DEBUG Starting configuration
XmlConfiguration[location=stream (14883 bytes, unknown location)]
INFO | jvm 1 | main | 2018/01/16 16:31:54.015 | 2018-01-16 16:31:53,914
lidl-shop.com-startStop-4 TRACE AsyncLoggerConfigDisruptor creating new
disruptor for this configuration.
INFO | jvm 1 | main | 2018/01/16 16:31:54.015 | 2018-01-16 16:31:53,918
lidl-shop.com-startStop-4 TRACE property AsyncLoggerConfig.WaitStrategy=TIMEOUT
INFO | jvm 1 | main | 2018/01/16 16:31:54.015 | 2018-01-16 16:31:53,961
lidl-shop.com-startStop-4 DEBUG Starting AsyncLoggerConfig disruptor for this
configuration with ringbufferSize=262144,
waitStrategy=TimeoutBlockingWaitStrategy, exceptionHandler=org.apache.
logging.log4j.core.async.AsyncLoggerConfigDefaultExceptionHandler@66dd2d36...
Do you have any idea how can I configure these values?
Thanks and greetings,
Christian
On 04.01.18, 12:00, "Mikael Ståldal" <mi...@apache.org> wrote:
Or include a log4j2.component.properties file in classpath.
https://urldefense.proofpoint.com/v2/url?u=https-3A__logging.apache.org_log4j_2.x_manual_configuration.html-23System-5FProperties&d=DwIDaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=37nF0SnGtdjmcblOpYG7cKwaPDc1GWo5GNDvnDLF8TE&m=lVphsnNDcnbOx_3dfvRm2hixA_KjF0dVz1gFnj2INWI&s=iN5cxHt0_1hAWprylfkuZnVooj-yjTCceP8W5wRfd_M&e=
On 2018-01-03 17:57, Matt Sicker wrote:
> Those are system properties, but in log4j 2.10+, you can also use an
> environment variable instead.
>
> On 3 January 2018 at 07:36, Fröstl, Christian <
> christian.froe...@accenture.com> wrote:
>
>> Hi,
>>
>> Thanks, that clarifies it. (
>> Is it possible to set the log4j2.asyncQueueFullPolicy and
>> log4j2.discardThreshold in the log4j2 xml configuration file or only as
>> environment variable?
>>
>> Greetings,
>> Christian
>>
>> On 03.01.18, 09:43, "Remko Popma" <remko.po...@gmail.com> wrote:
>>
>> No, the default async queue full policy is to block and not drop any
>> events. (This is different from Logback whose AsyncAppender is “lossy by
>> default if 80% full”.) Log4j 2.10 will block until space becomes
available
>> in the buffer.
>>
>> If you configure the DiscardingAsyncQueueFullPolicy (
>> https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__logging.apache.org_log4j_2.x_log4j-2Dcore_xref_org_
>> apache_logging_log4j_core_async_DiscardingAsyncQueueFullPolicy
>> .html&d=DwIFaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=
>> 37nF0SnGtdjmcblOpYG7cKwaPDc1GWo5GNDvnDLF8TE&m=
>> YD5JM4y8v44bpRXCOPKk3J0VIzak5IxqVyGe6fhkqAM&s=
>> Ggo8IbBfo8JQkLyrBQY4HhEpgjf3Flb_EM3Zu5y_Do0&e=), events below the
>> threshold are discarded when the queue is full. The default threshold is
>> INFO, so trace and debug events are discarded, while INFO and higher
events
>> will not be discarded so the appender will have to block until space
>> becomes available.
>>
>> I hope this clarifies things. :-)
>>
>> Remko
>>
>> (Shameless plug) Every java main() method deserves
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__picocli.
>> info&d=DwIFaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=
>> 37nF0SnGtdjmcblOpYG7cKwaPDc1GWo5GNDvnDLF8TE&m=
>> YD5JM4y8v44bpRXCOPKk3J0VIzak5IxqVyGe6fhkqAM&s=kCeGLk_Nd7hwvw13yJf3riq_
>> 6WW8ixnCv5pTFMijt_U&e=
>>
>> > On Jan 3, 2018, at 17:08, Fröstl, Christian <
>> christian.froe...@accenture.com> wrote:
>> >
>> > Hi,
>> >
>> > Thanks for your response.
>> > Just one question to verify.
>> > In the default configuration, all events of level info, debug and
>> trace will be dropped, if the ringbuffer is full. For all other events
the
>> application will block and if the ringbuffer has space again, the block
>> will release and the events will be written, right?
>> > That means that only events of type Info, debug and trace could be
>> lost, but none of the higher levels like error, warn and severe, right?
>> >
>> > Kind regards,
>> > Christian
>> >
>> > On 22.12.17, 01:53, "Remko Popma" <remko.po...@gmail.com> wrote:
>> >
>> > Yes by default the application thread will block until a slot
>> becomes available in the queue.
>> >
>> > Yes this is configurable: see
https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.proofpoint&d=DwIDaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=37nF0SnGtdjmcblOpYG7cKwaPDc1GWo5GNDvnDLF8TE&m=lVphsnNDcnbOx_3dfvRm2hixA_KjF0dVz1gFnj2INWI&s=Ve3ztZ-0F2t0m9Qtuq77swFIg7vkd_V_Z60yjzXyln8&e=.
>> com/v2/url?u=https-3A__github.com_apache_logging-2Dlog4j2_
>> blob_master_log4j-2Dcore_src_main_java_org_apache_logging_
>>
log4j_core_async_AsyncQueueFullPolicyFactory.java&d=DwIFaQ&c=eIGjsITfXP_y-
>> DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=37nF0SnGtdjmcblOpYG7cKwaPDc1GW
>> o5GNDvnDLF8TE&m=hk-mti7hK6agTdNqpiQVl3gpA4ri4hrn2pxHf_8maIE&s=
>> QykinLq8RJFWq5YIigJq8wWizXFOxKy3DWeXTomCnaM&e=
>> >
>> > (Shameless plug) Every java main() method deserves
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__picocli.
>> info&d=DwIFaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=
>> 37nF0SnGtdjmcblOpYG7cKwaPDc1GWo5GNDvnDLF8TE&m=hk-
>> mti7hK6agTdNqpiQVl3gpA4ri4hrn2pxHf_8maIE&s=w_
>> w2x7qWvjFgf1pKLN7kb5Q534FwglDl16TI5-OArl4&e=
>> >
>> >> On Dec 20, 2017, at 2:03, Fröstl, Christian <
>> christian.froe...@accenture.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I currently don’t find any documentation regarding the fallback
>> methods of the log4j2 async logger.
>> >> What happens when the AsyncLogger.RingBufferSize is too small to
>> log all entries from a burst? Will the application fall back into sync
>> logging and slow down the application or will the new messages be
dropped?
>> >> Is this a configurable behaviour?
>> >>
>> >> Kind regards,
>> >> Christian
>> >>
>> >>
>> >> ________________________________
>> >>
>> >> This message is for the designated recipient only and may contain
>> privileged, proprietary, or otherwise private information. If you have
>> received it in error, please notify the sender immediately and delete the
>> original. Any other use of the email by you is prohibited.
>> >
>> >
>> >
>> > ------------------------------------------------------------
>> ---------
>> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> > For additional commands, e-mail:
log4j-user-h...@logging.apache.org
>> >
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
________________________________
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited.
