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

Jose Luis Pedrosa commented on LOG4NET-415:
-------------------------------------------

Cauchy

This is UDP, Fire and forget, you don't block your bussiness for logging. 
Failures are better than retries, TCP vs UDP, And again this is a very very 
exotic scenario that It's not possible to reproduce using the whole .log4net 
(only raw socket send in a loop to make it happen)

Async involves more threads going on on your application and more memory 
consumption.

Async is good when you need to know when your invokation has completed and you 
need to do something afterwards, which is not the case.

Rgds


> 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 environment
>            Reporter: Jose Luis Pedrosa
>              Labels: RemoteSyslogAppender
>         Attachments: LOG4NET-415.patch, MessageLostTest.cs, 
> RemoteSyslogNonBlockingv2.patch
>
>
> 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)

Reply via email to