Closed aflatter closed 9 years ago
I think the registries should probably be actors. Now that https://github.com/celluloid/celluloid/pull/287 is landed and the inheritance anomalies have been eliminated, perhaps registries should descend from an abstract base class that includes Celluloid by default.
What about a delete method like I did here https://github.com/parcydo/dcell/commit/efdda59ddb90859a88516704f3b861eff7664d30, it's pretty much related to https://github.com/celluloid/dcell/issues/6
A TTL is one way to solve this but I do it right now different and this requires a delete in the registry.
node = DCell::Node[:foo]
dispatched = false
after(2) do
unless dispatched
Logger.warn "Delete node #{node.inspect}"
node.delete
end
end
dispatched = node[:bar].baz
In the floss
impl, the registry backends are actors.
I don't think we should have these actors as Cells, but perhaps we can wait for my celluloid/celluloid#291 PR.
@halorgium why not?
@tarcieri dunno, was a thought. the RPC overhead especially for the floss
project means double-accounting.
"Overhead" was my original motivation for designing the API the way it was. Fuck that. Make everything an actor FTW ;)
Haha! Good call. @aflatter would you feel OK spiking out an impl which used actors? I'm not sure how the bootup process would look like.
I should probably expound: lots of cases cropped up where the registry being an actor was advantageous. The most notable was Zookeeper where an actor could keep a local cache which Zookeeper could actively invalidate and replace with new values. Saving a network trip while still receiving push updates in realtime is a huge win
@tarcieri, @halorgium: I think the overhead is negligible for now. DCell::Registry::Base
already is an actor: https://github.com/aflatter/dcell/commit/b51d622026dcaec8ad2ea909701b3140dde0e16e#L2R2
@neonlex I don't really like exposing such functionality. The Node#delete
method removes a node from the directory, thus making it inaccessible for all other nodes too. DCell should handle node unavailability in a deterministic way, maybe using distributed concensus.
@tarcieri @aflatter @halorgium zeromq(czmq) can soonish be used to handle all registry needs, https://github.com/zeromq/czmq/blob/master/src/zgossip.c#L442 might be of interest.
Have also written a ruby ffi wrapper for czmq, here is a gossip example: https://github.com/Asmod4n/ruby-ffi-czmq/blob/master/examples/gossip.rb
Cool!
I've cleaned up a bit the Registry API in pull request #91 Though, as @tarcieri I have doubts whether those should be actors. I noticed a quite noticeable overhead in my stress testing. Probably a particular implementation should be an actor if registry BE library can't handle asynchronous requests. Mainly DCell does read access so I don't see a good reason to serialize access.
No feedback means everybody satisfied with current registry API?
As per celluloid/floss#14, the registry API is to be refactored. As per a discussion with @tarcieri on IRC, this includes the following changes:
A new API for implementing a registry.
A registry should be an actor too.
Refactor
Global
andDirectory
Provide a
NamespaceProxy
to DRY this up:One of the following:
DCell.global[:foo]
andDCell.directory[:bar]
(orDCell[:global, :foo]
)Node[:bar]
for the directory andDCell[:bar]
for globals.Opinions?