Log appender channel adapter
An event-driven adapter that receives logging events of the application.
A message producer endpoint that registers itself as an Appender
for Logback, sending all received logging events as XML messages to the output channel.
Note that any downstream logging events caused by the sending of logging messages are automatically skipped by Logback appenders as long as these are send from the same thread. This means that when the message flow this adapter is connected to is not single-threaded (e.g., by using a queue-channel), this will cause an infinite loop! To prevent this, try to avoid any downstream logging where possible and make sure the entire message flow is single-threaded (by using direct-channels, for example).
The generated messages will be complete, well-formed XML documents represented as a String. These messages will contain one <logging-event>
element, as defined by the XML schema located at:
classpath:com/emagiz/components/logging/emagiz-logging-1.0.xsd
Logger name
Sets the name of the Logger
this adapter will be appended to in order to receive logging events.
If not set, the root logger is used by default.
Level
Sets the logging level below which logging events will be filtered out by this appender.
Note that this setting is independent of the log level of the Logger
, and will only appear to have an effect when it is set to a higher level than the Logger
. In general, if you're not interested at all in certain log levels you should use the level of the Logger
, as this will generate less logging events (better performance). Change the log level of this appender when you want different log levels for multiple appenders.
If not set, the level is INFO by default (filtering out any TRACE and DEBUG events).
Appender type
Sets the type of appender this message producer endpoint will register itself as.
- UNSYNCHRONISED: An unsynchronised appender could improve performance, but can also cause thread synchronisation issues in the downstream message flow.
- SYNCHRONISED: A synchronised appender could prevent any thread synchronisation issues in the downstream message flow, but can also decrease performance.
- ASYNCHRONOUS: An asynchronous appender could prevent any thread synchronisation issues in the downstream message flow and significantly improve performance by decoupling application threads and logging appenders, but can also lead to loss of logging events and more heap memory usage because it will queue events in memory. Also when this queue is full, application threads will block until the queue is no longer at its maximum capacity.
Default is UNSYNCHRONISED
.
Queue size
The maximum capacity of the blocking queue.
Default is 256
.
Discarding threshold
The threshold to start discarding messages when the blocking queue is filling up. By default, when the blocking queue has 20% capacity remaining, it will drop events of level TRACE, DEBUG and INFO, keeping only events of level WARN and ERROR.
Setting the threshold to 0
disables any discarding of logging events; setting the threshold to the maximum queue size (or higher) will result in all logging events of level TRACE, DEBUG and INFO being discarded immediately.
Default is 20% of the queue size.
Retry interval
If sending a logging event to the output channel fails, this appender is stopped automatically to prevent a cascading failure. By specifying a retry interval, this appender will schedule tasks to periodically try to startup again. All logging events that were logged in the mean time will be lost however.
Default is undefined, disabling any retry attempts.
Cache max size
To detect and aggregate repeating log entries, this channel adapter uses an internal cache to keep track of the most recent log messages. This setting can be used to change the maximum number of log entries that are kept in memory, or even completely disable the detection of repeating log entries by using a value less than 1
.
Default is 100
.
Cache check interval
To detect and aggregate repeating log entries, this channel adapter uses an internal cache to keep track of the most recent log messages. A cleanup task periodically runs to check for log entries that should be moved out of the cache and send to the output channel. This setting can be used to change the interval (in milliseconds) between these cleanup tasks.
Default is 60000
(1 minute).
Cache max repeat count
To detect and aggregate repeating log entries, this channel adapter uses an internal cache to keep track of the most recent log messages. A cleanup task periodically runs to check for log entries that should be moved out of the cache and send to the output channel. This setting can be used to change the number of repeats after which a log entry will be moved out of the cache, regardless of whether it is still repeating.
Default is 1000
.
Cache max repeat delay
To detect and aggregate repeating log entries, this channel adapter uses an internal cache to keep track of the most recent log messages. A cleanup task periodically runs to check for log entries that should be moved out of the cache and send to the output channel. This setting can be used to change the maximum delay (in milliseconds) between two similar log entries to classify them as "repeating". After this delay has passed without another identical message being logged, a log entry will be moved out of the cache since it is no longer considered to be repeating.
Default is 120000
(2 minutes).
Send timeout
The maximum amount of time in milliseconds to wait when sending a message to the output channel.
Default is 0
, i.e. sends should be handled immediately without blocking waits.
Error channel
If a (synchronous) downstream exception is thrown and an error channel is specified, the MessagingException
will be sent to this channel. Otherwise, any such exception will simply be logged as a warning by the channel adapter.
Channel
Channel where the generated messages should be sent to.
You can select the nullChannel
here to silently drop the messages.
Required
Id
Name that uniquely identifies this flow component.
Required