zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: thoughts about extension to multi semantics
Date Sat, 17 Aug 2019 17:19:08 GMT
Some thoughts:

It doesn't really help with any of the "standard" recipes as they all need to set watches.
Not to open a can of worms, but if there were a firehose version of watches that could be
set independently, this type of multi-op could radically simplify some of the recipes. i.e.
one could imagine a multi-op that creates an ephemeral node and then returns a sorted list
of child node names so that leader election and locks can be done in one shot. 
An atomic counter could be done much more simply than how Curator does it now as the test/increment
could be done server side
Queues would be easier (possibly - I need to think about this some more). Curator's queue
code is very complex.

Anyway - I'll try to spend some time in Curator's various recipes to see how they would be
simplified if this server-side feature was available.

-Jordan

> On Aug 16, 2019, at 11:51 AM, Ted Dunning <ted.dunning@gmail.com> wrote:
> 
> The recent discussion about if/then/else idioms in ZK has raised the
> thought that it might be nice to have some extended semantics.
> 
> One version that I could see would be to to extend the current multi-op to
> allow multiple alternatives. The idea would be that there would effectively
> be multiple branches to be tried. The first one that succeeds atomically
> (all or nothing) would be used. The returned value would need to somehow
> indicate which alternative succeeded and would need to return any data
> accessed. The testing of alternatives would also be atomic so it wouldn't
> be possible for things to change within a single operation.
> 
> This extension would allow the previous question to be answered like this:
> 
>           pick_first {
>                 create(...)
>           } {
>                 set(...)
>           }
> 
> (the syntax here is just made up and wouldn't actually be supported ... it
> is just for pseudo code purposes).
> 
> 
> My theory is that this would be relatively easy to implement based on the
> current multi operation. Risk due to the change is pretty low given that
> there is code to copy.
> 
> My question is whether this would actually have all that much benefit.
> 
> Does anybody have an opinion on that?


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message