Announcement Recipe

55 views
Skip to first unread message

Eric Tschetter

unread,
Apr 16, 2013, 4:04:15 PM4/16/13
to curato...@googlegroups.com
I have the need for the ability to "announce" things on Zookeeper.  An announcement is just an ephemeral node that is alive as long as the node is alive.  

I would like for announcements to survive ZK disconnects, meddling hands deleting things and other such issues.  I'm thinking that curatorFramework.create.mode(EPHEMERAL).forPath will just create one node and not watch to make sure it doesn't get removed, etc.  Is that correct?  

If that is correct, is there a recipe that will do what I want, or do I need to create one?

If I have to create one, is this something that you would find useful for the main library (would you accept the pull request?)

--Eric

Brandon Beck

unread,
Apr 16, 2013, 5:27:27 PM4/16/13
to curato...@googlegroups.com
Hi Eric,

You're not the first to request this.  We at Bazaarvoice have the same needs (using ZK as the backing store for a SOA library).  We've created a recipe called PersistentEphemeralNode and have released it as part of our curator-extensions project (http://github.com/bazaarvoice/curator-extensions).  This is in maven central at com.bazaarvoice.curator:curator-extensions:1.1.1.  There's a NodeDiscovery recipe in there too for the component that needs to watch for these persistent ephemeral nodes (it just wraps PathChildrenCache).

I submitted a pull request for this implementation into curator, and Jordan is willing to have it as part of Curator proper, but my implementation has a few non-optimal implementation details.  The pull request is at: https://github.com/Netflix/curator/pull/201.  You can see the discussion there as to what is inferior about this implementation as well as Jordan's attempt to fix them.  I've been unable to get time at work to try to merge some ideas I have with Jordan's implementation.  Because of that things have lingered on much longer than they should.  You're free to use our implementations if you'd like though.  They're licensed under the Apache Open Source License just like Curator.

Thanks,
Brandon



--
You received this message because you are subscribed to the Google Groups "curator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to curator-user...@googlegroups.com.
To post to this group, send email to curato...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Eric Tschetter

unread,
Apr 16, 2013, 5:49:07 PM4/16/13
to curato...@googlegroups.com
Nice!  Unfortunately, it's common for my processes to each publish thousands of these ephemerals, so the one-thread-per limitation is going to bite me quickly.

This does at least verify that what I want doesn't exist...

--Eric 

Brandon Beck

unread,
Apr 16, 2013, 6:03:44 PM4/16/13
to curato...@googlegroups.com
The infrastructure is in place to pool the threads together, it's just not completely fleshed out yet.


Line 63 creates a new Executor.  If you were to accept it from the constructor instead and remove the shutdown/await on lines 81 and 82 then you can probably create many thousands of these with very few threads behind them.

I'm happy to accept a pull request (with tests) if you want it to make it into our maven central artifact.

I do feel like Jordan's approach (which doesn't use any additional threads) is definitely the way to go.  I just need to be really sure there aren't any race conditions in place.

Thanks,
Brandon

Jordan Zimmerman

unread,
Apr 16, 2013, 8:41:11 PM4/16/13
to curato...@googlegroups.com
Ha! We need more pressure on Brandon. Cheddar - please apply pressure as needed.

-JZ
Reply all
Reply to author
Forward
0 new messages