You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Jose Luis Pedrosa (JIRA)" <ji...@apache.org> on 2014/01/06 13:27:50 UTC

[jira] [Created] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164

Jose Luis Pedrosa created LOG4NET-415:
-----------------------------------------

             Summary: RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
                 Key: LOG4NET-415
                 URL: https://issues.apache.org/jira/browse/LOG4NET-415
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
    Affects Versions: 1.2.13
         Environment: Any windows Windows environment
            Reporter: Jose Luis Pedrosa


Sending UDP packages may block for some time in specific circumstances:
1) Next hop in network level 3 can't be resolved by ARP.
2) Datagram size exceeds FastSendDatagramThreshold configured size.

When sending packets bigger than FastSendDatagramThreshold, the OS waits until the packet is actually sent, if the If the syslog (or the next hop to reach the syslog) is in the same VLAN/Subnet the OS tries to resolve by ARP the Ip of the configured syslog, this may take up to 3 seconds, slowing down the whole application, which in some cases can lead to outages (timeouts, DB locks...).

Also the fact that each carriage return generates the headers of the packet again, that can lead to a significant overhead in some scenarios, for instance when loggign HTTP requests to a remote syslog, every header will go in a different message. Also some logging may require characters that are now skipped in patch:  https://issues.apache.org/jira/browse/LOG4NET-370


I'm adding a patch that
1) Moves the use of UDPClient to Non blocking sockets, which eliminates the blocking. 
2) Adds a configuration field to decide if you want Strict RFC Behaviour or not (with default Strict).

Please your feedback, thanks in advance

Jose Luis





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)