zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject ANN: Curator 1.2.3
Date Sat, 06 Oct 2012 16:52:11 GMT
* Previously, all background operations (i.e. when the inBackground() method is used)
were put into a queue and processed in an internal thread. Curator does this to handle retries
background operations. This can be improved, however. The first time the background operation
executed the ZooKeeper method can be called directly - without queuing. This will get the
into ZooKeeper immediately and will help prevent Curator's internal queue from backing up.

* Issue 173: The DistributedQueue (and, thus, all the other queue recipes) was unnecessarily
calling getChildren (with a watch) after each group of children was processed. It can just
as easily
wait for the internal cache to get its watch notified. This change creates an edge case, though,
for ErrorMode.REQUEUE. Consequently, when in mode ErrorMode.REQUEUE the DistributedQueue now
deletes the bad message and re-creates it. This required the use of ZooKeeper 3.4.x's transactions.
So, if you use ErrorMode.REQUEUE you MUST be running ZooKeeper 3.4+.

View raw message