You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The serialization of all values, whether for context or data, is performed by the encoder. If the encoder is setup on an appender which is executed asynchronously, then the encoding is performed in a different thread. For more information about Logback Appenders see:
If the value is immutable it is guaranteed to be the same when serialized asynchronously even if it occurs much later in the program's execution. However, mutable values may change state between the time the log message is created and the message is serialized. Thus, it is possible to log a message with the "wrong" (perhaps more correctly, misleading or mismatched) data values. However, the serialization in another thread actually improves the performance of your program versus formatting a String inline (especially if that log message is discarded).
The framework should be extended to support upfront serialization of mutable types. To put it another way, to detect immutable types and only pass those as-is for delayed serialization while serializing mutable types (perhaps to JsonNode) before dispatching to the appender. To mark immutable types we should use JSR-305:
This will be relatively straight forward when using the LogBuilder but more difficult (possibly impossible) to do in a general way with log statements using the markers. Whatever the limitations they should be clearly documented.
The text was updated successfully, but these errors were encountered:
The serialization of all values, whether for context or data, is performed by the encoder. If the encoder is setup on an appender which is executed asynchronously, then the encoding is performed in a different thread. For more information about Logback Appenders see:
http://logback.qos.ch/manual/appenders.html
If the value is immutable it is guaranteed to be the same when serialized asynchronously even if it occurs much later in the program's execution. However, mutable values may change state between the time the log message is created and the message is serialized. Thus, it is possible to log a message with the "wrong" (perhaps more correctly, misleading or mismatched) data values. However, the serialization in another thread actually improves the performance of your program versus formatting a String inline (especially if that log message is discarded).
The framework should be extended to support upfront serialization of mutable types. To put it another way, to detect immutable types and only pass those as-is for delayed serialization while serializing mutable types (perhaps to JsonNode) before dispatching to the appender. To mark immutable types we should use JSR-305:
https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/concurrent/Immutable.java
http://mvnrepository.com/artifact/com.google.code.findbugs/jsr305
This will be relatively straight forward when using the LogBuilder but more difficult (possibly impossible) to do in a general way with log statements using the markers. Whatever the limitations they should be clearly documented.
The text was updated successfully, but these errors were encountered: