This project is read-only.

Async Wrapper is not working


Hi All,

We are getting different behaviors when enabling Aync logging by using AsyncWrapper. As I know there are 2 ways to enable this.
  1. by using <targets async =" true">
  2. by providing a new target by using <target name="asyncWrapper" xsi:type="AsyncWrapper" queueLimit="5000" overflowAction="Grow">
The option 1 is fast and i can see that my logs are written on a different thread. I can see that 50000 log messages are being written when program control comes back. The only problem here is, log messages are lost.

The option 2 is not at all working. It seems that NLog writes messages synchronously and doesn't return control.

Are we missing any NLog specific configuration for option number 2?

Attached is the configuration file I am using.


file attachments


Harshil13 wrote Apr 23, 2013 at 1:30 PM

We have also observed the same behaviour. However, the actual behaviour is asyncWrapper doesn't work asynchronously and to make the code async, we have to have <targets async =" true"> set, which in turns overwrites all underlying setting at <target xsi:type="File" .... /> level. In such cases it mandates the default settings.

Is this bug?


wrote Apr 23, 2013 at 1:31 PM

wrote Apr 23, 2013 at 1:34 PM

jagrutpatel wrote Apr 23, 2013 at 1:42 PM

Ditto issue!

Is AsyncWrapper async at all? I don't see any difference with or without this target. It takes almost same time to log, say 50K messages. What is the correct way to achieve async logging using AsyncWrapper? For me OverFlowAction = Grow is important parameter.

I then tried "async=true". It is truly async. But alas! There is data loss. Not all log messages got logged even if the application is running. Is this because by default OverFlowAction is Discard so log messages that exceed the default queueLimit will be dropped?

jkowalski wrote Apr 23, 2013 at 5:14 PM

You need to fix your rules. Instead of writeTo="file" you need to say writeTo="asyncWrapper". Right now you're not really using the wrapper.

powertoy wrote Apr 24, 2013 at 1:44 PM

Thanks a lot Jaroslaw. It worked! Now I am facing another issue. Consider following scenario. 1. I am starting 5 applications logging 30,000 messages each. 2. I am expecting 1,50,000 messages at the end in the final log file. Applications are sharing the same log file. 3. I am leveraging concurrentWrites = true and keepFileOpen = true. Now the problem is, we are not getting 1,50,000 messages logged at the end. We have around 1,30,000 messages and other messages are lost. I am closing all applications once all logs are written to the file and I am also calling LogManager.Flush(); at the end. __Are we again missing any configuration here?__ Following is my configuration. <nlog xmlns="" xmlns:xsi=""> <targets> <target name="asyncWrapper" xsi:type="AsyncWrapper" queueLimit="5000" overflowAction="Grow"> <target name="file" xsi:type="File" layout="${message}" fileName="${basedir}/../Log/Test.log" archiveFileName="${basedir}/../Log/Test.{#####}.log" archiveAboveSize="4194304" archiveNumbering="Rolling" concurrentWrites="true" maxArchiveFiles="10000" keepFileOpen="true" encoding="iso-8859-2" /> </target> </targets> <rules> <logger name="*" minlevel="Info" writeTo="asyncWrapper"/> </rules> </nlog>

ccahdw wrote Jun 20, 2013 at 12:57 PM

Once I wrapped my FileTarget in an AsyncTargetWrapper my time to write went from 100ms to 31000.

This is the code:

public IAmALogEntry LogEntry { get; set; }
public LoggingConfiguration Configuration { get; set; }
public LogLevel NLogLevel { get; set; }

var asyncWrapper = new AsyncTargetWrapper(target) {OverflowAction = AsyncTargetWrapperOverflowAction.Grow};
Configuration.AddTarget(targetName, asyncWrapper);
var rule = new LoggingRule("*", NLogLevel, asyncWrapper);

I've had to go back to:
Configuration.AddTarget(targetName, target);
var rule = new LoggingRule("*", NLogLevel, target);

I'd appreciate any ideas on why this is the case?


wrote Jun 20, 2013 at 3:51 PM

johnnyjob wrote Dec 4, 2013 at 11:19 AM

I noticed lost messages too in NLog 2.0. This framework just drives me crazy, considering migration from it in the nearest future. Serious bugs are not fixed for months.

wrote Dec 4, 2013 at 11:19 AM