Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.15
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        nachbarslumpi Dominik Psenner added a comment -

        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.

        Show
        nachbarslumpi Dominik Psenner added a comment - 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.
        Hide
        nachbarslumpi Dominik Psenner added a comment -

        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..

        Show
        nachbarslumpi Dominik Psenner added a comment - 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..

          People

          • Assignee:
            nachbarslumpi Dominik Psenner
            Reporter:
            nachbarslumpi Dominik Psenner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development