RE: TPL DataFlows

2011-09-28 Thread Dominik Psenner
Hey Ron,

 

I actually implemented something similar in a product we're distributing.
There I used plain delegates (lambda expressions) in favour of not having a
dependency to the TPL library, but that's not the big deal anyway. It works
astonishingly well, but I had to add a small safety condition:

 

Since the creation of asynchronous logging events is extremely fast and
blocks the application almost for no-time, any application could possibly
overflow the logging facility with so much events that it can't handle them
anymore. The result is that the queues grow and grow until the application
goes out of memory.

 

The solution I made is simple, but effective. Before the logging event is
processed asynchronously, I check the queue size and decide there if I
should block the calling application for a small portion of time per logging
event. I.e. something similar to this:

 

public void QueueUserWorkItem(T item)

{

   bool blockInvoker = false;

   int blockTime = 0;

 

   lock (itemsLock)

   {

   // queue the item

   items.Enqueue(item);

 

   if (items.Count > 1000)

   {

   blockInvoker =
true;

   if (items.Count >
100)

 
blockTime = 10;

   else if
(items.Count > 50)

 
blockTime = 5;

   else if
(items.Count > 25)

 
blockTime = 3;

   else if
(items.Count > 10)

 
blockTime = 2;

   else if
(items.Count > 5)

 
blockTime = 1; // actually block the application

   else if
(items.Count > 1)

 
blockTime = 0; // give another thread the chance to get the cpu

   }

   }

 

   // out of any lock (such that we dont
lock ourselves) block the invoker

   if (blockInvoker)

   {

   Thread.Sleep(blockTime);

   }

}

 

This gradually slows the calling application and works pretty fine if one
does stupid things like:

 

while (true) {

  logger.Info("yehaw");

}

 

JMTC,

Dominik

 

  _  

From: Ron Grabowski [mailto:rongrabow...@yahoo.com] 
Sent: Thursday, September 29, 2011 5:59 AM
To: log4net-dev
Subject: TPL DataFlows

 

Has anyone played around with TPL DataFlows yet? It looks like it could be
next step beyond using a concurrent queue for async message processing. Once
a log event has had the appropriate thread specific properties evaluated it
could be posted to a BroadcastBlock which would asynchronously post the
message to appenders:

 

http://weblogs.asp.net/mjarguello/archive/2011/03/15/asynchrony-in-c-5-dataf
low-async-logger-sample.aspx

 

 

 

 



TPL DataFlows

2011-09-28 Thread Ron Grabowski
Has anyone played around with TPL DataFlows yet? It looks like it could be next 
step beyond using a concurrent queue for async message processing. Once a log 
event has had the appropriate thread specific properties evaluated it could be 
posted to a BroadcastBlock which would asynchronously post the message to 
appenders:


http://weblogs.asp.net/mjarguello/archive/2011/03/15/asynchrony-in-c-5-dataflow-async-logger-sample.aspx

RE: unsubscribe

2011-09-28 Thread Dominik Psenner
log4net-dev-unsubscr...@logging.apache.org

 

  _  

From: Frank Watkins [mailto:fwatk...@rals.com] 
Sent: Wednesday, September 28, 2011 4:10 PM
To: Log4NET Dev
Subject: RE: unsubscribe

 

 

 

Thanks,

 

Frank 

 

Product Verification Test

Medical Automation Systems

E-mail:   fwatk...@rals.com

Business Phone #: 434-951-2926

Internal Phone: x3043

 

  _  

From: Walden H. Leverich [mailto:wald...@techsoftinc.com] 
Sent: Wednesday, September 28, 2011 10:08 AM
To: log4net-dev@logging.apache.org
Subject: unsubscribe

 

unsubscribe

 


-- 
Walden H Leverich III
Tech Software & 

BEC - IRBManager
(516) 627-3800 x3051
wald...@techsoftinc.com
http://www.TechSoftInc.com  
http://www.IRBManager.com  


Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)

 



RE: unsubscribe

2011-09-28 Thread Frank Watkins


Thanks,

Frank

Product Verification Test
Medical Automation Systems
E-mail: fwatk...@rals.com
Business Phone #: 434-951-2926
Internal Phone: x3043


