Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.0, 6.0
    • Component/s: core/store
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      We should remove the setters for the LockFactory from Directory and make the field final. It is a bug to change the LockFactory after creating a directory, because you may break locking (if locks are currently held).

      The LockFactory should be passed on ctor only.

      The other suggestion: Should LockFactory have a directory at all? We moved away from having the lock separately from the index directory. This is no longer a supported configuration (since approx Lucene 2.9 or 3.0). I would like to remove the directory from LockFactory and make it part of the Directory only.

      1. LUCENE-5953.patch
        132 kB
        Uwe Schindler
      2. LUCENE-5953.patch
        130 kB
        Uwe Schindler
      3. LUCENE-5953.patch
        127 kB
        Uwe Schindler
      4. LUCENE-5953.patch
        130 kB
        Uwe Schindler
      5. LUCENE-5953.patch
        128 kB
        Uwe Schindler

        Issue Links

          Activity

          Hide
          Michael McCandless added a comment -

          +1

          Show
          Michael McCandless added a comment - +1
          Hide
          Robert Muir added a comment -

          strong +1.

          Lets simplify and make this safer. I agree too, the interaction between Directory and LockFactory is confusing.

          How can we make this as simple and error-free as possible?

          Show
          Robert Muir added a comment - strong +1. Lets simplify and make this safer. I agree too, the interaction between Directory and LockFactory is confusing. How can we make this as simple and error-free as possible?
          Hide
          Uwe Schindler added a comment -

          I am also going to remove "lockPrefix" completely, it was there to allow to store locks outside index dir and for that a "hash" prefix was calculated (back in 2.9). If some specific lock implementation needs that, it can implement this on itsself. Directory should not have to deal with a prefix on the filename.

          Show
          Uwe Schindler added a comment - I am also going to remove "lockPrefix" completely, it was there to allow to store locks outside index dir and for that a "hash" prefix was calculated (back in 2.9). If some specific lock implementation needs that, it can implement this on itsself. Directory should not have to deal with a prefix on the filename.
          Hide
          Michael McCandless added a comment -

          +1 to remove lock prefix.

          Show
          Michael McCandless added a comment - +1 to remove lock prefix.
          Hide
          Uwe Schindler added a comment -

          clearLock() in directory and lockfactory is obsolete, too. It was previously used to release any possible locks, but it is never used by any code in Lucene. To release a lock, you have to call release() on the lock itsself. This was a nice cleanup.

          My proposal:
          LockFactory only has one method: makeLock(Directory, lockName). By that we dont need to pass the directory path. If a lock factory needs the directory it can use it, if not (singleinstance or nolock) it just ignores (or maybe it can use it to key against directory instance - SingleInstanceLockFactory would be easier to implement).

          The directory keeps as it is, it just passes "this" to the lock factory (on lowest level, so FilterDirectory wont do this).

          This also removes instanceof checks, because FSLockFactory would simply deny to work together with RAMDirectory.

          I will post a patch for review later or tomorrow - this is just a collection of my ideas...

          Show
          Uwe Schindler added a comment - clearLock() in directory and lockfactory is obsolete, too. It was previously used to release any possible locks, but it is never used by any code in Lucene. To release a lock, you have to call release() on the lock itsself. This was a nice cleanup. My proposal: LockFactory only has one method: makeLock(Directory, lockName). By that we dont need to pass the directory path. If a lock factory needs the directory it can use it, if not (singleinstance or nolock) it just ignores (or maybe it can use it to key against directory instance - SingleInstanceLockFactory would be easier to implement). The directory keeps as it is, it just passes "this" to the lock factory (on lowest level, so FilterDirectory wont do this). This also removes instanceof checks, because FSLockFactory would simply deny to work together with RAMDirectory. I will post a patch for review later or tomorrow - this is just a collection of my ideas...
          Hide
          Uwe Schindler added a comment -

          Sorry that it took a while, I was very busy.

          Attached is a patch that refactors LockFactory handling. In addition to the discussion before, this one makes handling of locks much simplier:

          • LockFactory is no longer used or exposed by the Directory implementation it is just some factory class, that can be used by a directory to implement makeLock(name). BaseDirectory is the only place where the lockFactory is actually used, its not part of Directory interface.
          • IndexWriter and all other components solely use Directory.makeLock(name), which returns a Lock instance
          • FSDirectory subclasses are no longer allowed to take "null" as LockFactory instance. You have to pass one explicit (or use a constructor that is documented to take default).
          • FSLockFactory.getDefault() can be used to get a default instance for the platform used. Currently this always returns NativeFSLockFactory.INSTANCE.
          • Most lock factories are now singletons: NativeFSLockFactory.INSTANCE, SimpleFSLockFactory.INSTANCE, NoLockFactory.INSTANCE.

          I also rewrote the broken SnapShooter (the way how it locks) in Solr (but not fix it). As it is documented as "deprecated" and no longer used, we should remove it in Solr 5.0. I will open another issue about that.

          I would like to commit this asap, because the patch may get out of sync very fast. I will now run all test in a loop with explicit -Dtests.directory=... to check all combinations, because disallowing "null" as LockFactory may cause hidden bugs. So we should run this patch for a while on Jenkins

          Show
          Uwe Schindler added a comment - Sorry that it took a while, I was very busy. Attached is a patch that refactors LockFactory handling. In addition to the discussion before, this one makes handling of locks much simplier: LockFactory is no longer used or exposed by the Directory implementation it is just some factory class, that can be used by a directory to implement makeLock(name). BaseDirectory is the only place where the lockFactory is actually used, its not part of Directory interface. IndexWriter and all other components solely use Directory.makeLock(name), which returns a Lock instance FSDirectory subclasses are no longer allowed to take "null" as LockFactory instance. You have to pass one explicit (or use a constructor that is documented to take default). FSLockFactory.getDefault() can be used to get a default instance for the platform used. Currently this always returns NativeFSLockFactory.INSTANCE. Most lock factories are now singletons: NativeFSLockFactory.INSTANCE, SimpleFSLockFactory.INSTANCE, NoLockFactory.INSTANCE. I also rewrote the broken SnapShooter (the way how it locks) in Solr (but not fix it). As it is documented as "deprecated" and no longer used, we should remove it in Solr 5.0. I will open another issue about that. I would like to commit this asap, because the patch may get out of sync very fast. I will now run all test in a loop with explicit -Dtests.directory=... to check all combinations, because disallowing "null" as LockFactory may cause hidden bugs. So we should run this patch for a while on Jenkins
          Hide
          Uwe Schindler added a comment - - edited

          Patch also passes with explicit SimpleFSDirectory and explicit RAMDirectory.

          I was only not able to veryify my changes to HDFS and BlockDir (I'm Windows user). It would be good, if Mark Miller could review this. Thanks.

          Show
          Uwe Schindler added a comment - - edited Patch also passes with explicit SimpleFSDirectory and explicit RAMDirectory. I was only not able to veryify my changes to HDFS and BlockDir (I'm Windows user). It would be good, if Mark Miller could review this. Thanks.
          Hide
          Uwe Schindler added a comment -

          Small update in patch to simplify MMapDirectory testing.

          Show
          Uwe Schindler added a comment - Small update in patch to simplify MMapDirectory testing.
          Hide
          Uwe Schindler added a comment -

          Removed the UnsupportedLockFactory again, because it was just there to be used in BaseDirectory. This is no longer needed, if compound formats directly implement Directory (no need to extend BaseDirectory).

          Show
          Uwe Schindler added a comment - Removed the UnsupportedLockFactory again, because it was just there to be used in BaseDirectory. This is no longer needed, if compound formats directly implement Directory (no need to extend BaseDirectory).
          Hide
          Uwe Schindler added a comment -

          New patch:

          • Clarified how FileSwitchDirectory locks - as expected, the lock file is created in the directory where the lock file's extension belongs to.
          • Javadoc improvements
          • Cleaned up some import statements
          • Test cleanups

          I think it's ready,

          Show
          Uwe Schindler added a comment - New patch: Clarified how FileSwitchDirectory locks - as expected, the lock file is created in the directory where the lock file's extension belongs to. Javadoc improvements Cleaned up some import statements Test cleanups I think it's ready,
          Hide
          Uwe Schindler added a comment -

          New patch:

          • HdfsLockFactory is now also a singleton
          • removed some useless synchronization (LockFactories are immutable)
          Show
          Uwe Schindler added a comment - New patch: HdfsLockFactory is now also a singleton removed some useless synchronization (LockFactories are immutable)
          Hide
          Robert Muir added a comment -

          +1, this is an awesome cleanup!

          Show
          Robert Muir added a comment - +1, this is an awesome cleanup!
          Hide
          ASF subversion and git services added a comment -

          Commit 1637665 from Uwe Schindler in branch 'dev/trunk'
          [ https://svn.apache.org/r1637665 ]

          LUCENE-5953: Restructure Directory and LockFactory APIs

          Show
          ASF subversion and git services added a comment - Commit 1637665 from Uwe Schindler in branch 'dev/trunk' [ https://svn.apache.org/r1637665 ] LUCENE-5953 : Restructure Directory and LockFactory APIs
          Hide
          ASF subversion and git services added a comment -

          Commit 1637674 from Uwe Schindler in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1637674 ]

          Merged revision(s) 1637665 from lucene/dev/trunk:
          LUCENE-5953: Restructure Directory and LockFactory APIs

          Show
          ASF subversion and git services added a comment - Commit 1637674 from Uwe Schindler in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1637674 ] Merged revision(s) 1637665 from lucene/dev/trunk: LUCENE-5953 : Restructure Directory and LockFactory APIs
          Hide
          Uwe Schindler added a comment - - edited

          I committed this.

          I also noticed that (at least on my windows machine), Snapshooter sometimes fails with a crazy NoSuchFileException when trying to write a snapshot. To me it looks like a multi-threading issue, which may not be related to the changes here. We will see on jenkins.

          Nevertheless, Snapshooter should be removed (as far as I understand from the comments in the code because it is no longer used).

          Show
          Uwe Schindler added a comment - - edited I committed this. I also noticed that (at least on my windows machine), Snapshooter sometimes fails with a crazy NoSuchFileException when trying to write a snapshot. To me it looks like a multi-threading issue, which may not be related to the changes here. We will see on jenkins. Nevertheless, Snapshooter should be removed (as far as I understand from the comments in the code because it is no longer used).
          Hide
          ASF subversion and git services added a comment -

          Commit 1637688 from Uwe Schindler in branch 'dev/trunk'
          [ https://svn.apache.org/r1637688 ]

          LUCENE-5953: Remove obsolete locking

          Show
          ASF subversion and git services added a comment - Commit 1637688 from Uwe Schindler in branch 'dev/trunk' [ https://svn.apache.org/r1637688 ] LUCENE-5953 : Remove obsolete locking
          Hide
          ASF subversion and git services added a comment -

          Commit 1637689 from Uwe Schindler in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1637689 ]

          Merged revision(s) 1637688 from lucene/dev/trunk:
          LUCENE-5953: Remove obsolete locking

          Show
          ASF subversion and git services added a comment - Commit 1637689 from Uwe Schindler in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1637689 ] Merged revision(s) 1637688 from lucene/dev/trunk: LUCENE-5953 : Remove obsolete locking
          Hide
          Uwe Schindler added a comment -

          I checked out: Also without this patch applied, TestReplicationHandlerBackup fails in 30% of all tries on Windows (on my machine). Error is always a NoSuchFileException when opening the IndexOutput for some index file on the snapshot directory - which disappeared in the meantime. This is seems to be caused by some deleting on the snapshot dirs in parallel. Looks like the test has problems:

             [junit4]   2> 7139 T27 oash.SnapShooter.createSnapshot Creating backup snapshot...
             [junit4]   2> 7149 T27 oash.SnapShooter.createSnapshot ERROR Exception while creating snapshot java.nio.file.NoSuchFileException: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-B758CE1D69E0AEC1-001\solr-instance-001\collection1\data\snapshot.20141109154841694\_0.tip
             [junit4]   2>        at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
             [junit4]   2>        at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
             [junit4]   2>        at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
             [junit4]   2>        at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
             [junit4]   2>        at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:430)
             [junit4]   2>        at java.nio.file.Files.newOutputStream(Files.java:172)
             [junit4]   2>        at org.apache.lucene.store.FSDirectory$FSIndexOutput.<init>(FSDirectory.java:285)
             [junit4]   2>        at org.apache.lucene.store.FSDirectory.createOutput(FSDirectory.java:220)
             [junit4]   2>        at org.apache.lucene.store.Directory.copy(Directory.java:150)
             [junit4]   2>        at org.apache.lucene.store.MockDirectoryWrapper.copy(MockDirectoryWrapper.java:1030)
             [junit4]   2>        at org.apache.solr.handler.SnapShooter.copyFile(SnapShooter.java:234)
             [junit4]   2>        at org.apache.solr.handler.SnapShooter.copyFiles(SnapShooter.java:229)
             [junit4]   2>        at org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:139)
             [junit4]   2>        at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:88)
             [junit4]   2>
             [junit4]   2> 7159 T22 C1 oasc.SolrCore.execute [collection1] webapp=/solr path=/replication params={command=details} status=0 QTime=10
             [junit4]   2> 7159 T12 oas.SolrTestCaseJ4.tearDown ###Ending doTestBackup
          

          I see this unrelated to changes here - I just fixed the obsolete Locking on SnapShooter.java (it was unused), so I set NoLockFactory.INSTANCE on the Snapshot Directory instance.

          Show
          Uwe Schindler added a comment - I checked out: Also without this patch applied, TestReplicationHandlerBackup fails in 30% of all tries on Windows (on my machine). Error is always a NoSuchFileException when opening the IndexOutput for some index file on the snapshot directory - which disappeared in the meantime. This is seems to be caused by some deleting on the snapshot dirs in parallel. Looks like the test has problems: [junit4] 2> 7139 T27 oash.SnapShooter.createSnapshot Creating backup snapshot... [junit4] 2> 7149 T27 oash.SnapShooter.createSnapshot ERROR Exception while creating snapshot java.nio.file.NoSuchFileException: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup-B758CE1D69E0AEC1-001\solr-instance-001\collection1\data\snapshot.20141109154841694\_0.tip [junit4] 2> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) [junit4] 2> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) [junit4] 2> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) [junit4] 2> at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230) [junit4] 2> at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:430) [junit4] 2> at java.nio.file.Files.newOutputStream(Files.java:172) [junit4] 2> at org.apache.lucene.store.FSDirectory$FSIndexOutput.<init>(FSDirectory.java:285) [junit4] 2> at org.apache.lucene.store.FSDirectory.createOutput(FSDirectory.java:220) [junit4] 2> at org.apache.lucene.store.Directory.copy(Directory.java:150) [junit4] 2> at org.apache.lucene.store.MockDirectoryWrapper.copy(MockDirectoryWrapper.java:1030) [junit4] 2> at org.apache.solr.handler.SnapShooter.copyFile(SnapShooter.java:234) [junit4] 2> at org.apache.solr.handler.SnapShooter.copyFiles(SnapShooter.java:229) [junit4] 2> at org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:139) [junit4] 2> at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:88) [junit4] 2> [junit4] 2> 7159 T22 C1 oasc.SolrCore.execute [collection1] webapp=/solr path=/replication params={command=details} status=0 QTime=10 [junit4] 2> 7159 T12 oas.SolrTestCaseJ4.tearDown ###Ending doTestBackup I see this unrelated to changes here - I just fixed the obsolete Locking on SnapShooter.java (it was unused), so I set NoLockFactory.INSTANCE on the Snapshot Directory instance.
          Hide
          Uwe Schindler added a comment -

          SOLR-6151 is already there to track test failures. Another Policeman Jenkins server had a similar failure:

             [junit4]   2> 218994 T761 oash.SnapShooter.createSnapshot Creating backup snapshot...
             [junit4]   2> 218996 T761 oash.SnapShooter.createSnapshot ERROR Exception while creating snapshot java.nio.file.NoSuchFileException: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandlerBackup-2B253ACE4326502E-001/solr-instance-001/collection1/data/snapshot.20141109233419686/_0.cfe
             [junit4]   2> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
             [junit4]   2> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
             [junit4]   2> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
             [junit4]   2> 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
             [junit4]   2> 	at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
             [junit4]   2> 	at java.nio.file.Files.newOutputStream(Files.java:216)
             [junit4]   2> 	at org.apache.lucene.store.FSDirectory$FSIndexOutput.<init>(FSDirectory.java:285)
             [junit4]   2> 	at org.apache.lucene.store.FSDirectory.createOutput(FSDirectory.java:220)
             [junit4]   2> 	at org.apache.lucene.store.Directory.copy(Directory.java:150)
             [junit4]   2> 	at org.apache.lucene.store.MockDirectoryWrapper.copy(MockDirectoryWrapper.java:1030)
             [junit4]   2> 	at org.apache.solr.handler.SnapShooter.copyFile(SnapShooter.java:234)
             [junit4]   2> 	at org.apache.solr.handler.SnapShooter.copyFiles(SnapShooter.java:229)
             [junit4]   2> 	at org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:139)
             [junit4]   2> 	at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:88)
             [junit4]   2> 
             [junit4]   2> 219000 T754 C133 oasc.SolrCore.execute [collection1] webapp=/solr path=/replication params={command=details} status=0 QTime=0 
             [junit4]   2> 219002 T748 oas.SolrTestCaseJ4.tearDown ###Ending doTestBackup
          
          Show
          Uwe Schindler added a comment - SOLR-6151 is already there to track test failures. Another Policeman Jenkins server had a similar failure: [junit4] 2> 218994 T761 oash.SnapShooter.createSnapshot Creating backup snapshot... [junit4] 2> 218996 T761 oash.SnapShooter.createSnapshot ERROR Exception while creating snapshot java.nio.file.NoSuchFileException: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandlerBackup-2B253ACE4326502E-001/solr-instance-001/collection1/data/snapshot.20141109233419686/_0.cfe [junit4] 2> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) [junit4] 2> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [junit4] 2> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) [junit4] 2> at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214) [junit4] 2> at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) [junit4] 2> at java.nio.file.Files.newOutputStream(Files.java:216) [junit4] 2> at org.apache.lucene.store.FSDirectory$FSIndexOutput.<init>(FSDirectory.java:285) [junit4] 2> at org.apache.lucene.store.FSDirectory.createOutput(FSDirectory.java:220) [junit4] 2> at org.apache.lucene.store.Directory.copy(Directory.java:150) [junit4] 2> at org.apache.lucene.store.MockDirectoryWrapper.copy(MockDirectoryWrapper.java:1030) [junit4] 2> at org.apache.solr.handler.SnapShooter.copyFile(SnapShooter.java:234) [junit4] 2> at org.apache.solr.handler.SnapShooter.copyFiles(SnapShooter.java:229) [junit4] 2> at org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:139) [junit4] 2> at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:88) [junit4] 2> [junit4] 2> 219000 T754 C133 oasc.SolrCore.execute [collection1] webapp=/solr path=/replication params={command=details} status=0 QTime=0 [junit4] 2> 219002 T748 oas.SolrTestCaseJ4.tearDown ###Ending doTestBackup
          Hide
          ASF subversion and git services added a comment -

          Commit 1637701 from Uwe Schindler in branch 'dev/trunk'
          [ https://svn.apache.org/r1637701 ]

          LUCENE-5953: Fix null lock factory

          Show
          ASF subversion and git services added a comment - Commit 1637701 from Uwe Schindler in branch 'dev/trunk' [ https://svn.apache.org/r1637701 ] LUCENE-5953 : Fix null lock factory
          Hide
          ASF subversion and git services added a comment -

          Commit 1637702 from Uwe Schindler in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1637702 ]

          Merged revision(s) 1637701 from lucene/dev/trunk:
          LUCENE-5953: Fix null lock factory

          Show
          ASF subversion and git services added a comment - Commit 1637702 from Uwe Schindler in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1637702 ] Merged revision(s) 1637701 from lucene/dev/trunk: LUCENE-5953 : Fix null lock factory
          Hide
          ASF subversion and git services added a comment -

          Commit 1637743 from Uwe Schindler in branch 'dev/trunk'
          [ https://svn.apache.org/r1637743 ]

          LUCENE-5953: Revert changes to SnapShooter, just remove useless locking. The tests now pass more often, because snapshot directory does not disappear suddenly (its created explicitely before file copying

          Show
          ASF subversion and git services added a comment - Commit 1637743 from Uwe Schindler in branch 'dev/trunk' [ https://svn.apache.org/r1637743 ] LUCENE-5953 : Revert changes to SnapShooter, just remove useless locking. The tests now pass more often, because snapshot directory does not disappear suddenly (its created explicitely before file copying
          Hide
          ASF subversion and git services added a comment -

          Commit 1637744 from Uwe Schindler in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1637744 ]

          Merged revision(s) 1637743 from lucene/dev/trunk:
          LUCENE-5953: Revert changes to SnapShooter, just remove useless locking. The tests now pass more often, because snapshot directory does not disappear suddenly (its created explicitely before file copying

          Show
          ASF subversion and git services added a comment - Commit 1637744 from Uwe Schindler in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1637744 ] Merged revision(s) 1637743 from lucene/dev/trunk: LUCENE-5953 : Revert changes to SnapShooter, just remove useless locking. The tests now pass more often, because snapshot directory does not disappear suddenly (its created explicitely before file copying
          Hide
          Anshum Gupta added a comment -

          Bulk close after 5.0 release.

          Show
          Anshum Gupta added a comment - Bulk close after 5.0 release.

            People

            • Assignee:
              Uwe Schindler
              Reporter:
              Uwe Schindler
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development