Hello All, So I've been working on an implementation of a BlockingQueue for Menagerie<http://github.com/openUtility/menagerie> (shameless plug!), and I keep running into complications because of some compound actions, so I thought I would bring it up to the community at large.
To fully implement a java.util.concurrent.BlockingQueue, you need to implement a take() operation that blocks until an entry is added, then get the data for that entry and delete it. Unfortunately, the ZooKeeper API makes getting data from a znode a distinct, separate action from a delete operation which isn't atomic. Thus, in order to perform a take, I have to first grab a distributed Lock on the head node, just because a delete-and-get operation is not atomic. This seems very much like excessive locking that could be easily circumvented with an atomic get-and-delete operation. It seems like it would be a very powerful option to be able to have a "delete-and-return" operation that atomically deletes a znode, and returns the bytes that were previously stored in that znode. Is there a particular reason why this was not chosen as the behavior of the API? In most of the other generic compare-and-swap operations (put-if-absent and set-if-matches), there is already a mechanism in place, or one can relatively easily be implemented, but this seems like an odd oversight. I saw that ZooKeeper-965<https://issues.apache.org/jira/browse/ZOOKEEPER-965> could potentially address this in the future, but it seems like API overkill for something like this.
