Thomas -
I like the ideas of your proposal, it seems very natural to use
Callable/Future for zk operations rather than something with more
opaque semantics (does this method block? etc.). Let's discuss this
more, I'd be more than happy to help out.
We're still using 3.2.1 so I'll probably have to
Jun Rao:
> Hi,
>
> ZkClient (http://github.com/sgroschupf/zkclient) provides a nice wrapper
> around the ZooKeeper client and handles things like retry during
> ConnectionLoss events, and auto reconnect. Does anyone (other than Katta)
> use it? Would people recommend using it? Thanks,
>
> Jun
Hi
I use it at my job at kaChing. Generally it is just fine for the job,
doing what you'd expect.
My criticisms are that it is very thin on documentation (javadoc),
which may have been improved, and I don't like how it makes every zk
exception into a RuntimeException.
But I'm thumbs up.
.. Adam
On
While I agree DS is hard, I don't think we should lose the useful
feedback given by Jonathan/Adam - that getting started with ZK is
challenging and can be frustrating. We need to learn from this feedback
and create some action items to address. One of the main things I've
heard so far that we c
Thanks Travis, I've slated this for 3.4.0, I think it would be useful to
add more examples so feel free to add more if you have any ideas for
useful ones.
For future reference, we ask that contributions come in the form of a patch:
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
It's f
On Tue, May 4, 2010 at 3:45 PM, Ted Dunning wrote:
> Travis,
>
> Attachments are stripped from this mailing list. Can you file a JIRA and
> put your attachment on that instead?
>
> Here is a link to get you started:
> https://issues.apache.org/jira/browse/ZOOKEEPER
Whoops. Filed:
https://issues
Travis,
Attachments are stripped from this mailing list. Can you file a JIRA and
put your attachment on that instead?
Here is a link to get you started:
https://issues.apache.org/jira/browse/ZOOKEEPER
On Tue, May 4, 2010 at 3:43 PM, Travis Crawford wrote:
> Attached is a skeleton application I
Creating recipes is a great thing, but that doesn't change the fact that
distributed systems are inherently a bit tricky, especially if you start
with the assumption (as many people do) that Peter Deutsch was wrong.
One of the great contributions of MapReduce style parallelism or the java
concurre
Attached is a skeleton application I extracted from a script I use --
perhaps we could add this as a recipe? If there are issues I'm more
than happy to fix them, or add more comments, whatever. It took a
while to figure this out and I'd love to save others that time in the
future.
--travis
On Tu
I don't think that zk is hard to get right.
What is hard is to layer a very different model on top of ZK that changes
the semantics significantly and that that translation right.
One of the very cool things about ZK is how easy it is to write correct
code. I know that Ben and co put a lot of tho
I'll check it out, but it is repeated in this list and on the web site
that it's not as easy as it seems. I just want to enumerate the
failure points and create abstractions to avoid them.
.. Adam
On Tue, May 4, 2010 at 3:16 PM, Mahadev Konar wrote:
> Hi Adam,
> I don't think zk is very very ha
Hi Adam,
I don't think zk is very very hard to get right. There are exmaples in
src/recipes which implements locks/queues/others. There is ZOOKEEPER-22 to
make it even more easier for application to use.
Regarding re registration of watches, you can deifnitely write code and
submit is as a part
I use zkclient in my work at kaChing and I have mixed feelings about
it. On one hand it makes "easy things easy" which is great, but on the
other hand I very few ideas what assumptions it makes "under the
hood". I also dislike some of the design choices such as unchecked
exceptions, but that's neit
In general, writing this sort of layer on top of ZK is very, very hard to
get really right for general use. In a simple use-case, you can probably
nail it but distributed systems are a Zoo, to coin a phrase. The problem is
that you are fundamentally changing the metaphors in use so assumptions ca
Take a look at this thread for some background.
http://www.mail-archive.com/zookeeper-user@hadoop.apache.org/msg00917.html
There were some concerns at the time, not sure if they have been
addressed since (It has been a while since that discussion).
Patrick
On 05/04/2010 01:48 PM, Jonathan Hol
It looks good, having written a client already myself, I'd rather use this
than have to roll
my own each time.
Is there any reason why this isn't part of the Zookeeper trunk already?
It would make working with Zookeeper a bit easier (at least from my
perspective)...
Jon.
On 4 May 2010 12:57, Te
This is used as part of katta where it gets a fair bit of exercise at low
update rates with small data. It is used for managing the state of the
search cluster.
I don't think it has had much external review or use for purposes apart from
katta. Katta generally has pretty decent code, though.
On
THat would be a great way to get really good feedback.
On Thu, Aug 13, 2009 at 4:13 PM, Stefan Groschupf wrote:
> If we have something clean and stable running we might contribute it back
> to the apache zk project.
--
Ted Dunning, CTO
DeepDyve
18 matches
Mail list logo
