[
https://issues.apache.org/jira/browse/LOG4NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869607#comment-13869607
]
Stefan Bodewig edited comment on LOG4NET-415 at 1/13/14 3:19 PM:
-----------------------------------------------------------------
Sorry for not responding for so long - and in addition I don't really have my
brain with me right now, so I may be suggesting stupid things.
* without Jose Luis' changes SyslogAppender had guaranteed delivery - if we add
an option to use non-blocking sockets we need to make this change explicit (or
rather state what the choice of the parameter entails). It is quite possible
people using a syslog appender don't actually know they are using UDP under
the covers.
* doing things asynchronously requires some extra coding - you need to "fix"
thread-local state that may contribute to the log message. I think there is
some kind of AsyncAppender similar to BufferingForwardingAppender inside this
JIRA (and if there isn't, then we still should provide one). I'd prefer a
generic async appender (using ,NET 2.0 compatible code if possible) over
appender specific async solutions.
Just did a quick search: LOG4NET-190, LOG4NET-201, LOG4NET-407 and apparently
we already have got some sort of AsyncAppender inside the examples, oops.
was (Author: bodewig):
Sorry for not responding for so long - and in addition I don't really have my
brain with me right now, so I may be suggesting stupid things.
* without Jose Luis' changes SyslogAppender had guaranteed delivery - if we add
an option to use non-blocking sockets we need to make this change explicit (or
rather state what the choice of the parameter entails). It is quite possible
people using a syslog appender don't actually know they are using UDP under
the covers.
* doing things asynchronously requires some extra coding - you need to "fix"
thread-local state that may contribute to the log message. I think there is
some kind of AsyncAppender similar to BufferingForwardingAppender inside this
JIRA (and if there isn't, then we still should provide one). I'd prefer a
generic async appender (using ,NET 2.0 compatible code if possible) over
appender specific async solutions.
> 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,
> MessageLostTest.cs, MessageLostTestAsync.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)
