Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of cf@renttherunway.com
 designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
Sender: cf@renttherunway.com
In-Reply-To: <0834A03B-F1DB-4A68-BD88-E725DC766802@groovie.org>
References: <0834A03B-F1DB-4A68-BD88-E725DC766802@groovie.org>
Date: Wed, 11 Sep 2013 17:17:18 -0400
Message-ID: 
 <CAKF1A=tUaPw44K-6LuyjEAZoa0MkN6fLdZX0jKiKqaJfLqrDkQ@mail.gmail.com>
Subject: Re: Clarification of watch behavior at the Zookeeper Server
From: Camille Fournier <camille@apache.org>
To: "bookkeeper-user@zookeeper.apache.org" <user@zookeeper.apache.org>
Content-Type: multipart/alternative; boundary=001a1132f26a7ad3f304e6222550

--001a1132f26a7ad3f304e6222550
Content-Type: text/plain; charset=ISO-8859-1

OK here goes:

As far as I can tell from the code, the watches are resent by the client
connection when it connects to a new server. See ClientCnxn.primeConnection
particularly starting line 894. So whenever you connect to a server, we
resend the live watches. I don't see anything obvious to indicate that if
you reconnect to the same server we wouldn't do that, doesn't look like we
track who we were connected to and doesn't look like this is done on the
server side, but rather on the client side.

"I see from the Java server code that the watches are held at the
individual server. So if you connect to a new server but the session has
not expired, the watch is obviously not registered there, so it's sent a
session event? Which session event?"

It's sent as a setWatches event, added to the outgoing queue after a
connection request for the session, then auth (then watches).
I think the docs are probably imprecise but I don't think this is actually
about connecting to a NEW server, so much as getting disconnected and
reconnected at all.

Inside the server, when you resend those new watches, you send them
associated with a last seen zxid. They are registered in the server as a
HashSet to the Watcher object, which is in fact the ServerCnxn that you've
created with the client. So if for some reason that ServerCnxn object is
the same it wouldn't actually add anything new but I don't think that can
ever be the case. It will use that last seen zxid to check if there were
any changes and send a notification on those changes. The watch will come
in on the SyncConnected state so you know that this happened while you were
disconnected.


Yes, it's controlled by a variable and no, I have no idea why.


I'm sure this isn't answering everything, please feel free to ask
clarifying questions.

C


On Thu, Sep 5, 2013 at 6:12 PM, Ben Bangert <ben@groovie.org> wrote:

> I was wondering if someone could clarify watches, was having a tough time
> following the Java code and the docs seemed.... vague. The docs in question:
>
> "Watches are maintained locally at the ZooKeeper server to which the
> client is connected. This allows watches to be light weight to set,
> maintain, and dispatch. When a client connects to a new server, the watch
> will be triggered for any session events. Watches will not be received
> while disconnected from a server. When a client reconnects, any previously
> registered watches will be reregistered and triggered if needed."
>
> So.....
> 1) Watches are fired once, and only once. (Per docs)
> 2) This states that upon reconnect (but not during disconnect), the watch
> will be triggered for session events.
> 3) Upon client reconnect, previous registered watches will be reregistered
> and triggered (therefore another watch notification?)
>
> Kazoo does these things quite differently, but the end behavior is
> apparently identical. So, a few questions...
>
> I see from the Java server code that the watches are held at the
> individual server. So if you connect to a new server but the session has
> not expired, the watch is obviously not registered there, so it's sent a
> session event? Which session event?
>
> If you reconnect to the same server, the watch is not triggered at all,
> unless something happens after its reregistered? If nothing happened, then
> the watch is not triggered at all even though the connection was lost and
> re-established?
>
> Is the client expected to reregister the watch if it connects to a new
> server and the session is still valid?
>
> There's a Zookeeper environment variable that turns auto-reregistration
> off in the Zookeeper server, why would this exist?  Wouldn't it break the
> expectations of every client?
>
> If the server is holding a watch registry and re-registers it should the
> client come back before the session expires, why? In a real production
> setup, most clients will rotate through a list of servers, so it seems
> remote that with 5+ ZK machines that upon disconnect the client will happen
> to reconnect to the exact machine it was just at.
>
> Cheers,
> Ben
>

--001a1132f26a7ad3f304e6222550--