keith-turner commented on PR #5256:
URL: https://github.com/apache/accumulo/pull/5256#issuecomment-2605433098
It seems trying to use persistent recursive watches w/ ZooSession is a bit
tricky because persistent recursive watches have a lifecycle that is 1:1 w/ a
zookeeper object. The nice thing we get from ZooSession is the automated
retry, however it significantly complicates this 1:1 relationship. The
following is a half baked idea that is trying to reconcile these things in the
code, in this model there are two objects.
```java
// This contains all of the current ZooCache code, but it uses ZooKeeper
directly instead of ZooSession. Instances of this class use a single zookeeper
object for their lifetime (so the Zookeeper obj could be final). Also the set
of watched paths could be final and immutable.
class ZooCacheDirect {
}
```
```java
// All code in Accumulo uses this for caching zookeeper reads
class ZooCache {
// All reads are proxied to the internal zoo cache w/ reconnect handling
that will create an new internal zoocachedirect as needed.
AtomicReference<ZooCacheDirect> internalZooCache;
// However w/ this model it seems that ZooCache has to duplicate some of
the retry logic in ZooSession? Could this be refactored?
}
```
Not really sure about the above. Its an attempt to move the zoocache code
to having a 1:1 relationship w/ a zookeeper object in its internals because
this may simplify its impl and simplify reasoning abouts its correctness.
However unsure how the retry logic plays out in this model and if it duplicates
zoosession code.
--
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-unsubscr...@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
