logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Nussbaum (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-936) Erroneously conjoined log events
Date Tue, 13 Jan 2015 23:12:34 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14276148#comment-14276148
] 

Michael Nussbaum commented on LOG4J2-936:
-----------------------------------------

Overriding #getLock in SyslogAppender seems like a pretty reasonable approach. I can produce
a second patch with that approach if there's interest?

Looking through the code though it seems that no other child classes explicitly use this lock,
and since it's a read lock there is no circumstance where the lock will block, so could the
read lock be removed entirely?

> 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.0, 2.1
>            Reporter: Michael Nussbaum
>              Labels: rfc5426, syslog
>         Attachments: patchfile.txt
>
>
> 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


Mime
View raw message