logging takes forever when archiving has hit maxint counter

3 messages Options
Embed this post
Permalink
mtijn1977

logging takes forever when archiving has hit maxint counter

Reply Threaded More More options
Print post
Permalink
Hi,

I also filed this bug on SourceForge under #2847706 in the Issue Tracker Bugs section.
I'm reposting here because I'm not sure where to get the best response quickly.
So here we go again:

When file archiving has been enabled and
 archiving to files with a counter and
 counter has reached maxint, then
  logging takes very looooong to complete and
  nothing is archived anymore.

My log and archive settings for file target are:
<target name="filelog" xsi:type="AutoFlushWrapper">
<target xsi:type="File"
FileName="${basedir}/logs/YourApplicationName.txt"
Layout="${longdate}|${level:uppercase=true}|(${logger}) ${message} ${exception:format=message}"
ArchiveFileName="${basedir}/logs/archives/YourApplicationName.{##}.txt"
ArchiveAboveSize="64"
ArchiveNumbering="FileTarget.ArchiveNumberingMode.Sequence"
MaxArchiveFiles="3"
ConcurrentWrites="false" />
</target>

ArchiveAboveSize set to 64 bytes for testing purposes.
mtijn1977

Re: logging takes forever when archiving has hit maxint counter

Reply Threaded More More options
Print post
Permalink
Let me add the expected behavior to this report:
I expected numbering to restart from 0.

Let me add how I got to test this in the first place:
I was looking for new ways to make MaxArchiveFiles only archive as many files as indicated.
Previously I used a date variable in my archived filenames but that screwed up MaxArchiveFiles.
MaxArchiveFiles would only limit today's archived files to the indicated amount.
But I was looking for a kind of MaxArchiveFiles attribute to limit ALL archived files.
Getting rid of the date component and just sticking to counters did not seem to work out thanks to the bug I just mentioned.
Jaroslaw Kowalski

Re: logging takes forever when archiving has hit maxint counter

Reply Threaded More More options
Print post
Permalink
It seems to me that the number of "#" characters in your config is very small (only 2). Is this intentional?
Are you expecting numbering to go like this?
 
YourApplicationName.95
YourApplicationName.96
YourApplicationName.97
YourApplicationName.98
YourApplicationName.99
YourApplicationName.00
YourApplicationName.01
YourApplicationName.02
...
 
Jarek

On Mon, Aug 31, 2009 at 6:25 AM, mtijn1977 (via Nabble) - No Reply <[hidden email]> wrote:
Let me add the expected behavior to this report:
I expected numbering to restart from 0.

Let me add how I got to test this in the first place:
I was looking for new ways to make MaxArchiveFiles only archive as many files as indicated.
Previously I used a date variable in my archived filenames but that screwed up MaxArchiveFiles.
MaxArchiveFiles would only limit today's archived files to the indicated amount.
But I was looking for a kind of MaxArchiveFiles attribute to limit ALL archived files.
Getting rid of the date component and just sticking to counters did not seem to work out thanks to the bug I just mentioned.