Nlog: Logs are dropped when sent over network with NLogViewer target

[stil]

Type : Bug
NLog version: 5.0.0-beta07
Platform: .NET Core
Current NLog config:

<?xml version="1.0" encoding="utf-8"?>

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
      autoReload="true"
      throwExceptions="false"
      internalLogLevel="Warn" internalLogFile="c:\temp\nlog-internal.log">

  <targets>
    <target name="log4view" xsi:type="NLogViewer" address="tcp://127.0.0.1:878" />
    <target xsi:type="ColoredConsole" name="console" layout="${longdate} ${logger} ${uppercase:${level}} ${message}" />
  </targets>

  <rules>
    <logger name="*" minlevel="Trace" writeTo="log4view,console" />
  </rules>
</nlog>

Steps to reproduce:

1. Create new Console App .NET Core project in VS2017. Install NLog 5.0.0-beta07.
2. Create following Main method.

using System;
using System.Threading.Tasks;
using NLog;

namespace ConsoleApp1
{
    internal class Program
    {
        private static readonly Logger Logger = LogManager.GetCurrentClassLogger();

        private static void Main(string[] args)
        {
            Parallel.For(0, 1000, i => { Logger.Debug($"#{i}"); });

            Console.ReadLine();
        }
    }
}

1. Start log4view and connect to tcp://127.0.0.1:878.

In case of a BUG:

What is the current result?

Only ~25% of the logs are received by log4view. Animated screenshot:

What is the expected result?

It should receive all 1000 logs. Console target receives all logs, but Network target (NLogViewer) somehow drops majority of logs.

Did you checked the Internal log?

Yes, I set level to Warn and it stays empty.

Are there any work arrounds?

I'm not aware of any.

Is there a version in which it did worked?

I don't know.

Can you help us by writing an unit test?

I'm not sure where the problem lies to begin with.

[304NotModified]

Hi!

Is it possible to check with NLog 4 for this?

I will also test this first in NLog 4.

[304NotModified]

See the same result on NLog4 and Log4view:

Dunno what the read errors are, and if this is a NLog of Log4view issue

[304NotModified]

added the tester here: https://github.com/NLog/NLog.TestCases

[304NotModified]

some things i noticed,

when settings

 internalLogLevel="Trace" internalLogFile="c:\temp\nlog-internal.log">

Most of the time (but not always), log4view gets 1000 records

In the internal log, there is always 1000 records

[304NotModified]

Other observations:

• when writing with a thread sleep, more messages are arriving
• when not logging to console, only 17 messages are succeeded (from the 1000)
  
• don't saw any error in the log
• when log4view is not enabled, the following error will be logged: Error Error when sending. Exception: System.IO.IOException: Error: ConnectionRefused (also exact 1000 times)
• when messages are lost, log4view shows "read errors", but 1 read error are multiple lost messages?

So I think it's a max connections in parallel thing.

[304NotModified]

• It seems it won't help to use the bufferingwrapper. Still testing though

[stil]

Network target has this onConnectionOverflow property, which is by default set to AllowNewConnnection. Is it however possible to configure it in NLogViewer target?

[304NotModified]

yes, good one. NLogViewerTarget inherits NetworkTarget, so NLogViewerTarget has all the NetworkTarget properties. (not clear in the docs I guess)

[304NotModified]

unfortunately OnConnectionOverflow="Block" MaxConnections="1" /> won't help much / at all

[304NotModified]

this seems to work :)

<?xml version="1.0" encoding="utf-8"?>

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
      autoReload="true"
      throwExceptions="true"
      internalLogLevel="Warn" internalLogFile="c:\temp\nlog-internal.log">

  <targets>


    <target name="log4view" xsi:type="NLogViewer" address="tcp://127.0.0.1:878" 
                 KeepConnection="false" OnConnectionOverflow="Block" MaxConnections="5" />

    <target xsi:type="ColoredConsole" name="console" layout="${longdate} ${logger} ${uppercase:${level}} ${message}" />
  </targets>

  <rules>
    <logger name="*" minlevel="Trace" writeTo="log4view" />
  </rules>
</nlog>

So, combo of KeepConnection="false" OnConnectionOverflow="Block" MaxConnections="5"

update:

• MaxConnections="50" also works
• MaxConnections="100" also works (multiple tests)
• MaxConnections="150" also works (multiple tests)
• MaxConnections="200" wont work

[stil]

Wow, it works for me too. Thank you so much for help.

Don't you think it's worth to override default values so it won't cause troubles for other people?

[304NotModified]

final recommendations:

• add the following properties: keepConnection="false" onConnectionOverflow="Block" maxConnections="100"
• don't use buffertarget
• ignore the XML validation errors in nlog.config when using the XSD

[304NotModified]

Closing this now in favor of 3 new Github issues :)

[snakefoot]

Alternative solution is just to enabled newLine="true":

<target name="log4view" xsi:type="NLogViewer" address="tcp://127.0.0.1:878" NewLine="true" />

Using KeepConnection="false" will increase allocations, and hurt performance.

[snakefoot]

Think the "message loss" issue is caused by Log4View receiving multiple LogEvents in a single TCP read, and instead of using the xml-format to seperate them, then it depends on newlines.

Thus multiple logevents are turned into a single logevent-chunk, giving the appearance of message-loss, but actually it is Log4View having problems with parsing these chunks and only showing the first logevent in the chunk.

Have tested that Log4View has no issues with additional newlines within a single log-event.

[snakefoot]

Tried using the Log2Console-viewer and it has no issues with keeping up, independent of using NewLine=true or false.

I guess Log4View is just a very sensitive application.