Re: [jira] [Commented] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
Hi Stefan, Unfortunately, I am still learning all the fine points of log4net to understand these issues with this appender but I'm willing to help you out with testing and such with what I can. If you tell me what to test, I can test it on a few different platforms (OpenSuSE/Mono, OS X/Mono, WinXp/.NET, etc). Who knows, I may even be able to send a patch or two if possible. :) Thanks, Ryan On Thu, Apr 5, 2012 at 10:31 PM, Stefan Bodewig (Commented) (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248077#comment-13248077 > ] > > Stefan Bodewig commented on LOG4NET-27: > --- > > This issue may be the one with the most votes, but of you search around JIRA > you'll see RollingFileAppender is broken in so many ways. I think it is > responsible for about a third of all reports. > > Last summer when we waded through the issues to triage what should go into > 1.2.11 I deliberately left out all RFE issues as - to be honest - I don't > think it can be fixed without rewriting it. Back then some people started to > work on a new implementation so this decision seemed to be a good one. > > Unfortunately life has interfered with the efforts of back then, as with the > time I can devote to log4net myself. I'll look into the latest incarnation > of this patch but honestly would prefer a re-thought and re-written RFA > myself. > > Are there enough people watching this issue who would actually be able to > build log4net from svn trunk to verify it fixes their problem (and doesn't > introduce new ones) before I'd cut a new release? > >> Rolling files on date/time boundaries doesn't support a maximum number of >> backup files. >> --- >> >> Key: LOG4NET-27 >> URL: https://issues.apache.org/jira/browse/LOG4NET-27 >> Project: Log4net >> Issue Type: New Feature >> Components: Appenders >> Affects Versions: 1.2.11 >> Reporter: Florian Ramillien >> Priority: Minor >> Fix For: 1.2 Maintenance Release >> >> Attachments: LOG4NET-27.patch, RollingFileAppender.cs, >> RollingFileAppender.cs, RollingFileAppender.cs, >> RollingFileAppender.cs.patch, RollingFileAppender.patch >> >> >> A maximum of backup files exist when rolling files on file size, but not for >> rolling on date/time. >> This can be implemented with the same config key : MaxSizeRollBackups > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > >
[jira] [Commented] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248085#comment-13248085 ] Stefan Bodewig commented on LOG4NET-27: --- One problem I see is that the file added 26/Apr/11 is not licensed to the ASF, so I must not use it to patch trunk. This leads to the unfortunate situation where I'll have to evaluate Jochen's patch of Feb 2012 whether it seems to be based on the Apr 2011 version - or just the older patches. This sounds messy and probably is, but the ASF certainly will not publish code of other people who don't allow it to do. > Rolling files on date/time boundaries doesn't support a maximum number of > backup files. > --- > > Key: LOG4NET-27 > URL: https://issues.apache.org/jira/browse/LOG4NET-27 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.11 >Reporter: Florian Ramillien >Priority: Minor > Fix For: 1.2 Maintenance Release > > Attachments: LOG4NET-27.patch, RollingFileAppender.cs, > RollingFileAppender.cs, RollingFileAppender.cs, RollingFileAppender.cs.patch, > RollingFileAppender.patch > > > A maximum of backup files exist when rolling files on file size, but not for > rolling on date/time. > This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248077#comment-13248077 ] Stefan Bodewig edited comment on LOG4NET-27 at 4/6/12 5:32 AM: --- This issue may be the one with the most votes, but if you search around JIRA you'll see RollingFileAppender is broken in so many ways. I think it is responsible for about a third of all reports. Last summer when we waded through the issues to triage what should go into 1.2.11 I deliberately left out all RFA issues as - to be honest - I don't think it can be fixed without rewriting it. Back then some people started to work on a new implementation so this decision seemed to be a good one. Unfortunately life has interfered with the efforts of back then, as with the time I can devote to log4net myself. I'll look into the latest incarnation of this patch but honestly would prefer a re-thought and re-written RFA myself. Are there enough people watching this issue who would actually be able to build log4net from svn trunk to verify it fixes their problem (and doesn't introduce new ones) before I'd cut a new release? was (Author: bodewig): This issue may be the one with the most votes, but of you search around JIRA you'll see RollingFileAppender is broken in so many ways. I think it is responsible for about a third of all reports. Last summer when we waded through the issues to triage what should go into 1.2.11 I deliberately left out all RFE issues as - to be honest - I don't think it can be fixed without rewriting it. Back then some people started to work on a new implementation so this decision seemed to be a good one. Unfortunately life has interfered with the efforts of back then, as with the time I can devote to log4net myself. I'll look into the latest incarnation of this patch but honestly would prefer a re-thought and re-written RFA myself. Are there enough people watching this issue who would actually be able to build log4net from svn trunk to verify it fixes their problem (and doesn't introduce new ones) before I'd cut a new release? > Rolling files on date/time boundaries doesn't support a maximum number of > backup files. > --- > > Key: LOG4NET-27 > URL: https://issues.apache.org/jira/browse/LOG4NET-27 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.11 >Reporter: Florian Ramillien >Priority: Minor > Fix For: 1.2 Maintenance Release > > Attachments: LOG4NET-27.patch, RollingFileAppender.cs, > RollingFileAppender.cs, RollingFileAppender.cs, RollingFileAppender.cs.patch, > RollingFileAppender.patch > > > A maximum of backup files exist when rolling files on file size, but not for > rolling on date/time. > This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248077#comment-13248077 ] Stefan Bodewig commented on LOG4NET-27: --- This issue may be the one with the most votes, but of you search around JIRA you'll see RollingFileAppender is broken in so many ways. I think it is responsible for about a third of all reports. Last summer when we waded through the issues to triage what should go into 1.2.11 I deliberately left out all RFE issues as - to be honest - I don't think it can be fixed without rewriting it. Back then some people started to work on a new implementation so this decision seemed to be a good one. Unfortunately life has interfered with the efforts of back then, as with the time I can devote to log4net myself. I'll look into the latest incarnation of this patch but honestly would prefer a re-thought and re-written RFA myself. Are there enough people watching this issue who would actually be able to build log4net from svn trunk to verify it fixes their problem (and doesn't introduce new ones) before I'd cut a new release? > Rolling files on date/time boundaries doesn't support a maximum number of > backup files. > --- > > Key: LOG4NET-27 > URL: https://issues.apache.org/jira/browse/LOG4NET-27 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.11 >Reporter: Florian Ramillien >Priority: Minor > Fix For: 1.2 Maintenance Release > > Attachments: LOG4NET-27.patch, RollingFileAppender.cs, > RollingFileAppender.cs, RollingFileAppender.cs, RollingFileAppender.cs.patch, > RollingFileAppender.patch > > > A maximum of backup files exist when rolling files on file size, but not for > rolling on date/time. > This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-266) AdoNetAppender does not work on a IIS 7 website using Windows authentication
[
https://issues.apache.org/jira/browse/LOG4NET-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247708#comment-13247708
]
Johannes Krackowizer commented on LOG4NET-266:
--
I have analyzed this problem, it occurs only under very special conditions but
there is a simple workaround.
If you use an application pool in integrated mode on iis 7 or 7.5 and if
windows authentication is activated and if the http request starts threads and
this threads use log4net.
As seen in this scenario i'm working with (MVC 3 Web Application):
1. The HTTP request start and the MVC Controller starts.
2. In the controller we start a long running background thread (in my case a
lot of work in the database)
3. The MVC controller completes and after that the view is rendered and send
back to the client.
4. System.Threading.Thread.CurrentPrincipal is disposed by iis.
5. The long running background thread tries to log something and an
System.ObjectDisposedException occurs in Core\LoggingEvent.cs:885
if (System.Threading.Thread.CurrentPrincipal != null &&
System.Threading.Thread.CurrentPrincipal.Identity != null &&
System.Threading.Thread.CurrentPrincipal.Identity.Name != null)
The third part will fail because the getter of .Name will throw an exception.
The simplest workaround is to set new CurrentPrincipal if you start a new
background thread. E.g.:
System.Threading.Thread asyncWorker = new System.Threading.Thread(
LongRunningTasks );
asyncWorker.Start( System.Security.Principal.WindowsIdentity.GetCurrent() );
private void LongRunningTasks( object identity )
{
System.Security.Principal.WindowsIdentity windowsIdentity = identity as
System.Security.Principal.WindowsIdentity;
System.Security.Principal.WindowsImpersonationContext impersonationContext =
null;
if ( windowsIdentity != null )
{
System.Threading.Thread.CurrentPrincipal = new
System.Security.Principal.WindowsPrincipal( windowsIdentity );
impersonationContext = windowsIdentity.Impersonate();
}
// Do your work.
if ( impersonationContext != null )
impersonationContext.Undo();
}
I'm not sure how this should be fixed in the source.
But the simplest way would be to catch the System.ObjectDisposedException in
the getter of LoggingEvent.Identity in file Core\LoggingEvent.cs and set
m_data.Identity = "" like if System.Threading.Thread.CurrentPrincipal would be
null. I think this would be the correct way because iis tries to dispose the
CurrentPrincipal but stops before the work is done.
> AdoNetAppender does not work on a IIS 7 website using Windows authentication
> -
>
> Key: LOG4NET-266
> URL: https://issues.apache.org/jira/browse/LOG4NET-266
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.10
> Environment: Windows Server 2008, IIS 7, ASP.Net Framework v4.0, Sql
> Server 2008, Windows Authentication Activated
>Reporter: Kaider
>Priority: Critical
> Fix For: 1.2 Maintenance Release
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When the Windows Authentication is deactivated, the AdoNetAppender works
> properly.
> Howerver, once the Windows authentication is activated, the AdoNetAppender
> start working properly and then, after a few seconds, it is aborted and the
> following error message is retrieved:
> log4net:ERROR [AdoNetAppender] Failed in DoAppend
> System.ObjectDisposedException: Safe handle has been closed
>at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean&
> success)
>at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle,
> Boolean& success)
>at Microsoft.Win32.Win32Native.GetTokenInformation(SafeTokenHandle
> TokenHandle, UInt32 TokenInformationClass, SafeLocalAllocHandle
> TokenInformation, UInt32 TokenInformationLength, UInt32& ReturnLength)
>at
> System.Security.Principal.WindowsIdentity.GetTokenInformation(SafeTokenHandle
> tokenHandle, TokenInformationClass tokenInformationClass)
>at System.Security.Principal.WindowsIdentity.get_User()
>at System.Security.Principal.WindowsIdentity.GetName()
>at System.Security.Principal.WindowsIdentity.get_Name()
>at log4net.Core.LoggingEvent.get_Identity()
>at log4net.Core.LoggingEvent.FixVolatileData(FixFlags flags)
>at log4net.Appender.BufferingAppenderSkeleton.Append(LoggingEvent
> loggingEvent)
>at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent loggingEvent)
> See below the settings of the appender. Various options (i.e. Securitycontext
> ) have also been tested in vain.
> type="log4net.Appender.AdoNetAppender">
>
>
>
>
>
>
>
RE: [jira] [Commented] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
They just got the ball rolling in the last year - resubmit! -Original Message- From: Joshua Masek (Commented) (JIRA) [mailto:j...@apache.org] Sent: Thursday, April 05, 2012 9:54 AM To: log4net-dev@logging.apache.org Subject: [jira] [Commented] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files. [ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247313#comment-13247313 ] Joshua Masek commented on LOG4NET-27: - What I originally submitted (and looks like it has been made into a patch), I have been running in production for close to 3 years (against the 1.2.10 version), and am not aware of any issues with it. Seems to be working, and nobody has had a harddisk fill up with logs (and I log heavily). I don't know if there are any concerns that have prevented it being in the trunk. My guess is that development on log4net has been minimal (considering it took 5 years to have a new minor version release), and may have something to do with this. Also in my opinion, it isn't simple to resolve cleanly (I did my best) and maybe there is still thought to be put into it. What I provided wasn't necessarily even me recommending it to be in the trunk, but rather just something people could use to get around the limitation. > Rolling files on date/time boundaries doesn't support a maximum number of > backup files. > --- > > Key: LOG4NET-27 > URL: https://issues.apache.org/jira/browse/LOG4NET-27 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.11 >Reporter: Florian Ramillien >Priority: Minor > Fix For: 1.2 Maintenance Release > > Attachments: LOG4NET-27.patch, RollingFileAppender.cs, > RollingFileAppender.cs, RollingFileAppender.cs, RollingFileAppender.cs.patch, > RollingFileAppender.patch > > > A maximum of backup files exist when rolling files on file size, but not for > rolling on date/time. > This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
[jira] [Commented] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247313#comment-13247313 ] Joshua Masek commented on LOG4NET-27: - What I originally submitted (and looks like it has been made into a patch), I have been running in production for close to 3 years (against the 1.2.10 version), and am not aware of any issues with it. Seems to be working, and nobody has had a harddisk fill up with logs (and I log heavily). I don't know if there are any concerns that have prevented it being in the trunk. My guess is that development on log4net has been minimal (considering it took 5 years to have a new minor version release), and may have something to do with this. Also in my opinion, it isn't simple to resolve cleanly (I did my best) and maybe there is still thought to be put into it. What I provided wasn't necessarily even me recommending it to be in the trunk, but rather just something people could use to get around the limitation. > Rolling files on date/time boundaries doesn't support a maximum number of > backup files. > --- > > Key: LOG4NET-27 > URL: https://issues.apache.org/jira/browse/LOG4NET-27 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.11 >Reporter: Florian Ramillien >Priority: Minor > Fix For: 1.2 Maintenance Release > > Attachments: LOG4NET-27.patch, RollingFileAppender.cs, > RollingFileAppender.cs, RollingFileAppender.cs, RollingFileAppender.cs.patch, > RollingFileAppender.patch > > > A maximum of backup files exist when rolling files on file size, but not for > rolling on date/time. > This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247255#comment-13247255 ] Piotr Jastrząbek commented on LOG4NET-27: - This is the most popular issue right now :( according to https://issues.apache.org/jira/browse/LOG4NET#selectedTab=com.atlassian.jira.plugin.system.project%3Apopularissues-panel Guys, have you been using patched version on production? Is sth. wrong with this patch that it still not present in trunk? > Rolling files on date/time boundaries doesn't support a maximum number of > backup files. > --- > > Key: LOG4NET-27 > URL: https://issues.apache.org/jira/browse/LOG4NET-27 > Project: Log4net > Issue Type: New Feature > Components: Appenders >Affects Versions: 1.2.11 >Reporter: Florian Ramillien >Priority: Minor > Fix For: 1.2 Maintenance Release > > Attachments: LOG4NET-27.patch, RollingFileAppender.cs, > RollingFileAppender.cs, RollingFileAppender.cs, RollingFileAppender.cs.patch, > RollingFileAppender.patch > > > A maximum of backup files exist when rolling files on file size, but not for > rolling on date/time. > This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
