logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject Re: Log File Naming Problem
Date Mon, 21 Jan 2008 17:41:57 GMT
Maybe instead of the MinimalLock you could write a MutexLock locking model in conjunction with
opening the file in more of a shared mode so each plugin has write permission to the file
but the mutex (either at the locking model level or inside a special MutexFileAppender) is
the gatekeeper for file writes. I think the biggest challenge is the rolling file appender
requirement. Can you configure the host to use a FileAppender that writes to the current day's
log file? I recall nlog has some special ways to deal with multiple processes writing to the
same file. It uses Win32 apis to cooridnate multiple writes. I would imagine this is much
much faster than the MinimalLock model. I've not tried nlog's multiprocess write support in
conjunction with rolling the file.

I've not done a lot with plugins and app domains but I think making the host responsible for
receiving/recording log messages from the plugins seems like a more managable solution. You
don't want a plugin to mess up the log file for the host.

----- Original Message ----
From: Steve Wranovsky <wranovsky@gmail.com>
To: Log4NET User <log4net-user@logging.apache.org>
Sent: Monday, January 21, 2008 11:08:40 AM
Subject: Re: Log File Naming Problem

First, concerning our use of multiple App domains, we've implemented a
plugin based Windows service that has several independently running
plugin threads running.  We've decided to use an App domain per plugin
thread so that if there is a problem with one of the plugins/threads,
it doesn't bring down the other threads within the service.

I took a look at the blog post, and our code is similar to what is
described in that post.  We are initializing log4net in each app
domain.  We potentially have a very large amount of logs being
generated overall in our system.  I'd prefer to avoid having to save
the data in a database, so routing the logs to a single
RollingFileAppender seems to be the best solution.  It sounds like
this would also be an added benefit from a performance standpoint if
we were able to use the ExclusiveLock locking model.

Thanks for the feedback.  It would be nice if this worked with the
standard RollingFileAppender, but, this at least points me in a
direction to find a solution to the problem I am having.


On Jan 20, 2008 1:42 PM, Ron Grabowski <rongrabowski@yahoo.com> wrote:
> When a new app domain is created is log4net re-initialized in the new
 app domain?
> It sounds like the problem is that you have a lot of threads trying
 to open, close, and roll the log file. Can you delegate all the locking
 issues to a database then extract data out at a later date?
> If using a database isn't an option I suggest trying to route all the
 messages to a single RollingFileAppender instance configured to use
 the default ExclusiveLock locking model (MinimalLock is noticeably slower
 even for a small amount of logs). A comment from this blog:
> mentions using Remoting to channel all the messages from the threads
 to a single RollingFileAppender so there is a single thread and class
 controlling rolling. You coculd use the IpcChannel for inter-process
 communications. Is your code similiar to the sample code in the blog post?
> If you don't mind me asking, what is the use case for having to
 create new app domains in addition to the new threads?
>  ----- Original Message ----
> From: Steve Wranovsky <wranovsky@gmail.com>
> To: log4net-user@logging.apache.org
> Sent: Thursday, January 17, 2008 11:10:29 AM
> Subject: Log File Naming Problem
> Hello,
> I have a multi-threaded application using log4net 1.2.10 for logging.
> There are a couple of points when the application runs where there
> a large number of logs occurring simultaneously from multiple threads
> (that happen to be in different App Domains).  On occasion, I will
> up with two separate log files generated when this point in my
> application occurs.  One of the log files will end up with a date
> pattern twice in the name and will look something like this:
> Server_2008-01-16.log
> Server_2008-01-16.log2008-01-16.log
> A few of the logs end up in the second log file from one of the
> threads.  The remainder of the threads log to the first log file and
> continue using it.  Occasionally this second log file will be used
> again by another thread if the problem happens again.  Here's the
> configuration file I'm using:
> <log4net>
>                 <appender name="RollingLogFileAppender"
> type="log4net.Appender.RollingFileAppender">
>                                 <param name="File"
>  value=".\\logs\\Server_" />
>                                 <param name="AppendToFile"
>  />
>                                 <param name="MaxSizeRollBackups"
>  value="20" />
>                                 <param name="MaximumFileSize"
>  value="10MB" />
>                                 <param name="RollingStyle"
>  value="Composite" />
>                                 <param name="datePattern"
> value="yyyy-MM-dd.lo\g" />
>                                 <param name="StaticLogFileName"
>  value="false" />
>                                 <layout
>  type="log4net.Layout.PatternLayout">
>                                                 <param
> name="ConversionPattern" value="%d [%t] %-5p - %m%n" />
>                                 </layout>
>                                 <lockingModel
> type="log4net.Appender.FileAppender+MinimalLock" />
>                 </appender>
>                 <root>
>                                 <level value="INFO" />
>                                 <appender-ref
>  ref="RollingLogFileAppender" />
>                 </root>
> </log4net>
> It appears that perhaps a lock is failing in one of the threads, and
> it by default tries to create another log file to log to.  Is it
> possible to block this from happening and have the logs go into the
> original log file?  If this is not possible, it would be nice if the
> second log file didn't have the double date in it, or if the handling
> of this was cleaner.
> Thanks,
> Steve

View raw message