From: Walden H. Leverich [mailto:wald...@techsoftinc.com]
Sent: Wednesday, September 28, 2011 10:08 AM
To: log4net-dev@logging.apache.org
Subject: unsubscribe

unsubscribe


--
Walden H Leverich III
Tech Software &
BEC - IRBManager
(516) 627-3800 x3051
wald...@techsoftinc.com
http://www.TechSoftInc.com
http://www.IRBManager.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)



unsubscribe

2011-09-28 Thread Walden H. Leverich
unsubscribe


--
Walden H Leverich III
Tech Software &
BEC - IRBManager
(516) 627-3800 x3051
wald...@techsoftinc.com
http://www.TechSoftInc.com
http://www.IRBManager.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)



[jira] [Commented] (LOG4NET-208) RollingFileAppender does not delete file when RollingStyle = log4net.Appender.RollingFileAppender.RollingMode.Once

2011-09-28 Thread Dominik Psenner (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LOG4NET-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116489#comment-13116489
 ] 

Dominik Psenner commented on LOG4NET-208:
-

Would You please provide us with some more information? For a start we would 
like to know which file you are expectecting to be deleted?

> RollingFileAppender does not delete file when RollingStyle = 
> log4net.Appender.RollingFileAppender.RollingMode.Once
> --
>
> Key: LOG4NET-208
> URL: https://issues.apache.org/jira/browse/LOG4NET-208
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
> Environment: Windows Xp SP3
>Reporter: Alain Dupont
>Priority: Minor
> Fix For: 1.2 Maintenance Release
>
>
> The RollingFileAppender does not delete file when RollingStyle = 
> log4net.Appender.RollingFileAppender.RollingMode.Once or when then append 
> attribut is set to false.

--
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-226) Allow to specify file name as wildcard pattern

2011-09-28 Thread Dominik Psenner (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LOG4NET-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116465#comment-13116465
 ] 

Dominik Psenner commented on LOG4NET-226:
-

I would target this issue only in the reimplementation of the RFA. What do you 
think Stefan?

> Allow to specify file name as wildcard pattern
> --
>
> Key: LOG4NET-226
> URL: https://issues.apache.org/jira/browse/LOG4NET-226
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 1.2.9, 1.2.10, 1.2.11
> Environment: Windows
>Reporter: Maxim Fateev
> Fix For: 1.2 Maintenance Release
>
>
> Change 707809 fixes issue with windows file name extension. 
> From filename.txt.1, filename.txt.2 it changes it to filename.1.txt, 
> filename.2.txt. 
> But it is still limiting form some use cases. I need to integrate logs with 
> existing logging infrastucture that requires file names to be filename_0.log, 
> filename_1.log.
> I propose to add additional property to specify filename as a format pattern. 
> I recommend using standard .net string format. So in my case file name would 
> be filename_{0}.log.
> It would also support other cases like requirement for filename to be 
> filename_00.log, filename_01.log. Just specify format as filename_{00}.log
> Also property to specify initial counter value is necessary to support my use 
> case.

--
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-280) Rolling appender doesnt roll 0kb file, configured to roll on date.

2011-09-28 Thread Dominik Psenner (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LOG4NET-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116444#comment-13116444
 ] 

Dominik Psenner commented on LOG4NET-280:
-

I maybe understood why this doesn't work:

If there are no events to be handled by the appender, the rolling algorithm is 
never invoked and thus the file won't be rolled until there's a logging event 
to be written into that file. To implement this feature, we would require a 
worker thread that is synchronized with the appender. Is this really worth the 
effort?

> Rolling appender doesnt roll 0kb file, configured to roll on date.
> --
>
> Key: LOG4NET-280
> URL: https://issues.apache.org/jira/browse/LOG4NET-280
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
> Environment: asp.net 2.0
>Reporter: Naveen Jakkur Muniraju
>Priority: Blocker
> Fix For: 1.2 Maintenance Release
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> We are using a log4net version 1.2.10.1. We have a web application in which 
> we are using log4net rolling appender for application logging. 
> However the files which are 0Kb is not rolling on a daily basis. Below is the 
> configuration we are using. It's configured to roll on a date basis. 
> The logs which are >0kb are rolling fine.
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> Any help ASAP will be appreciated. 

