Patrick Hunt wrote:
> Have you heard anyone implementing webdav on top of zookeeper? Seems
> like it would be a pretty good match (my experience with webdav is
> limited though). There are lots of webdav clients and client libs available.
I know from experience with httpd that it is possible to create a
mod_dav provider that doesn't use a real filesystem as its repository,
so at least at a high level it should be possible with ZooKeeper as well.
It likely wouldn't be a trivial task, though.
I'm quite new to ZooKeeper, and only wrote my httpd module as a
trial of a not-yet-released httpd API. Based on my limited knowledge
so far, though, it would seem to be difficult or perhaps impossible to
make effective use of things like ephemeral nodes (a key building block
of things like locks, as I understand it) in a stateless or RESTful
context. If one could live without such things, though, I suppose
there could be some value in a DAV interface or something similar.
What I'm puzzling over at the moment is a slightly different issue,
though, and that's whether there's any value in pooling ZooKeeper
connections or not. I haven't grokked zookeeper.c and mt_adaptor.c
fully and so I can't determine if one could (or should) have a set of
"client" threads share a pool of ZooKeeper connections. Or would it
be better to have a single connection handle (and thus a single
pair of IO and completion threads) for a process, and allow multiple
"client" threads then use that sole handle? Is a ZooKeeper handle
thread-safe if used in this manner? It appears as if it might be.
Does anyone have experience with allowing multiple threads to use
a single zhandle_t simultaneously?
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Zookeeper-user mailing list