[jira] [Comment Edited] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
[ https://issues.apache.org/jira/browse/LOG4NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
[
https://issues.apache.org/jira/browse/LOG4NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13865013#comment-13865013
]
Dongsheng Song edited comment on LOG4NET-415 at 1/9/14 8:35 AM:
Just Set Socket.Blocking to false is not correct non-block programing,
this will cause huge unexpected message lost.
Here is a demo:
{quote}
Message lost rate: 32.61 %, 32.61 %
Message lost rate: 32.90 %, 32.76 %
Message lost rate: 27.28 %, 30.81 %
Message lost rate: 55.46 %, 36.56 %
...
{quote}
Here is my test code:
{code:borderStyle=solid}
class MessageLostTest
{
private static long _messageCount;
private static long _errorCount;
private static void Main()
{
Socket socket = new Socket(AddressFamily.InterNetwork,
SocketType.Dgram, ProtocolType.Udp);
socket.Connect(192.168.30.233, 514);
socket.Blocking = false;
new Thread(delegate(object obj)
{
long m = _messageCount, e = _errorCount;
while (true)
{
Thread.Sleep(5000);
long m2 = Interlocked.Read(ref _messageCount);
long e2 = Interlocked.Read(ref _errorCount);
Console.WriteLine(Message lost rate: {0:##.00 %}, {1:
##.00 %},
(e2 - e) / (double)(m2 - m), e2 /
(double)m2);
m = m2; e = e2;
}
}).Start();
byte[] message = new byte[480];
while (true)
{
try
{
Interlocked.Increment(ref _messageCount);
if (socket.Send(message) != message.Length)
Interlocked.Increment(ref _errorCount);
}
catch (Exception e)
{
Interlocked.Increment(ref _errorCount);
//Console.WriteLine(Socket.Send failed: {0}{1}{2},
e.Message, Environment.NewLine, e.StackTrace);
}
}
}
}
{code}
was (Author: dongsheng):
Just Set Socket.Blocking to false is not correct non-block programing,
this will cause huge unexpected message lost.
Here is a demo:
Message lost rate: 32.61 %, 32.61 %
Message lost rate: 32.90 %, 32.76 %
Message lost rate: 27.28 %, 30.81 %
Message lost rate: 55.46 %, 36.56 %
...
Here is my test code:
class MessageLostTest
{
private static long _messageCount;
private static long _errorCount;
private static void Main()
{
Socket socket = new Socket(AddressFamily.InterNetwork,
SocketType.Dgram, ProtocolType.Udp);
socket.Connect(192.168.30.233, 514);
socket.Blocking = false;
new Thread(delegate(object obj)
{
long m = _messageCount, e = _errorCount;
while (true)
{
Thread.Sleep(5000);
long m2 = Interlocked.Read(ref _messageCount);
long e2 = Interlocked.Read(ref _errorCount);
Console.WriteLine(Message lost rate: {0:##.00 %}, {1:
##.00 %},
(e2 - e) / (double)(m2 - m), e2 /
(double)m2);
m = m2; e = e2;
}
}).Start();
byte[] message = new byte[400];
while (true)
{
try
{
if (socket.Send(message) != message.Length)
Interlocked.Increment(ref _errorCount);
Interlocked.Increment(ref _messageCount);
}
catch (Exception e)
{
Interlocked.Increment(ref _errorCount);
//Console.WriteLine(Socket.Send failed: {0}{1}{2},
e.Message, Environment.NewLine, e.StackTrace);
}
}
}
}
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
[jira] [Comment Edited] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
[
https://issues.apache.org/jira/browse/LOG4NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13865444#comment-13865444
]
Dongsheng Song edited comment on LOG4NET-415 at 1/8/14 1:53 PM:
Loop send without syslog heades is wrong:
{code:borderStyle=solid}
buffer = this.Encoding.GetBytes(builder.ToString());
Int32 offset = 0;
while (offset != buffer.Length)
{
offset += this.Client.SendTo(buffer, offset,
buffer.Length - offset, SocketFlags.None,
this.RemoteEndPoint);
}
{code}
was (Author: dongsheng):
{code:borderStyle=solid}
buffer = this.Encoding.GetBytes(builder.ToString());
Int32 offset = 0;
while (offset != buffer.Length)
{
offset += this.Client.SendTo(buffer, offset,
buffer.Length - offset, SocketFlags.None,
this.RemoteEndPoint);
}
{code}
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)
[jira] [Comment Edited] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
[
https://issues.apache.org/jira/browse/LOG4NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13865444#comment-13865444
]
Dongsheng Song edited comment on LOG4NET-415 at 1/8/14 1:58 PM:
Loop send without syslog heades is wrong:
{code:borderStyle=solid}
buffer = this.Encoding.GetBytes(builder.ToString());
Int32 offset = 0;
while (offset != buffer.Length)
{
offset += this.Client.SendTo(buffer, offset,
buffer.Length - offset, SocketFlags.None,
this.RemoteEndPoint);
}
{code}
Since you had set Socket.Blocking to false, then Socket.sendTo can throw
exception due to this underlying error:
{quote}
WSAENOBUFS No buffer space is available.
{quote}
was (Author: dongsheng):
Loop send without syslog heades is wrong:
{code:borderStyle=solid}
buffer = this.Encoding.GetBytes(builder.ToString());
Int32 offset = 0;
while (offset != buffer.Length)
{
offset += this.Client.SendTo(buffer, offset,
buffer.Length - offset, SocketFlags.None,
this.RemoteEndPoint);
}
{code}
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)
[jira] [Comment Edited] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
[ https://issues.apache.org/jira/browse/LOG4NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13865015#comment-13865015 ] Dongsheng Song edited comment on LOG4NET-415 at 1/8/14 3:11 AM: Message lost testing with just set Blocking to false was (Author: dongsheng): Message lost testing with simple set Blocking to false 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 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)
