Github user arina-ielchiieva commented on a diff in the pull request:
https://github.com/apache/drill/pull/755#discussion_r171088565
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/store/sys/store/LocalPersistentStore.java
---
@@ -112,23 +127,65 @@ public static DrillFileSystem
getFileSystem(DrillConfig config, Path root) throw
@Override
public Iterator<Map.Entry<String, V>> getRange(int skip, int take) {
+ //Marking currently seen modification time
+ long currBasePathModified = 0L;
+ try {
+ currBasePathModified =
fs.getFileStatus(basePath).getModificationTime();
+ } catch (IOException ioexcp) {
+ ioexcp.printStackTrace();
+ }
+
+ //Acquiring lock to avoid reloading for request coming in before
completion of profile read
--- End diff --
1. Before reading lock acquirement was enough, with your changes you modify
class fields. Since many threads can access this method, you'll end up with
raise conditions, also class fields can be cached by threads as well... I think
design here should be reconsidered.
2. Guava library has several cache implementations. Can we leverage any of
them instead of using tree set?
Pinging @vlad since he is working on DRILL-6053 which intends to make
changes in the same class to avoid excessive locking to be aware of intended
changes.
---
