[
https://issues.apache.org/jira/browse/LOG4NET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004032#comment-15004032
]
Dominik Psenner commented on LOG4NET-490:
-----------------------------------------
We could solve one issue by overriding WriteFooterAndCloseWriter() to do
nothing, but this feels wrong. Another thing is that there's a Reset() method
which closes any open stream, but in the case of the rolling file appender this
happens when the file is already closed and thus tries to open the file when
the locking mutex is not there yet. For now I've enough headache..
> InterProcessLock Tests fail
> ---------------------------
>
> Key: LOG4NET-490
> URL: https://issues.apache.org/jira/browse/LOG4NET-490
> Project: Log4net
> Issue Type: Bug
> Reporter: Dominik Psenner
> Priority: Critical
>
> The tests in question are:
> * TestInterProcessLockRoll
> * TestInterProcessLockUnlocks
> This is actually quite bad and proves that my last attempt to introduce
> something that just works failed miserably. At first glance the trouble comes
> from the interaction with the base classes. One thing I noted is that the
> base class tries to write a footer when the file gets closed. But in the case
> of the rolling file appender the file is no longer there when this happens.
> Another example is that due to the error logs I'm writing the test finally
> noticed that the locks are acquired and released in bad order and thus result
> in bad behaviour.
> But these are just two examples from a bunch of issues that still have to be
> worked out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
