You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Michael Nussbaum (JIRA)" <ji...@apache.org> on 2015/01/13 21:04:36 UTC

[jira] [Created] (LOG4J2-936) Erroneously conjoined log events

Michael Nussbaum created LOG4J2-936:
---------------------------------------

             Summary: Erroneously conjoined log events
                 Key: LOG4J2-936
                 URL: https://issues.apache.org/jira/browse/LOG4J2-936
             Project: Log4j 2
          Issue Type: Bug
          Components: Appenders
    Affects Versions: 2.1, 2.0, 2.2
            Reporter: Michael Nussbaum


There is a race condition in the {{AbstractOutputStreamAppender}} that allows two log events to be sent in the same UDP package during concurrent log writes, thereby combining them into a single log event of output. This is an issue at least for the {{SyslogAppender}}, as only the first of the two lines will be parsed and templated correctly by services like rsyslog. 

Currently, the {{AbstractOutputStreamAppender}} uses a read lock in its {{append}} method to lock around writes and flushes to the log manager. However, two threads may acquire the read lock, write simultaneously to the log manager and then trigger a manager flush. Since the {{DatagramOutputStream}} only sends packets upon receiving the flush method this will cause two log events to go into a single UDP package, which violates [RFC 5426 spec|https://tools.ietf.org/html/rfc5426#section-3.1].

One option to fix the bug is to change the read lock used in the {{append}} method to be a write lock. This seems to match the intention of the code, and I'm curious as to why a read lock was used originally.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org