[ 
https://issues.apache.org/jira/browse/LOG4NET-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roy Chastain updated LOG4NET-285:
---------------------------------

         Priority: Minor  (was: Blocker)
    Fix Version/s:     (was: 1.2.11)
                   2.0

What you describe sounds like an unsupportable configuration.  It is certainly 
something that cannot be resolved in the 1.2.11 timeframe, so we are dropping 
this issue's priority and changing it to a future version so that it may be 
further reviewed.

I have a couple of suggested workarounds.
1) - Change to different files (and/or directories) for each program and have 
script/program that merges them together by time stamp.
2) - Use one of the "remote" appenders, TelnetAppender, RemoteSyslogAppender or 
RemotingAppender, to forward your logs to an 11th program that can write the 
composite log file.


> Issue with rolling based on a date
> ----------------------------------
>
>                 Key: LOG4NET-285
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-285
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>    Affects Versions: 1.2.10
>         Environment: windows server 2003,dotnet framework3.5, wcf services
>            Reporter: kinnar
>            Priority: Minor
>              Labels: build
>             Fix For: 2.0
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Hi,
> We are having 10 programs which are rolling into same log file 
>  namlely "logger.log".
>  Below is configuration of RollingFileAppender which we are using :
>    <appender name="RollFile" type="log4net.Appender.RollingFileAppender">
>      <threshold value ="ALL"/>
>      <file value="C:\logger.log" />
>      <param name="LockingModel" 
> type="log4net.Appender.FileAppender+MinimalLock" />
>      <appendToFile value="true" />
>      <maximumFileSize value="1GB" />
>      <staticLogFileName value="true"/>
>      <maxSizeRollBackups value="5" />
>      <datePattern value=".yyyy-MM-dd-tt&quot;.log&quot;"/>
>      <rollingStyle value="Composite" />
>      <layout type="log4net.Layout.PatternLayout">
>      </layout>
>    </appender>
>  Our rolling based on date is running at every 12 hour span means 
>  at 12 Noon and 12 Midnight. Now what is happening when multiple 
>  programs try to log into log file at the same time when rolling happens 
> means 
>  at 12 noon/midnight, then size of file getting rolled is becoming very 
>  small compare to original file size(i.e Suppose logger.log is 
>  around 1 MB at 12 noon, when rolling happens the new rolled file which is 
> get 
>  generated is around 3 KB or somewhat). So, almost data get lost due to this. 
>  This is basically happening when multiple programs try to log into log 
>  file at the same time of when rolling happens(means at 12 noon/midnight).
> Debugging Info:
> ============
>  I have debug this issue by enabling debugging in  log4net. What is happing 
> when 2 or more programs try to log into log file at time of roll time means 
> at 12 midnight/12 noon, then from first program call RollOverTime() function 
> in log4net source code gets called. It will in turn call RollFile() , which 
> in turn check whether rolled file with particular date and time exist, if yes 
> then its deleting that file and creating new roll file with particular date 
> and time and moving content of original log file into new roll log file. Till 
> now its fine. But as second request for logging comes at same time means at 
> 12 midnight/12 noon , it will also call RolloverTime(), then RollFile(), 
> which in turn find rolled file with particular date and time. so, it will 
> delete that rolled file with particular and date and create a new roll file 
> and move content of original log file into it.At that time original log file 
> contains very less data. So, thats why size of rolled log file is becoming 
> very low. Very less size of rolled file is a major issue of it . 
> All of you might get my whole debugging description described above. Please 
> revert back to us on this ASAP as its very important us to go ahead.
> Regards,
> Kinnar

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to