You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Dominik Psenner (JIRA)" <ji...@apache.org> on 2015/11/13 19:40:10 UTC

[jira] [Resolved] (LOG4NET-490) InterProcessLock Tests fail

     [ 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)