It feels like we need a flowchart, state-chart, or something, so we
can all talk about the same thing. Then people could suggest
abstractions that would essentially put a box around sections of the
diagram. However I feel woefully inadequate at the former :(.
.. Adam
On Thu, Jan 8, 2009 at 4:20 P
For your first issue if an ensemble goes offline and comes back, everything
should be fine. it will look to the client just like a server went down. if a
session expires, you are correct that the client will not reconnect. this again
is on purpose. for the node watcher the session is unimportant
On Thu, Jan 8, 2009 at 2:07 PM, Benjamin Reed wrote:
> if you do a getData("/a", true) and then "/a" changes, you will get a watch
> event. if "/a" changes again, you will not get an event. so, if you want to
> monitor "/a", you need to do a new getData() after each watch event to
> reregister th
>
>
> i just found that part of this thread went to my junk folder. can you send
> the URL for the NodeListener?
>
Sure... here you go:
http://pastebin.com/f1e9d3706
>
> this NodeWatcher is a useful thing. i have a couple of suggestions to
> simplify it:
>
> 1) Construct the NodeWatcher with a
On Thu, Jan 8, 2009 at 3:21 PM, Benjamin Reed wrote:
> InterruptedException is rather tricky because the semantics of
> Thread.isInterrupted() is rather vague. specifically, it is unclear why
> someone would interrupt a thread. usually Thread.interrupt() is used to shut
> things down which requir
InterruptedException is rather tricky because the semantics of
Thread.isInterrupted() is rather vague. specifically, it is unclear why someone
would interrupt a thread. usually Thread.interrupt() is used to shut things
down which requires special handing. thus we propagate it. for example, i'm n
Hey kevin,
i just found that part of this thread went to my junk folder. can you send the
URL for the NodeListener?
this NodeWatcher is a useful thing. i have a couple of suggestions to simplify
it:
1) Construct the NodeWatcher with a ZooKeeper object rather than constructing
one. Not only do
if you do a getData("/a", true) and then "/a" changes, you will get a watch
event. if "/a" changes again, you will not get an event. so, if you want to
monitor "/a", you need to do a new getData() after each watch event to
reregister the watch and get the new value. (re-registering watches on
r
Live in San Diego/Southern California and want to get together and talk
Hadoop/HBase/Mahout/Zookeeper/Thrift/Cloud/Pig/HBase/etc?
If so, please join us for the first San Diego Hadoop Users Group meeting
that will officially kick-off on January 28, 2009.
The agenda is still TBD, but will inclu
The next Bay Area Hadoop User Group meeting is scheduled for Wednesday,
January 21st at Yahoo! 2821 Mission College Blvd, Santa Clara, Building
1, Training Rooms 3 & 4 from 6:00-7:30 pm.
Agenda:
Hadoop 0.20 Overview - Sameer Paranjpye
Hadoop 1.0 discussion - Sanjay Radia.
Please send me a
>
>
> while the case in which a value only changes once, can be made slightly
> more optimal by passing the value in the watch event. it is not worth the
> risk. in our experience we had a application that was able to make that
> assumption initially and then later when the assumption became invali
just to clarify: you also get ConnectionLossException from syncronous requests
if the request cannot be sent or no response is received.
ben
-Original Message-
From: Patrick Hunt [mailto:ph...@apache.org]
Sent: Wednesday, January 07, 2009 10:16 AM
To: zookeeper-user@hadoop.apache.org
Su
I think you are looking at the race condition backwards. (and this btw is where
the users had many of their bugs.) remember watches are one time triggers. so
if you get a watch event it means a change has happened, so if /a is changed to
1 and then changed to 2. the data that will come back in t
We should expand that section. the current queue recipe guarantees that things
are consumed at most once. to guarantee at least the consumer creates an
ephemeral node queue-X-inprocess to indicate that the node is being processed.
once the queue element has been processed the consumer deletes qu
You can't simply leave an element in the queue until a consumer
finishes processing it, otherwise multiple consumers may end up
processing it. What about the following:
- Use a failure detector to detect which consumers are up;
- Before removing an element from the queue, a consumer creates a
I'm interested in using ZooKeeper to provide a distributed
producer/consumer queue for my distributed application.
Of course I've been studying the recipes provided for queues, barriers, etc...
My question is: how can I prevent packets of work from being lost if a
process crashes?
For example, f
I've updated based on the last round of feedback regarding ZK operation:
http://pastebin.com/f66898b7
This is what I think the API should look like for event based applications
without any insane requirements.
You write code like:
NodeListener listener = new NodeListener() {
17 matches
Mail list logo
