log4net and IIS problems

[Morten Andersen <mo...@vianett.no>]

Hi

I am using log4net on my asp.net web page hosted at an IIS server. This seems to work just fine until I do some changes in the source. Since asp.net runs as a shadow copy, changes will be compiled on the next request after the change was made. I guess this causes the log manager to duplicate itself, and the second one will not have write access to the log files. Since the old app domain will not die before all the requests are completed, the new log manager must wait for this pool to die before enabling the appenders. An alternative solution can be that the log manager retries to create the appenders if it fails.

Maybe it already exist a solution for this problem?

Best regards,
Morten Andersen

RE: log4net and IIS problems

[Morten Andersen <mo...@vianett.no>]

Hi

Thank you for your response. I will try to use the shared locking.

Morten


Fra: Walden H. Leverich [mailto:WaldenL@TechSoftInc.com]
Sendt: 26. februar 2008 16:03
Til: Log4NET User
Emne: RE: log4net and IIS problems

>This seems to work just fine until I do some changes in the source. Since asp.net runs as a
>shadow copy, changes will be compiled on the next request after the change was made.

The problem will also show its head on a worker-process restart for the same reason. There are two possible ways around this. First, use the ProcessID in the file name, so you'd have a new file since it's a new process (somewhat ugly). Or, use the shared-locking option so the file is opened written-to and closed each time. This is certainly slower, but avoids the cross-process locking issue.

-Walden

--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com<BLOCKED::blocked::http://www.techsoftinc.com/>

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

RE: log4net and IIS problems

["Walden H. Leverich" <Wa...@TechSoftInc.com>]

>This seems to work just fine until I do some changes in the source.
Since asp.net runs as a 

>shadow copy, changes will be compiled on the next request after the
change was made.

 

The problem will also show its head on a worker-process restart for the
same reason. There are two possible ways around this. First, use the
ProcessID in the file name, so you'd have a new file since it's a new
process (somewhat ugly). Or, use the shared-locking option so the file
is opened written-to and closed each time. This is certainly slower, but
avoids the cross-process locking issue.

 

-Walden

 

-- 

Walden H Leverich III
Tech Software
(516) 627-3800 x3051

WaldenL@TechSoftInc.com
http://www.TechSoftInc.com
<BLOCKED::blocked::http://www.techsoftinc.com/> 

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