ctubbsii commented on issue #2474: URL: https://github.com/apache/accumulo/issues/2474#issuecomment-1057420566
> That's interesting. We have discussed using `sync` previously with ZooKeeper, but I don't think we are actually using it anywhere in Accumulo. Presumably you only need to do the third sync call from above, on `txdir`, before checking the status? I tried only doing the last one. It didn't exist yet (or the client wasn't aware of its existence), so it had nothing to sync on. I had to sync the parents so knowledge of the children were updated before I could sync the child nodes. It's possible I only needed to sync the parent, though... if the sync is effectively recursive... I'm not sure exactly how it works, only that some aggressive syncing did solve the test failure. > This might not be an issue with `Fate` because it all runs in the `Manager` process and the FaTE transaction runner threads are likely using a shared `ZooReaderWriter` from the `ServerContext`. This seems very similar to using the Java `volatile` modifier. 1. ZooReaderWriter is merely a utility wrapper that adds methods to a ZooKeeper composed within it. It has no state itself, so whether it is shared or not has no influence on the matter. Furthermore, it should use the same ZooKeeper session provided by the ZooSession singleton, so it doesn't matter if you construct a new ZRW or reuse it. 2. Similarly, the ZooKeeper composed within it is itself contained within a ZooSession singleton, and can be replaced if the old ZooKeeper session dies. So, there's no guarantee that you reuse the same ZooKeeper object. 3. And finally, sync is sometimes necessary because you can be talking to a different ZooKeeper server, which ZooKeeper objects can transparently switch between, and not necessarily because of a different ZooKeeper client instance being used. I would imagine that it would stay sync'd for actions performed by the same ZooKeeper client instance, even if it transparently switches to another server, but I don't know what guarantees there are for that. In any case, even if sync isn't necessary for item 3 in this list (assuming the same ZK object stays sync'd when it switches servers transparently), which I'm not sure about, we don't have guarantees over item 2... because ZooSession can change the ZooKeeper object used. These are part of the things I'm trying to investigate in #2298 when I encountered this. However, progress is slow on that because of the complications involving the deprecated Instance/Connector objects and their requirements to use the singleton ZooKeeper sessions, and we can't remove those until 3.0. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
