[GitHub] [accumulo] EdColeman opened a new issue, #3005: Bypass cache on property updates.

[GitBox <gi...@apache.org>]

EdColeman opened a new issue, #3005:
URL: https://github.com/apache/accumulo/issues/3005

   The prop store has a method to get values directly from ZooKeeper that does not use the cache.  When updating properties this may help reduce the concurrency issues that are seen with the multiple property updates.
   
   Instead of using:
   
    ```java
   context.getPropStore().get(TablePropKey.of(context, tableId)))
   ```
   
   and equivalent call using
   
   ```java
   context.getPropStore().getWithoutCaching(SystemPropKey.of(context))
   ```
   
   The basic idea is that the getWithoutCaching method existed to read the vprops directly from ZooKeeper and does not add the returned value to the local cache.  The process reading / updating the value might not ever host anything that would benefit from caching and may help to reduce update race conditions because its not relying on watcher notification to update or invalidate the cached values.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [accumulo] cshannon commented on issue #3005: Bypass cache on property updates.

[GitBox <gi...@apache.org>]

cshannon commented on issue #3005:
URL: https://github.com/apache/accumulo/issues/3005#issuecomment-1304560557

   @EdColeman - This is an interesting idea. So to make sure I understand correctly the goal here would be to:
   
   1. Read any properties to update directly from Zookeeper without going through the cache.
   2. Update the properties directly in zookeeper without modifying the cache.
   3. Any values not already cached won't be added but anything that was cached would be reloaded on future cache reads because entries that had been cached but just were updated in ZK would be invalided since we listen to the ZK events and get notified of the update.
   
   Assuming I have that correct that seems reasonable to me. Making sure to read/update to ZK directly makes sense for updates as caching should primarily exist for making reads fast. Updates are generally not going to happen too often under normal conditions for properties so making sure to update directly to ZK and leaving the caching for the read use case primarily for performance makes sense.
   
   Do I have that correct? I can poke around this a bit when I have some time and see what kind of changes would be involved and the impact of the change if you haven't looked at it yet.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org