is_unrecoverable() means exactly that: the session is toast. nothing you
do will get it back.
zookeeper_init is almost never used with a non-null client_id. the main
use case for it is crash recovery. i've rarely seen it used, but you can
start a session, save off the client_id to disk, create
> 2) Session events can *only* be observed by setting a watch
> explicitly, so one has to do something similar to wexists("/",
> observe_change_func) in their preferred client API to set a hook which
> will purposefully wait on a session change.
I see I got this part wrong already. I missed the c
On Thu, Nov 18, 2010 at 3:46 PM, Jeremy Hanna
wrote:
> Unless I misunderstand, active watches aren't open sessions. If that's the
> case, I don't think we'll hit the 10K-20K number of open sessions at a given
> time. However, that's a good boundary to keep in mind as we put the system
> together
> why don't you let the client library do the move for you?
Maybe there's no need to reestablish the session manually, but there
are a few details in the API which give a hint this should be
supported. The strongest one is that there's a parameter in
zookeeper_init() to allow reestablishing an ex
Camille and Patrick,
Thank you for your feedback and suggestions.
Unless I misunderstand, active watches aren't open sessions. If that's the
case, I don't think we'll hit the 10K-20K number of open sessions at a given
time. However, that's a good boundary to keep in mind as we put the system
to
At canonical we've been using zookeeper heavily in the development of a new
project (ensemble) as noted by gustavo.
I just wanted to give a quick overview of the client library we're using for
it. Its called txzookeeper, its got 100% test coverage, and implements
various queue, lock, and utilities
oops, sorry camille, i didn't mean to replicate your answer. you
explained it better than me :)
ben
On 11/18/2010 10:06 AM, Fournier, Camille F. [Tech] wrote:
This is exactly the scenario that you use to test session expiration, make one
connection to a ZK and then another with the same sessi
ah i see. you are manually reestablishing the connection to B using the
session identifier for the session with A.
the problem is that when you call "close" on a session, it kills the
session. we don't really have a way to close a handle without do that.
(actually there is a test class that do
We tested up to the ulimit (~16K) of connections against a single server and
performance was ok, but I would definitely try to do some serious load testing
before I put a system into production that I knew was going to have that load
from the get-go.
The system degrades VERY ungracefully when yo
> Right now, if you have a partition between client and server A, I would not
> expect
> server A to see a clean close from the client, but one of the various
> exceptions
> that cause the socket to close.
Please don't get me wrong, but I find it very funny to rely on the
stability of a network
fyi: I haven't heard of anyone running over 10k sessions. I've tried
20k before and had issues, you may want to look at this sooner rather
than later.
* Server gc tuning will be an issue (be sure to use cms/incremental).
* Be sure to disable clients accessing the leader (server configuration param
Hi Ben,
> that quote is a bit out of context. it was with respect to a proposed
> change.
My point was just that the reasoning why you believed it wasn't a good
approach to kill ephemerals in that old instance applies to the new
cases I'm pointing out. I wasn't suggesting you agreed with my new
Hi Camille,
> Check out ZKClient: https://github.com/sgroschupf/zkclient
>
> The way this client deals with sessions is pretty nice and clean and I ended
> up using a lot of this code as the basis for my Java client.
Looking at the code base feels like a pretty dumb wrapper on top of
standard ZK
that quote is a bit out of context. it was with respect to a proposed
change.
in your scenario can you explain step 4)? what are you closing?
ben
On 11/18/2010 07:16 AM, Gustavo Niemeyer wrote:
Greetings,
As some of you already know, we've been using ZooKeeper at Canonical
for a project we'v
Check out ZKClient: https://github.com/sgroschupf/zkclient
The way this client deals with sessions is pretty nice and clean and I ended up
using a lot of this code as the basis for my Java client.
C
-Original Message-
From: Gustavo Niemeyer [mailto:gust...@niemeyer.net]
Sent: Thursday,
>> Can you clarify what you mean when you say 10-100K watchers? Do you mean
>> 10-100K clients with 1 active watch, or some lesser number of clients with
>> more watches, or a few clients doing a lot of watches and other clients
>> doing other things?
Probably 10-100K clients each with 1 or 2 a
Hello again,
Even though we've been using ZooKeeper for some time, just now we're
stopping and thinking through to see how to best deal with session
events in the context of a whole application.
To ensure I'm not off track, my understanding of session and session
event handling is:
1) It is an e
This is exactly the scenario that you use to test session expiration, make one
connection to a ZK and then another with the same session and password, and
close the second connection, which causes the first to expire. It is only a
clean close that will cause this to happen, though (one where the
Camille, that's a very good question. Largest cluster I've heard about
is 10k sessions.
Jeremy - largest I've ever tested was a 3 server cluster with ~500
sessions. Each session created 10k znodes (100bytes each znode) and
set 5 watches on each. So 5 million znodes and 25million watches. I
then ha
Can you clarify what you mean when you say 10-100K watchers? Do you mean
10-100K clients with 1 active watch, or some lesser number of clients with more
watches, or a few clients doing a lot of watches and other clients doing other
things?
-Original Message-
From: Jeremy Hanna [mailto:
I had a question about number of clients against a zookeeper cluster. I was
looking at having between 10,000 and 100,000 (towards 100,000) watchers within
a single datacenter at a given time. Assuming that some fraction of that
number are active clients and the r/w ratio is well within the zoo
Greetings,
As some of you already know, we've been using ZooKeeper at Canonical
for a project we've been pushing (Ensemble, http://j.mp/dql6Fu).
We've already written down txzookeeper (http://j.mp/d3Zx7z), to
integrate the Python bindings with Twisted, and we're also in the
process of creating a G
Hi all,
I would like to customize the config of Zookeeper so that when a client is
disconnected, the server will instantaneously remove all ephemeral nodes
associated with the client.
No wait for session timeout or at least a very small amount of time. But I
would like to keep the feature that whe
23 matches
Mail list logo
