You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@curator.apache.org by "kezhuw (via GitHub)" <gi...@apache.org> on 2023/09/02 14:54:42 UTC

[GitHub] [curator] kezhuw commented on pull request #478: CURATOR-688. SharedCount will be never updated successful when version of ZNode is overflow.

kezhuw commented on PR #478:
URL: https://github.com/apache/curator/pull/478#issuecomment-1703855895

   @Hexiaoqiao Sorry for the delay. I am stuck about and also fearing this overflow things. There are not simple bugs, there are limitations. Hard to fix, only fragile workaround for best wish. I have some chaos thoughts for this issue:
   1. Curator guarantees no ordering-ness about  `VersionedValue.getVersion`. That is good. Better to document this out of order issue or make it private in future.
   2. The promise about "up-to-date" should be guaranteed.
   3. Silent "never update" is not good which is the goal for us to fix here.
   
   I am ok to a workaround but I am also think exception(e.g. let caller know they hit an implementation limitation) is a good fallback except for background watcher. Though, I am not positive to a good workaround. I think there are few choices when encountering this hard limitation.
   1. Push foward underlying implementation. In this case, a `check_zxid` version of `setData` in ZooKeeper.
   2. Rewrites something in caller side. In this case, either curator side or your application.
   3. Fragile workaround.
   
   All these suggestions happened in https://lists.apache.org/thread/4o3rl49rdj5y0134df922zgc8clyt86s.  cc @li4wang 
   
   Besides above, did you find this in production ? What is your use case ? @Hexiaoqiao 


-- 
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: commits-unsubscribe@curator.apache.org

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