Last Log Entry is increasing the size of the file more than the limit

Topics: Logging Application Block
Jan 28, 2013 at 5:20 AM

Hi,

We have a log entry mechanism using EL 3.0. We have a rolling limit of 2 MB. It creates a new logfile after it reaches the limit. But recently I figured that if the last log file size is more than the specified limit, for e.g. 10MB, it is writing to the same file, by increasing the file size more than the limit.

 

Is there any way to write the log entry in separate files, instead of appending into the same.

Jan 28, 2013 at 5:55 AM

I don't see that behavior.  Are you using the out of the box RollingFlatFileTraceListener?  Are you sure that there isn't an error happening when attempting to roll the file? 

If you have an invalid roll file TimeStampPattern( e.g. "yyyy/MM/dd") then the roll will fail and the existing file will be appended to.

Perhaps you can post the configuration along with instructions that recreate the issue?

--
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to 

Jan 28, 2013 at 8:32 AM

If it fails, then it should fail at all cases.

 

It is writing remaining logs normally. After reaching the size limit, it is  creating a new file and writing to it. In this case also it is doing the same except that the last entry is large and it is creating after writing this large entry.

We kept the size limit to 2 MB. The log entry size  is 10MB. What is the expected behavior? In our case, it is writing all the data into one file, and increasing it to 11MB or so. Then for the next entry, it is creating new file.

The configuraition is added below.

<add fileName="SampleLog.log" rollSizeKB="2048"
    timeStampPattern="yyyy-MM-dd" rollFileExistsBehavior="Increment"
    rollInterval="Day" formatter="Custom Text Formatter" header="--------------------------------------"
    footer="----------------------------------------" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.RollingFlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null"
    traceOutputOptions="None" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.RollingFlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null"
    name="Sample" />

Jan 28, 2013 at 9:04 AM

The behavior you describe sounds correct.  LogEntries are written as a single unit.  When the file becomes greater than the RollSize  then the next log write will force a roll of the file.  So it's not really a size limit but a threshold to determine when to roll the file.

--
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to 

Jan 28, 2013 at 9:30 AM
Edited Jan 28, 2013 at 11:26 AM

Thanks @randylevy

So there is no way to split the message into two and fit it into new files?? Not even in EL 5.0??

If so, that  might be a hit to performance as it will take longer time to write to a larger file.

Jan 29, 2013 at 4:26 AM

Enterprise Library does not "split" LogEntry's in any scenario.  

Not sure if your performance concern is actually valid (as always, you should test).  

Scenario A:

  • Check if roll is necessary
  • Write out a 10MB LogEntry to a single file.  

Scenario B:

  • Check if roll is necessary
  • Write out partial 2MB LogEntry to file
  • Check if roll is necessary
  • Move file ("roll")
  • Open a new file
  • Write out partial 2MB LogEntry to file
  • Repeat as needed to log entire 10MB message.

If you really wanted to "split" messages then you could programmatically split the Message into multiple LogEntry's and then call Logger.Write multiple times (although that would also seem to me to be less performant).

--
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to