ppkarwasz commented on code in PR #2552:
URL: https://github.com/apache/logging-log4j2/pull/2552#discussion_r1587650201
##########
src/site/antora/modules/ROOT/pages/manual/async.adoc:
##########
@@ -363,87 +348,95 @@ The below properties can also be specified by creating a
file named
`log4j2.component.properties` and including this file in the classpath
of the application.
-NOTE: All system properties were renamed into a more consistent style in
-Log4j 2.10. All old property names are still supported which are
-documented xref:manual/configuration.adoc#SystemProperties[here].
-
[[SysPropsMixedSync-Async]]
.System Properties to configure mixed asynchronous and normal loggers
-[cols="5m,2,10a",options="header"]
+[cols="1,1,5"]
|===
-|System Property |Default Value |Description
+h| Java Property
-|log4j2.asyncLoggerConfigExceptionHandler
-|`default handler`
-|Fully qualified name of a class that implements the
-`com.lmax.disruptor.ExceptionHandler` interface. The class needs to have
-a public zero-argument constructor. If specified, this class will be
-notified when an exception occurs while logging the messages.
+(Environment Variable)
+h| Default Value
+h| Description
-If not specified, the default exception handler will print a message and
+|
[[log4j2.asyncLoggerConfigExceptionHandler]]`log4j2.asyncLoggerConfig{zwsp}ExceptionHandler`
+
+(`LOG4J_ASYNC_LOGGER_CONFIG_{zwsp}EXCEPTION_HANDLER`)
+|
link:../javadoc/log4j-core/org/apache/logging/log4j/core/async/AsyncLoggerConfigDefaultExceptionHandler[AsyncLoggerConfig{zwsp}DefaultExceptionHandler]
+|
+Fully qualified name of a class that implements the
https://lmax-exchange.github.io/disruptor/javadoc/com.lmax.disruptor/com/lmax/disruptor/ExceptionHandler.html[ExceptionHandler]
interface, which will be notified when an exception occurs while logging
messages.
+The class needs to have a public zero-argument constructor.
+
+The default exception handler will print a message and
stack trace to the standard error output stream.
-|log4j2.asyncLoggerConfigRingBufferSize
-|256 * 1024
-|Size (number of slots) in the RingBuffer used by the asynchronous
-logging subsystem. Make this value large enough to deal with bursts of
-activity. The minimum size is 128. The RingBuffer will be pre-allocated
-at first use and will never grow or shrink during the life of the
-system.
-
-When the application is logging faster than the underlying appender can
-keep up with for a long enough time to fill up the queue, the behavious
-is determined by the
-link:../javadoc/log4j-core/org/apache/logging/log4j/core/async/AsyncQueueFullPolicy.html[AsyncQueueFullPolicy].
-
-|[[asyncLoggerConfigWaitStrategy]]log4j2.asyncLoggerConfigWaitStrategy
-|`Timeout`
-|Valid values: Block,
-Timeout, Sleep, Yield.
-(See also the <<Custom WaitStrategy>> section below.) +
-`Block` is a strategy that uses a lock and condition variable for the
-I/O thread waiting for log events. Block can be used when throughput and
-low-latency are not as important as CPU resource. Recommended for
-resource constrained/virtualised environments. +
-`Timeout` is a variation of the `Block` strategy that will periodically
-wake up from the lock condition await() call. This ensures that if a
-notification is missed somehow the consumer thread is not stuck but will
-recover with a small latency delay (default 10ms). +
-`Sleep` is a strategy that initially spins, then uses a Thread.yield(),
-and eventually parks for the minimum number of nanos the OS and JVM will
-allow while the I/O thread is waiting for log events. Sleep is a good
-compromise between performance and CPU resource. This strategy has very
-low impact on the application thread, in exchange for some additional
-latency for actually getting the message logged. +
-`Yield` is a strategy that uses a Thread.yield() for waiting for log
-events after an initially spinning. Yield is a good compromise between
-performance and CPU resource, but may use more CPU than Sleep in order
-to get the message logged to disk sooner.
-
-|log4j2.asyncLoggerConfigTimeout
-|`10`
-|Timeout in milliseconds of `TimeoutBlockingWaitStrategy`. See
-link:#asyncLoggerConfigWaitStrategy[WaitStrategy System Property] for details.
+|
[[log4j2.asyncLoggerConfigRingBufferSize]]`log4j2.asyncLoggerConfig{zwsp}RingBufferSize`
+
+(`LOG4J_ASYNC_LOGGER_CONFIG_{zwsp}RING_BUFFER_SIZE`)
+| `256 × 1024`
+
+`4 × 1024` (GC mode)
+|
+Size (number of slots) in the RingBuffer used by the asynchronous
+logging subsystem.
+Make this value large enough to deal with bursts of
+activity.
+The minimum size is 128.
+The RingBuffer will be pre-allocated at first use and will never grow or
shrink during the life of the system.
+
+When the application is logging faster than the underlying appender can keep
up with for a long enough time to fill
+up the queue, the behaviour is determined by the
link:../javadoc/log4j-core/org/apache/logging/log4j/core/async/AsyncQueueFullPolicy.html[AsyncQueueFullPolicy].
+
+|
[[log4j2.asyncLoggerConfigWaitStrategy]]`log4j2.asyncLoggerConfig{zwsp}WaitStrategy`
+
+(`LOG4J_ASYNC_LOGGER_CONFIG_{zwsp}WAIT_STRATEGY`)
+| `Timeout`
+a| Specifies the
https://lmax-exchange.github.io/disruptor/javadoc/com.lmax.disruptor/com/lmax/disruptor/WaitStrategy.html[WaitStrategy]
used by the LMAX Disruptor.
+
+Valid values:
+
+* `Block`: a strategy that uses a lock and condition variable for the I/O
thread waiting for log events.
+Block can be used when throughput and low-latency are not as important as CPU
resource.
+Recommended for resource constrained/virtualised environments.
+
+* `Timeout`: a variation of the `Block` strategy that will periodically wake
up from the lock condition `await()` call.
+This ensures that if a notification is missed somehow the consumer thread is
not stuck but will recover with a small latency delay (see
<<log4j2.asyncLoggerConfigTimeout>>)
+
+* `Sleep`: a strategy that initially spins, then uses a `Thread.yield()`, and
eventually parks for the minimum number of nanos the OS and JVM will allow
while the I/O thread is waiting for log events (see
<<log4j2.asyncLoggerConfigRetries>> and
<<log4j2.asyncLoggerConfigSleepTimeNs>>).
+Sleep is a good compromise between performance and CPU resource.
+This strategy has very low impact on the application thread, in exchange for
some additional latency for actually getting the message logged.
+
+* `Yield`: is a strategy that uses a `Thread.yield()` for waiting for log
events after an initially spinning.
+Yield is a good compromise between performance and CPU resource, but may use
more CPU than `Sleep` in order to get the message logged to disk sooner.
+
+* a <<Custom WaitStrategy>>.
Review Comment:
Fixed in 46550d21f7cf4736bd0c4bcc88713e5bf4f981be
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
