File not archiving when reaches to maximum size given in "archiveAboveSize"

[Vatsi]

In case of a BUG:

• What is the current result?
  File not archiving when reaches to maximum size given in "archiveAboveSize"

• What is the expected result?
  It should archive as per given size.

• Did you checked the Internal log?
  Yes. Nothing there.

• Please post full exception details (message, stacktrace, inner exceptions)

• Are there any work arrounds? yes/no
  None found for now.

• Is there a version in which it did worked?
  2.1

• Can you help us by writing an unit test?
  Let us know what kind of unit test required and I can provide.

Current version of NLog is 4.4.3.

Here is the NLog Section for reference.

<nlog autoReload="false" xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
		<targets>
			<target name="asyncWrapper" xsi:type="AsyncWrapper" queueLimit="5000" overflowAction="Grow">
				<target name="file" xsi:type="File" layout="${message}" filename="${gdc:logdir}/Log/xxxx.log" archiveFileName="${gdc:logdir}/Log/xxxx.{##}.log" archiveAboveSize="25194304" archiveNumbering="Rolling" concurrentWrites="true" maxArchiveFiles="50" keepFileOpen="true" encoding="iso-8859-2" enableFileDelete="false"></target>
			</target>
		</targets> 

in case of a FEATURE REQUEST:

• Why do we need it?
• An example of the XML config, if relevant.

[snakefoot]

@Vatsi Please give your nlog.config file, or how you configure the FileTarget using code.

Even better attach a small example project that reproduces the issue.

[304NotModified]

@Vatsi Please give your nlog.config file, or how you configure the FileTarget using code.

It was hidden in the post :)

[304NotModified]

@Vatsi could you test with a more limited feature set?

• remove the usage of gdc:logdir
• remove the keepFileOpen
• remove the maxArchiveFiles
• remote the concurrentWrites
• remove the asyncWrapper

Thanks in advance!

[Vatsi]

Hi... We tried with given changes...

After several configurations, we noticed that setting keepfileopen to false does the trick but that will not allow us to concurrentwrites, correct?

Also, we noticed that with every configuration, files were increasing in numbers than given max archive files.... Let me know if you need any more information...

Thanks for responding to my queries, I very much appreciate it...

Let me know if any more information is required from us.

Thanks,
Vatsal

[304NotModified]

After several configurations, we noticed that setting keepfileopen to false does the trick but that will not allow us to concurrentwrites, correct?

You can still concurrently write to it. :)

Thanks, will try to fix this for the next release.

[snakefoot]

@Vatsi keepfileopen=false will give lots of memory allocations for every logevent, so it will be poison for any long running application, that is doing a reasonable amount of logging.

Maybe the problem is enableFileDelete="false" ?

Tried your exact nlog.config with NLog 4.5-RC and it also fails to roll correctly when many processes, but if I remove enableFileDelete="false" then it just works.

[jonreis]

I am having the same issue with archiving by date. My settings are:

fileName="${specialFolder:folder=CommonApplicationData}\ConnexionV14\logs\Connexion.txt" archiveNumbering="Date" archiveEvery="Day" archiveDateFormat="yyyyMMdd" maxArchiveFiles="30" keepFileOpen="true"

When the date rolls, NLog still logs to Connexion.txt. No archive files are ever created.

I believe this problem has been around since 2015. We switch to WCF logging to work around this issue and I just switched it back to shared logfile logging to see if had been resolved.

Old Issue: Writing to the same file from multiple processes does not function when concurrentWrites="true" and keepFileOpen="true" #1029

[snakefoot]

@jonreis Could you try with NLog 4.5-rc06, and ensure that enableFileDelete="true" ?

If you can create a test-application that reproduces the issue with NLog 4.5-rc06, then it would be very helpful.

[jonreis]

@sean-gilliam Here is the test application, but please don't bother with it. I cannot seem to reproduce it out side of my application. I will have to assume that the issue is on my side and not NLog. Sorry for the false report.

ConcurrentFileTargetTest.zip

[snakefoot]

@jonreis No problem. Have been making lots of changes to NLog 4.5 to prevent issues with locked file handles stopping the archive logic. Where I have used your test application to test. Unit tests have also been added to validates that the archive logic can be trusted in a concurrent process scenario.

[snakefoot]

@304NotModified Since the issue can no longer be reproduced with latest NLog, then it should probably be resolved.

[jonreis]

We haven't seen it so I am for closing it.

[304NotModified]

Closing for now. Please let me know if the issue is there again.