You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-user@logging.apache.org by Shaily Goel <gs...@novell.com> on 2007/05/08 10:56:03 UTC
FileAppender ExclusiveLock
Hi
I am using "RollingFileAppender" of "incubating-log4net-1.2.9-beta" version in my Product.
I found by default, the appender open the file in "Exclusive lock" mode only, in which the fileStream is opened in Read share mode only.
As a result of this log files created by this appender can be opened in notepad, but user cannot delete or rename these files.
My scenario is like this:
In order to see what is actually happening when a particular operation is done in a product we do like below:
For support, we usually say "delete your log files, try this operation again, and send the logs".
This cannot be possible in above case as a user cannot delete the above files without stopping the service/process
Is there any work around in above version to handle this.
Can we override the filestream of "ExclusiveLock" class in order to open in FileStream(fileName ,FileMode.Append, FileAccess.Write, FileShare.ReadWrite);
Please let me know this as soon as possible.
Thanks
Shaily
>>> Ron Grabowski <ro...@yahoo.com> 4/6/2007 8:55 AM >>>
I meant to suggest adding CreateFileStream to LockingModelBase.
----- Original Message ----
From: Ron Grabowski <ro...@yahoo.com>
To: Log4NET User <lo...@logging.apache.org>
Sent: Thursday, April 5, 2007 11:21:40 PM
Subject: Re: FileAppender ExclusiveLock workaround (Not MinimalLock)
Perhaps the FileAppender can be enhanced to allow the underlying FileStream to be opened by an inheritor:
// example code only...will not compile because CreateFileStream does not exist in FileAppender
public class CustomFileStreamFileAppender : FileAppender
{
// called from OpenFile method
public override FileStream CreateFileStream(string fileName, FileMode fileMode, FileAccess fileAccess, FileShare fileShare)
{
return new FileStream(fileName ,FileMode.Append, FileAccess.Write, FileShare.ReadWrite);
}
}
----- Original Message ----
From: Frogg <li...@rocketmail.com>
To: log4net-user@logging.apache.org
Sent: Thursday, April 5, 2007 9:25:01 AM
Subject: Re: FileAppender ExclusiveLock workaround (Not MinimalLock)
Thanks for the suggestion, I tried to add this to my code however it doesnt
seem to work, I may be missing some initialization command somewhere.... It
will create the log file but it will not input any text into it.
Ron Grabowski wrote:
>
> Have you tried something like this:
>
> // untested
> FileAppender fileAppender = new FileAppender();
> fileAppender.Writer =
> new QuietTextWriter(
> new StreamWriter(
> new
> FileStream("logs.txt",FileMode.Append,FileAccess.Write,FileShare.ReadWrite)),
> new OnlyOnceErrorHandler());
>
> ----- Original Message ----
> From: Frogg <li...@rocketmail.com>
> To: log4net-user@logging.apache.org
> Sent: Wednesday, April 4, 2007 4:31:05 PM
> Subject: FileAppender ExclusiveLock workaround (Not MinimalLock)
>
>
> Hello,
>
> We used to use a really old version of log4net (1.2.03) but have since
> upgraded to 1.2.10. With the old log4net we created a custom FileAppender
> so that different application domains could log to the same file (this was
> before the days of MinimalLock). Basically, what we did was to override
> the
> OpenFile method to open the file stream in share mode, thus allowing many
> processes to write to the file at the same time.
>
> This is how the code looked that worked with the old log4net dll:
>
> ==================Code c#=========================
> protected override void OpenFile(string rawFileName, bool append)
> {
> lock(this)
> {
> // Release any current configuration and prepare for new.
> Reset();
>
> // Make THIS debuggable at least.
> LogLog.Debug(
> string.Format(
> "CustomFileAppender: Opening file for SHARED writing[{0}]
> append [{1}]
> ",fileName, append ) );
>
> // Create the directory if needed
> Directory.CreateDirectory((new FileInfo(fileName)).DirectoryName);
>
> // Open the file to allow reading and writing WHILE OPEN
> FileStream fs = new
> FileStream(fileName,FileMode.Append,FileAccess.Write,FileShare.ReadWrite);
>
> // and store for use in the base class
> SetQWForFiles(new StreamWriter(fs));
>
> // save the name and append settings
> base.File = fileName;
> base.AppendToFile = append;
>
> // and write out any header details
> WriteHeader();
> }
> ==============End Code======================
>
> When we upgraded to the 1.2.10 this code no longer worked. I tried using
> MinimalLock instead of the above code but that has the unfortunate side
> effects of being very slow(Lock, Unlock, Lock, Unlock, etc) and allowing
> some other process to maintain an exclusive lock on the file (no matter
> how
> short of time), someone other than the logger (for example, someone is
> viewing the log file, the application is not able to log events because
> that
> person viewing got a writer lock).
>
> I would like to be able to redo the code above to work with 1.2.10 but my
> attempts thus far have been unsuccessfull, if anyone has any ideas that
> may
> put me on the right track I would be greatly appreciative.
>
> Thanks,
> --
> View this message in context:
> http://www.nabble.com/FileAppender-ExclusiveLock-workaround-%28Not-MinimalLock%29-tf3528119.html#a9845029
> Sent from the Log4net - Users mailing list archive at Nabble.com.
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/FileAppender-ExclusiveLock-workaround-%28Not-MinimalLock%29-tf3528119.html#a9855384
Sent from the Log4net - Users mailing list archive at Nabble.com.
RE: IAppender, IOptionHandler oddity
Posted by lim xu <lx...@yahoo.com>.
Nicko,
Thanks a lot. Truly appreciate it. I guess it's just confusing to my customers that when they look into the log files, they see "D:/whateverhwatever" that doesn't even exist on their system, immediately, they report back something is really wrong which makes me nervous.
I don't see any PDB files being distributed with the software to client and the assemblies were compiled under a custom "mode" called "FreeTrial", going to have to look again, but in our web.config, we disabled debug=true that's for sure.
nicko@apache.org wrote: v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} This is a feature of .net intended to help you debug issues in your code. It also helps the debugger know what source to display for each stack frame. Have you built your assembly with debug enabled? Have you included the debug PDB files with the assembly? This is not related specifically to log4net, but just a feature of .net in general.
Log4net can extract this information from the call stack when a message is logged. The %file and %line patterns can be used to extract the source code location of the logging call, however this is rather slow to generate and probably should not be used for general logging.
Cheers,
Nicko
------------
Nicko Cadell
log4net development
http://logging.apache.org/log4net
From: lim xu [mailto:lx2222182@yahoo.com]
Sent: 08 May 2007 16:09
To: Log4NET User
Subject: IAppender, IOptionHandler oddity
Hi all,
In our software, we implemented a custom database appender that implements the IAppender, IOptionHandler interfaces, it's called "ApplicationErrorDB".
Now this class is not only used by log4net, but I also directly access it through our code as well because I added some additional methods for our software to use.
Anyway, one of my method threw an exception when one of our beta testers were testing it and the log4net rolling file recorded the strangest error. It recorded a physical drive on MY machine like so
"System.FormatException: Input string was not in a correct format.
at Civion.PM.DataAccess.ApplicationErrorDB.LogServerException(Exception ex) in D:\Websites\Civion\Projects\PM1\ProjectManagement\Source\Data Access Layer\Civion.PM.DataAccess\ApplicationErrors\ApplicationErrorDB.cs"
That's the physical address to the source code on my local machine, I did not hard code this physical path anywhere in my code, how in the world my beta tester who is thousands of miles away getting the path?
When I compiled my project (which references log4net), is that somehow compiled into somewhere? I can't figure it out.
Thanks
---------------------------------
Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.
---------------------------------
Don't be flakey. Get Yahoo! Mail for Mobile and
always stay connected to friends.
RE: IAppender, IOptionHandler oddity
Posted by ni...@apache.org.
This is a feature of .net intended to help you debug issues in your
code. It also helps the debugger know what source to display for each
stack frame. Have you built your assembly with debug enabled? Have you
included the debug PDB files with the assembly? This is not related
specifically to log4net, but just a feature of .net in general.
Log4net can extract this information from the call stack when a message
is logged. The %file and %line patterns can be used to extract the
source code location of the logging call, however this is rather slow to
generate and probably should not be used for general logging.
Cheers,
Nicko
------------
Nicko Cadell
log4net development
http://logging.apache.org/log4net
From: lim xu [mailto:lx2222182@yahoo.com]
Sent: 08 May 2007 16:09
To: Log4NET User
Subject: IAppender, IOptionHandler oddity
Hi all,
In our software, we implemented a custom database appender that
implements the IAppender, IOptionHandler interfaces, it's called
"ApplicationErrorDB".
Now this class is not only used by log4net, but I also directly access
it through our code as well because I added some additional methods for
our software to use.
Anyway, one of my method threw an exception when one of our beta testers
were testing it and the log4net rolling file recorded the strangest
error. It recorded a physical drive on MY machine like so
"System.FormatException: Input string was not in a correct format.
at Civion.PM.DataAccess.ApplicationErrorDB.LogServerException(Exception
ex) in D:\Websites\Civion\Projects\PM1\ProjectManagement\Source\Data
Access
Layer\Civion.PM.DataAccess\ApplicationErrors\ApplicationErrorDB.cs"
That's the physical address to the source code on my local machine, I
did not hard code this physical path anywhere in my code, how in the
world my beta tester who is thousands of miles away getting the path?
When I compiled my project (which references log4net), is that somehow
compiled into somewhere? I can't figure it out.
Thanks
________________________________
Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.
IAppender, IOptionHandler oddity
Posted by lim xu <lx...@yahoo.com>.
Hi all,
In our software, we implemented a custom database appender that implements the IAppender, IOptionHandler interfaces, it's called "ApplicationErrorDB".
Now this class is not only used by log4net, but I also directly access it through our code as well because I added some additional methods for our software to use.
Anyway, one of my method threw an exception when one of our beta testers were testing it and the log4net rolling file recorded the strangest error. It recorded a physical drive on MY machine like so
"System.FormatException: Input string was not in a correct format.
at Civion.PM.DataAccess.ApplicationErrorDB.LogServerException(Exception ex) in D:\Websites\Civion\Projects\PM1\ProjectManagement\Source\Data Access Layer\Civion.PM.DataAccess\ApplicationErrors\ApplicationErrorDB.cs"
That's the physical address to the source code on my local machine, I did not hard code this physical path anywhere in my code, how in the world my beta tester who is thousands of miles away getting the path?
When I compiled my project (which references log4net), is that somehow compiled into somewhere? I can't figure it out.
Thanks
---------------------------------
Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.