Description
Even with prefetch enabled having 2 CopyOnRead directories pointing to same index can lead to one of the instance reading index files directly off of remote index.
The reason this happens is because COR#copyFilesToLocal explicitly chooses to work with remote if index copier reports that a copy is in progress.
This wasn't a problem earlier when COR was only used via IndexTracker so concurrent COR instances weren't expected (COR's avoid local for conc copy was probably worried about non-prefetch case).
But with OAK-8097, DefaultDirectoryFactory also uses COR to bring the files. Which means that if there's a query against an index which is getting updated as well then either of COR instance could read directly from remote.
The condition should only be relevant during early app start up but since this can happen in default configuration, we should attempt to fix this.
Attachments
Issue Links
- causes
-
OAK-8542 Test failure: ConcurrentCopyOnReadDirectoryTest.concurrentPrefetchWithTimeout
- Closed
-
OAK-8554 IndexCopier#waitForCopyCompletion doesn't reset interrupted flag after catching InterruptedException
- Closed
-
OAK-8543 Javadoc of IndexCopier#waitForCopyCompletion refers to boolean return
- Closed
- is caused by
-
OAK-8097 Load Lucene index files before writing to the index
- Closed
- relates to
-
OAK-8512 Without prefetch CopyOnRead opens index files remotely even if they are locally available
- Open
-
OAK-8514 CoR should log a warn when opening remote index file when prefetch is enabled
- Closed