--
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




Re: I will not be working on RFA Next Gen

2011-09-28 Thread Stefan Bodewig
On 2011-09-28, Roy Chastain wrote:

> Best of luck to all.

Sorry to hear that.

Stefan


RE: I will not be working on RFA Next Gen

2011-09-28 Thread Dominik Psenner
>Best of luck to all.

Sad news, I wish you the best!



I will not be working on RFA Next Gen

2011-09-28 Thread Roy Chastain
Best of luck to all.

--
Roy Chastain






[jira] [Assigned] (LOG4NET-291) RollingFileAppender not working correctly when using DatePattern containing >= 1 uppercase character in date format string literal

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-291:


Assignee: (was: Roy Chastain)

> RollingFileAppender not working correctly when using DatePattern containing 
> >= 1 uppercase character in date format string literal
> --
>
> Key: LOG4NET-291
> URL: https://issues.apache.org/jira/browse/LOG4NET-291
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.9, 1.2.10, 1.2.11
> Environment: N.A.
>Reporter: Lee Chun Kit
>Priority: Minor
>  Labels: bug
> Fix For: 1.2 Maintenance Release
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> When using RollingFileAppender with a DatePattern containing at least 1 
> uppercase character in the form of a string literal, rolling of log files 
> does not take place correctly. This is as "curFileName" is a lowercase string.
> To reproduce, see: 
> http://mail-archives.apache.org/mod_mbox/logging-log4net-user/201104.mbox/%3CBANLkTi=lrapg7wijkb583gf7l5ystfe...@mail.gmail.com%3E
> Suggest change/fix to RollingFileAppender.cs:
> 1.2.9:
> 793c793
> < if (! curFileName.StartsWith(baseFile + 
> m_dateTime.Now.ToString(m_datePattern, 
> System.Globalization.DateTimeFormatInfo.InvariantInfo)))
> ---
> > if (! curFileName.StartsWith(baseFile + 
> > m_dateTime.Now.ToString(m_datePattern, 
> > System.Globalization.DateTimeFormatInfo.InvariantInfo).ToLower(System.Globalization.CultureInfo.InvariantCulture)))
> 1.2.10
> 816c816
> < if (! curFileName.StartsWith(baseFile + 
> m_dateTime.Now.ToString(m_datePattern, 
> System.Globalization.DateTimeFormatInfo.InvariantInfo)))
> ---
> > if (! curFileName.StartsWith(baseFile + 
> > m_dateTime.Now.ToString(m_datePattern, 
> > System.Globalization.DateTimeFormatInfo.InvariantInfo).ToLower(System.Globalization.CultureInfo.InvariantCulture)))
> Trunk:
> 885c885
> < if (! 
> curFileName.StartsWith(CombinePath(baseFile, 
> m_dateTime.Now.ToString(m_datePattern, 
> System.Globalization.DateTimeFormatInfo.InvariantInfo
> ---
> > if (! 
> > curFileName.StartsWith(CombinePath(baseFile, 
> > m_dateTime.Now.ToString(m_datePattern, 
> > System.Globalization.DateTimeFormatInfo.InvariantInfo).ToLower(System.Globalization.CultureInfo.InvariantCulture
> Work-about:
> Don't use uppercase characters in the form of a string literal for 
> RollingFileAppender.DatePattern.

--
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] [Assigned] (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-27:
---

Assignee: (was: Roy Chastain)

> 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.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] [Assigned] (LOG4NET-234) RollingFileAppender generates incorrect file name

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-234:


Assignee: (was: Roy Chastain)

> RollingFileAppender generates incorrect file name
> -
>
> Key: LOG4NET-234
> URL: https://issues.apache.org/jira/browse/LOG4NET-234
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
> Environment: Windows XP, Windows 2003
>Reporter: Miroslav Vanicky
> Fix For: 1.2 Maintenance Release
>
> Attachments: logs.zip
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I have Appender defined as follow...
>  type="log4net.Appender.RollingFileAppender" >
>  
> 
>  
>  
>  
> 
> 
>   
> 
>   
> This Appender should generate file names like "Log_2009-10-15.txt", mostly it 
> works fine, but in some unknown situations it generates file named 
> "Log_2009-10-15.txt_2009-10-15.txt". It seems to me that this happens when 
> there were no log-files and the incorrectly named file was the first log-file 
> generated.

--
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] [Assigned] (LOG4NET-208) RollingFileAppender does not delete file when RollingStyle = log4net.Appender.RollingFileAppender.RollingMode.Once

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-208:


Assignee: (was: Roy Chastain)

> RollingFileAppender does not delete file when RollingStyle = 
> log4net.Appender.RollingFileAppender.RollingMode.Once
> --
>
> Key: LOG4NET-208
> URL: https://issues.apache.org/jira/browse/LOG4NET-208
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
> Environment: Windows Xp SP3
>Reporter: Alain Dupont
>Priority: Minor
> Fix For: 1.2 Maintenance Release
>
>
> The RollingFileAppender does not delete file when RollingStyle = 
> log4net.Appender.RollingFileAppender.RollingMode.Once or when then append 
> attribut is set to false.

--
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] [Assigned] (LOG4NET-118) RollingFileAppender: RollingStyle=Size with StaticLogFileName=false does not work

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-118:


Assignee: (was: Roy Chastain)

> RollingFileAppender: RollingStyle=Size with StaticLogFileName=false does not 
> work
> -
>
> Key: LOG4NET-118
> URL: https://issues.apache.org/jira/browse/LOG4NET-118
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
> Environment: Windows 2003 / Microsoft .NET Framework 2.0
>Reporter: Patrick Gautschi
>Priority: Minor
> Fix For: 1.2 Maintenance Release
>
>
> When using the an appender configuration like
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
>   
> 
> results in the following error message when the application is started the 
> second time:
> log4net:ERROR RollingFileAppender: INTERNAL ERROR. Append is False but 
> OutputFile [V:\...\bin\Debug\info.log.0] already exists.

--
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] [Assigned] (LOG4NET-82) RollingFileAppender: Cannot RollFile ... Source does not exist

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-82:
---

Assignee: (was: Roy Chastain)

> RollingFileAppender: Cannot RollFile ... Source does not  exist
> ---
>
> Key: LOG4NET-82
> URL: https://issues.apache.org/jira/browse/LOG4NET-82
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.9, 1.2.10
> Environment: Windows 2003 Server
>Reporter: Kenneth Oberleitner
> Fix For: 1.2 Maintenance Release
>
>
> The following logging configuration will produce an endless loop of warnings 
> under the following circumstances:
>type="log4net.Appender.RollingFileAppender">
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 1.) set your system clock back at least three days
> 2.) run an application to create the static log file dated 3 days prior
> 3.) set your system clock forward a day (i.e. from Monday to Tuesday)
> 4.) run the application again, the log file will roll and a new static 
> log file is written
> 5.) set your system clock forward a day (i.e. from Monday to Tuesday)
> 6.) run the application
> repeated warnings will be issued until the application is killed
> log4net:WARN RollingFileAppender: Cannot RollFile 
> [E:\tmp\LoggingFileLockBug\LoggingFileLockBug\bin\Debug\Log\Audit\audit.txt.XXX]
>  -> 
> [E:\tmp\LoggingFileLockBug\LoggingFileLockBug\bin\Debug\Log\Audit\audit.txt.20060719.XXX].
>  Source does not exist
> where XXX is infinitely incremented until the process is halted
> Two workarounds found so far both involve changing the date pattern. Both 
> "MMdd" and ".-MM-dd" seem to work without issue.

--
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] [Assigned] (LOG4NET-175) RollingFileAppender generates unexpected filename and/or causes IIS to hang

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-175:


Assignee: (was: Roy Chastain)

> RollingFileAppender generates unexpected filename and/or causes IIS to hang
> ---
>
> Key: LOG4NET-175
> URL: https://issues.apache.org/jira/browse/LOG4NET-175
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.9
> Environment: win32
>Reporter: Devan Iyer
> Fix For: 1.2 Maintenance Release
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> We are using rolling file appender in an IIS managed C# application. Our 
> log4Net deployment is configured with the following options specified in 
> basic.xml:   
>   
>  . The file 
> pattern for our log file name is "abc_%date{MMdd_HHmmss}_%processid_.log".
> We have observed in our production environment that occasionally filenames 
> would be created with patterns like 
> "abc_%date{MMdd_HHmmss}_%processid_.log.1", 
> "abc_%date{MMdd_HHmmss}_%processid_.log.1.2", 
> "abc_%date{MMdd_HHmmss}_%processid_.log.1.2.3", etc. We have observed 
> filenames with the dot+sequential numbers pattern after the .log to be 
> anything from ".1" to ".220". This is one of two unexpected behaviours 
> observed.
>  
> The second unexpected behaviour seems to a special case of the first that 
> occasionally causes IIS to hang (100% CPU consumption). An analysis of 
> several crash dumps taken at the time of the hang indicated that 
> RollingFileAppender had in memory a filename of the same pattern as above but 
> with the number of characters [base filename pattern]+[recurring extension 
> pattern] exceeding 255 characters. It is very likely that an attempt to 
> create a file by such name on NTFS would throw exceptions at various levels - 
> managed and native - and hence the file itself is never created.
>  
> To the best of our knowledge, there were no events to trigger the filename to 
> be rolled. As indicated in the configuration options, we are using 
> RollingStyle of "Once". (The log file content is minimal at the time the 
> symptoms occur - total file size is about 2K - and the times of occurrence 
> are totally non related).
>  
> We have been unable to capture the workflow leading up to the symptoms above 
> due to the high number of users and document types in our production 
> environment. The permissions on the logging folder are static. However, we 
> have found a simple workflow in our lab environment, using permissions, that 
> produce similar symptoms. This workflow is:
>  
> - Right click on the logging folder and select "Properties"
> - Under the "Security" tab ensure that IIS_WPG group doesn't have write 
> access to the logging folder.
> - Restart IIS
> - Launch our application and view a document.  Check the logging folder to 
> make sure that a logfile is not created.
> - View a few more documents
> - Change the permission on the logging folder and ensure IIS_WPG group has 
> write access to the folder.  DO NOT restart IIS after changing the permission.
> - Launch our application and view another document.
> - At this point a logfile with a filename pattern described will be found in 
> the logging folder.
>  
> As mentioned, it is unlikely that permissions are the trigger in our event 
> but it is likely that the same code is creating these unexpected patterns 
> irrespective of the trigger.

--
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] [Assigned] (LOG4NET-203) RollingFileAppender does not roll more than one time when PreserveLogFileNameExtension is true

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-203:


Assignee: (was: Roy Chastain)

> RollingFileAppender does not roll more than one time when 
> PreserveLogFileNameExtension is true
> --
>
> Key: LOG4NET-203
> URL: https://issues.apache.org/jira/browse/LOG4NET-203
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
> Environment: I'm using the trunk
>Reporter: Scott Alexander
> Fix For: 1.2 Maintenance Release
>
>
> Method InitializeFromOneFile in RollingFileAppender.cs does not take into 
> account the file extension. To repro setup an appender like so
>  var appender = new DevicePointValueCsvAppender
> {
> MaxFileSize = 
> ConfigurationManager.AppSettings[MaxFileSizeName].IfNotNull(max => 
> OptionConverter.ToFileSize(max, DefaultMaxFileSize), DefaultMaxFileSize),
> MaxSizeRollBackups = 6,// 
> ConfigurationManager.AppSettings[MaxSizeRollBackupsName].IfNotNull(max => 
> Int32.Parse(max), DefaultMaxSizeRollBackups),
> Layout = new PatternLayout { ConversionPattern = 
> PatternLayout.DefaultConversionPattern },
> File = String.Format(CultureInfo.InvariantCulture, 
> FileNameFormat, modbusMasterName),
> RollingStyle = RollingFileAppender.RollingMode.Composite,
> PreserveLogFileNameExtension = true,
> StaticLogFileName = false,
> AppendToFile = false
> };
> When the logger initializes the call to InitializeRollBackups is made whic 
> incorrectly calculates the pre-existing number of backups, due to the fact 
> that the file extension is being included in the following line
> if (! curFileName.StartsWith(CombinePath(baseFile, 
> m_dateTime.Now.ToString(m_datePattern, 
> System.Globalization.DateTimeFormatInfo.InvariantInfo
> The previous line should be replaced with something like the following
>  string baseComparison = CombinePath(baseFile, 
> m_dateTime.Now.ToString(m_datePattern, 
> System.Globalization.DateTimeFormatInfo.InvariantInfo));
> if (m_preserveLogFileNameExtension)
> baseComparison = 
> Path.GetFileNameWithoutExtension(baseComparison);
>   if (! curFileName.StartsWith(baseComparison))
> Thanks

--
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] [Assigned] (LOG4NET-252) RollingFileAppender stops logging intermittently when it tries to roll over the log file

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-252:


Assignee: (was: Roy Chastain)

> RollingFileAppender stops logging intermittently when it tries to roll over 
> the log file
> 
>
> Key: LOG4NET-252
> URL: https://issues.apache.org/jira/browse/LOG4NET-252
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
> Environment: log4net - 1.2.0.30714
>Reporter: Kapil Goyal
>Priority: Critical
> Fix For: 1.2 Maintenance Release
>
>
> I tried to analyze the diagnostic log for log4net but did not find any 
> ERRORs. I did notice that when the logging stopped working, the last 
> statement in the diagnostic log indicated an attempt to roll-over. This issue 
> was reproduced 3-4 times in the span of around 10 days. Restarting the 
> process will cause the logging to start again. Below is the diagnostic log 
> followed by the log4net configuration being used.
> Diagnostic Log
> --
> log4net: FileAppender: Opening file for writing [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log] append [False]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.1] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.1]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.2]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.3] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.3]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.4] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.4]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.5] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.5]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.6] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.6]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.7] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.7]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.8] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.8]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.9] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.9]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.10] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.10]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.11] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.11]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.12] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.12]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.13] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.13]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.14] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.14]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.15] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.15]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.16] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.16]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.17] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.17]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.18] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.18]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.19] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.19]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.20] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.20]
> log4net: RollingFileAppender: Moved [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.21] -> [D:\Apps\Program 
> Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.21]
> log4net: Rol

[jira] [Assigned] (LOG4NET-240) Backup of logs are not created when application is running and at the same time date changes.

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-240:


Assignee: (was: Roy Chastain)

> Backup of logs are not created when application is running and at the same 
> time date changes.
> -
>
> Key: LOG4NET-240
> URL: https://issues.apache.org/jira/browse/LOG4NET-240
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
> Environment: XP
>Reporter: renuka
>Priority: Critical
> Fix For: 1.2 Maintenance Release
>
>
> Hi,
> I have set configuration properties as below.
>  type="log4net.Appender.RollingFileAppender">
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> When is in running mode, data gets locked correctely but in the mean time if 
> date changes, previous date's backup is not getting created. This happens 
> only if application is running else it works perfectely.
> Please help.

--
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] [Assigned] (LOG4NET-226) Allow to specify file name as wildcard pattern

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-226:


Assignee: (was: Roy Chastain)

> Allow to specify file name as wildcard pattern
> --
>
> Key: LOG4NET-226
> URL: https://issues.apache.org/jira/browse/LOG4NET-226
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 1.2.9, 1.2.10, 1.2.11
> Environment: Windows
>Reporter: Maxim Fateev
> Fix For: 1.2 Maintenance Release
>
>
> Change 707809 fixes issue with windows file name extension. 
> From filename.txt.1, filename.txt.2 it changes it to filename.1.txt, 
> filename.2.txt. 
> But it is still limiting form some use cases. I need to integrate logs with 
> existing logging infrastucture that requires file names to be filename_0.log, 
> filename_1.log.
> I propose to add additional property to specify filename as a format pattern. 
> I recommend using standard .net string format. So in my case file name would 
> be filename_{0}.log.
> It would also support other cases like requirement for filename to be 
> filename_00.log, filename_01.log. Just specify format as filename_{00}.log
> Also property to specify initial counter value is necessary to support my use 
> case.

--
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] [Assigned] (LOG4NET-220) multiple users overwrite existing log file when RollingFileAppender is rolling over date and minimal locking is used

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-220:


Assignee: (was: Roy Chastain)

> multiple users overwrite existing log file when RollingFileAppender is 
> rolling over date and minimal locking is used
> 
>
> Key: LOG4NET-220
> URL: https://issues.apache.org/jira/browse/LOG4NET-220
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
> Environment: .net client side application running on framework 3.5 
> service pack 1, windows xp box makes use of log4net dll to write user info to 
> log files
>Reporter: shabhana rampersadh
>Priority: Critical
> Fix For: 1.2 Maintenance Release
>
>
> config settings for rolling file appender
> 
> 
>type="log4net.Appender.RollingFileAppender,log4net">
>  value="C:\\Projects\\DealerMailer\\DealerMailer.UI\\DealerMailer.UI\\Log\\DealerMailer.UI_"
>  />
> 
> 
> 
> 
> 
> 
>  type="log4net.Appender.FileAppender+MinimalLock" />
> 
>/>
> 
>   
>   
> 
> 
>   
> 
> problem
> today 070702009
> user1 logs into application today --> logs data in log file dated today 
> (DealerMailer.UI_07072009.log)
> user2 logs into application today --> logs data in log file dated today 
> (DealerMailer.UI_07072009.log)
> user2 logs out of application today --> logs data in log file dated today 
> (DealerMailer.UI_07072009.log)
> tomorrow 08072009
> user1 still has his application open from yesterday (all calls are per call 
> basis so no locks are held)
> user2 logs into application --> no file exists, rolls over to next day & logs 
> data (DealerMailer.UI_08072009.log)
> user1 submits a transaction --> all data in (DealerMailer.UI_08072009.log) is 
> overwritten
> i have no idea why this is happening

--
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] [Assigned] (LOG4NET-272) Problems in dynamic file naming with multiple appenders

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-272:


Assignee: (was: Roy Chastain)

> Problems in dynamic file naming with multiple appenders
> ---
>
> Key: LOG4NET-272
> URL: https://issues.apache.org/jira/browse/LOG4NET-272
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
> Environment: OS: Windows XP
> Programming Environment: VB.NET
> .NET Framework 3.5
> Appender Type: RollingFileAppender
>Reporter: Ranjith Nair
>Priority: Critical
> Fix For: 1.2 Maintenance Release
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> I have 3 appenders in my config file for creating 3 different types of logs. 
> I am using dynamic naming of file in each of the 3 appenders by setting the 
> global context properties. In some cases, i need to set the log file name 
> dynamically for just 1 appender. When i set the file name for just 1 
> appender, it creates another file named "null" with no data in addition to 
> the actual logfile whose name has been set dynamically.
>  type="log4net.Appender.RollingFileAppender">
> 
> .
> .
> .
>  type="log4net.Appender.RollingFileAppender">
> 
> .
> .
> 
> 
> 
> 
> 
> 
> 
> 
> In the VB.NET code i set the filename as :
> log4net.GlobalContext.Properties("applog") = "file1.log"
> Dim logobj as log4net.Ilog =  LogManager.GetLogger("Logger1")
> logobj.debug("test")
> In this case it creates "file1.log" and also another empty file with name as 
> "null". This happens only when i am setting either of the appenders filename 
> at runtime. 
> Could you please check and let me know the issue behind this.

--
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] [Assigned] (LOG4NET-280) Rolling appender doesnt roll 0kb file, configured to roll on date.

2011-09-28 Thread Roy Chastain (Assigned) (JIRA)

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

Roy Chastain reassigned LOG4NET-280:


Assignee: (was: Roy Chastain)

> Rolling appender doesnt roll 0kb file, configured to roll on date.
> --
>
> Key: LOG4NET-280
> URL: https://issues.apache.org/jira/browse/LOG4NET-280
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
> Environment: asp.net 2.0
>Reporter: Naveen Jakkur Muniraju
>Priority: Blocker
> Fix For: 1.2 Maintenance Release
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> We are using a log4net version 1.2.10.1. We have a web application in which 
> we are using log4net rolling appender for application logging. 
> However the files which are 0Kb is not rolling on a daily basis. Below is the 
> configuration we are using. It's configured to roll on a date basis. 
> The logs which are >0kb are rolling fine.
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> Any help ASAP will be appreciated. 

--
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