Mailing-List: contact log4net-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4NET Dev" <log4net-dev@logging.apache.org>
Date: Wed, 3 Apr 2013 03:55:15 +0000 (UTC)
From: "Jarrod Alexander (JIRA)" <jira@apache.org>
To: log4net-dev@logging.apache.org
Message-ID: <JIRA.12638937.1364236433558.96610.1364961315008@arcas>
In-Reply-To: <JIRA.12638937.1364236433558@arcas>
References: <JIRA.12638937.1364236433558@arcas>
Subject: [jira] [Commented] (LOG4NET-370) RemoteSyslogAppender doesn't
 properly handle newline in log message
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jarrod Alexander commented on LOG4NET-370:
------------------------------------------

To get a measurable result, I implemented each of the 4 methods and executed the complete Append method 10,000 times recorded the number of milliseconds it took to complete on my machine.  I swapped in a fake UdpClient to remove network considerations from the result, and tested each of the 4 implementations using the same 100 byte and 1000 byte randomly generated ASCII string.  The results are:

Logging 100 byte random string 10000 times:
Pre 1461433:     93ms
1461433:         252ms
Suggested:       242ms
Regex:           358ms

Logging 1000 byte random string 10000 times:
Pre 1461433:     171ms
1461433:         1516ms
Suggested:       1467ms
Regex:           2708ms

The suggested timing above is my suggested (last patch) version, with a couple of minor tweaks.  It appears to be slightly faster than even the 1461433 version, although any amount of string processing is nearly an order of magnitude slower than the original implementation.  Still, this should be plenty fast considering it can log 1KB in ~0.1467ms.  If you would like, I can attach my benchmark code. 
                
> RemoteSyslogAppender doesn't properly handle newline in log message
> -------------------------------------------------------------------
>
>                 Key: LOG4NET-370
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-370
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>         Environment: All
>            Reporter: Jarrod Alexander
>            Assignee: Dominik Psenner
>             Fix For: 1.2.12
>
>         Attachments: RemoteSyslogAppender.cs.patch, RemoteSyslogAppender.cs.revised2.patch, RemoteSyslogAppender.cs.revised3.patch, RemoteSyslogAppender.cs.revised.patch
>
>
> RemoteSyslogAppender sends log messages containing newline characters to syslog, however the syslog RFC 3164 states that the message portion of the syslog packet can only contain visible ASCII characters and spaces.  This causes multiline log messages to render on a single line in at least some instances.
> The solution appears to be sending each line of the log message as a separate syslog packet.  I have modified RemoteSyslogAppender to support this behavior and will provide a patch file.
> Here is the relevant portion of the RFC:
> 4.1.3 MSG Part of a syslog Packet
>    The MSG part will fill the remainder of the syslog packet.  This will
>    usually contain some additional information of the process that
>    generated the message, and then the text of the message.  There is no
>    ending delimiter to this part.  The MSG part of the syslog packet
>    MUST contain visible (printing) characters.  The code set
>    traditionally and most often used has also been seven-bit ASCII in an
>    eight-bit field like that used in the PRI and HEADER parts.  In this
>    code set, the only allowable characters are the ABNF VCHAR values
>    (%d33-126) and spaces (SP value %d32).  However, no indication of the
>    code set used within the MSG is required, nor is it expected.  Other
>    code sets MAY be used as long as the characters used in the MSG are
>    exclusively visible characters and spaces similar to those described
>    above.  The selection of a code set used in the MSG part SHOULD be
>    made with thoughts of the intended receiver.  A message containing
>    characters in a code set that cannot be viewed or understood by a
>    recipient will yield no information of value to an operator or
>    administrator looking at it.
> http://www.ietf.org/rfc/rfc3164.txt

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira