kotman12 opened a new issue, #1246: URL: https://github.com/apache/curator/issues/1246
The current `CachedModeledFrameworkImpl` doesn't manage cache initialization for you. A perfect example of the kind of code you can expect to see in the wild is in the `CachedModeledFramework` tests themselves, i.e. blocking on semaphores that pin the reading thread to prevent it from certain operations that are cache dependent (but as far as I can tell exactly _which_ operations are cache dependent is not really guaranteed so this is arguably cumbersome). Either way, this is fine in a lot of cases... However, I propose an additional `InitializedCachedModeledFramework` implementation which asynchronously waits for the cache initialization trigger and only _then_ proceeds to read from the cache. I implemented something similar for my personal use-case where I couldn't rely on, i.e. `readThrough`, to handle the uninitialized case because `readThrough` cannot disambiguate between a znode that is missing because it truly is missing from zk vs one that is missing because the cache hasn't initialized. In my case the znode wouldn't always exist in zk and so using `readThrough` would result in a lot of wasted calls to zk, greatly reducing the benefit of the cache in the first place. To reiterate `InitializedCachedModeledFramework` has a couple benefits over the existing implementation: 1. No more possibility of misleading `NoNodeException` in the case of reading from `CachedModeledFramework` _before_ the cache has warmed. (I say misleading because the node may exist .. just not in the cache) 2. No more temptation to add blocking semaphores in front of this non-blocking interface. 3. IMO generally less [confusion about how to properly use](https://stackoverflow.com/questions/65328623/how-to-be-notified-when-cachedmodeledframework-is-initialized) this otherwise great(!) feature. -- 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: dev-unsubscr...@curator.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
