[
https://issues.apache.org/jira/browse/LOG4NET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Psenner resolved LOG4NET-490.
-------------------------------------
Resolution: Fixed
Fixed with svn rev 1714249.
I had to introduce a pair of methods named ActivateOptions/OnClose in the
locking model such that mutexes are properly opened and disposed. Further a
recursive watch counter was required to untangle a complicated sequence of
acquirelock/open/close/releaselock operations. And last but not least I fixed
the seek stream operation that would crash if another program holds an
exclusive write lock on a logfile while logging takes place.
> InterProcessLock Tests fail
> ---------------------------
>
> Key: LOG4NET-490
> URL: https://issues.apache.org/jira/browse/LOG4NET-490
> Project: Log4net
> Issue Type: Bug
> Reporter: Dominik Psenner
> Assignee: 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)
