Log4j 2
  1. Log4j 2
  2. LOG4J2-542

LogEvents with exceptions fail to deserialize

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-rc1
    • Fix Version/s: 2.0-rc2
    • Component/s: Appenders
    • Labels:
      None

      Description

      Events serialized by
      <Socket name="Socket" host="localhost" port="4560" protocol="TCP">
      <SerializedLayout />
      </Socket>

      are suddenly containing unchanged serialized exceptions again. This was already working in earlier versions.

      Doing so means that receiving such log-events is impossible if the exception class is not available in the receiving application. This is the main reason for ThrowableProxy.

      This is caused by

      org.apache.logging.log4j.core.impl
      public class ThrowableProxy

      { private final Throwable throwable; }

      The throwable field would have to be transient and the info of the Throwable would have to be added to ThrowableProxy. This may be the only necessary change but I'm not sure.

        Issue Links

          Activity

          Hide
          Remko Popma added a comment -

          For background: the throwable field was added in beta9 as part of addressing LOG4J2-216 and LOG4J2-299.

          Show
          Remko Popma added a comment - For background: the throwable field was added in beta9 as part of addressing LOG4J2-216 and LOG4J2-299 .
          Hide
          Remko Popma added a comment -

          When consuming a serialized log event, what exception data would we want included (as non-transient fields) in ThrowableProxy?

          • Exception Class will give the same problem (ClassNotFoundEx or NoClassDefFoundErr). Avoid this by storing only the exception class name as a String.
          • Exception message
          • Stack trace string?
          • anything else?

          For performance reasons, we probably want to avoid generating the stack trace string until the ThrowableProxy is actually serialized.

          Show
          Remko Popma added a comment - When consuming a serialized log event, what exception data would we want included (as non- transient fields) in ThrowableProxy ? Exception Class will give the same problem (ClassNotFoundEx or NoClassDefFoundErr). Avoid this by storing only the exception class name as a String. Exception message Stack trace string? anything else? For performance reasons, we probably want to avoid generating the stack trace string until the ThrowableProxy is actually serialized.
          Hide
          Joern Huxhorn added a comment -

          StackTrace string shouldn't be created at all. It will only cost performance creating it and needs to be parsed on the receiving end, i.e. double impact. It also introduces another opportunity for bugs since toString and parsing of Throwables isn't entirely trivial since the addition of Suppressed.
          Use StackTraceElement[] and StackTracePackageElement[] instead or rather go for a single ExtendedStackTraceElement[] like Logback. Going the ExtendedStackTraceElement path would also prevent the undefined state that StackTraceElement[] and StackTracePackageElement[] length differ.
          A single String would also prevent the serialization mechanism from identifying duplicate entries. If there are two STEs with the same class name then serialization will detect this and reference the previous String instead of sending it again. The same would happen if the entire STE is the same like it's the case with nested exceptions sharing the same STE.

          Show
          Joern Huxhorn added a comment - StackTrace string shouldn't be created at all. It will only cost performance creating it and needs to be parsed on the receiving end, i.e. double impact. It also introduces another opportunity for bugs since toString and parsing of Throwables isn't entirely trivial since the addition of Suppressed. Use StackTraceElement[] and StackTracePackageElement[] instead or rather go for a single ExtendedStackTraceElement[] like Logback. Going the ExtendedStackTraceElement path would also prevent the undefined state that StackTraceElement[] and StackTracePackageElement[] length differ. A single String would also prevent the serialization mechanism from identifying duplicate entries. If there are two STEs with the same class name then serialization will detect this and reference the previous String instead of sending it again. The same would happen if the entire STE is the same like it's the case with nested exceptions sharing the same STE.
          Hide
          Ralph Goers added a comment -

          I suspect the best way to handle this is to add readObject and writeObject methods to ThrowableProxy.

          Show
          Ralph Goers added a comment - I suspect the best way to handle this is to add readObject and writeObject methods to ThrowableProxy.
          Hide
          Ralph Goers added a comment -

          Throwable was made transient in revision 1591544.

          Show
          Ralph Goers added a comment - Throwable was made transient in revision 1591544.

            People

            • Assignee:
              Ralph Goers
              Reporter:
              Joern Huxhorn
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development