The idea behind 'myid'
Hi! Can someone pin-point me to a site (or please explain ) where I can read about the use of the myid-file for configuring the id of the ZooKeeper servers? I'm sure there is a good reason for using this approach, but it is the first time I have come over this type of non-automatic way for administrating replicas. Regards, Orjan
Re: The idea behind 'myid'
can you clarify what you are asking for? are you just looking for motivation? or are you trying to find out how to use it? the myid file just has the unique identifier (number) of the server in the cluster. that number is matched against the id in the configuration file. there isn't much to say about it: http://hadoop.apache.org/zookeeper/docs/r3.2.1/zookeeperStarted.html ben Ørjan Horpestad wrote: Hi! Can someone pin-point me to a site (or please explain ) where I can read about the use of the myid-file for configuring the id of the ZooKeeper servers? I'm sure there is a good reason for using this approach, but it is the first time I have come over this type of non-automatic way for administrating replicas. Regards, Orjan
Re: The idea behind 'myid'
Hi Ben Well, im just wondering why the server's own unique IP-address isn't good enough as a valid identifyer; it strikes me to be a bit exhausting to manually set the id for each server in the cluster. Or maybe there is some details im not getting here :-) Regards, Orjan On Fri, Sep 25, 2009 at 3:56 PM, Benjamin Reed br...@yahoo-inc.com wrote: can you clarify what you are asking for? are you just looking for motivation? or are you trying to find out how to use it? the myid file just has the unique identifier (number) of the server in the cluster. that number is matched against the id in the configuration file. there isn't much to say about it: http://hadoop.apache.org/zookeeper/docs/r3.2.1/zookeeperStarted.html ben Ørjan Horpestad wrote: Hi! Can someone pin-point me to a site (or please explain ) where I can read about the use of the myid-file for configuring the id of the ZooKeeper servers? I'm sure there is a good reason for using this approach, but it is the first time I have come over this type of non-automatic way for administrating replicas. Regards, Orjan
Re: The idea behind 'myid'
A server doesn't have a unique IP address. Each interface can have 1 or more IP addresses and there can be many interfaces. Furthermore, an IP address can move from one machine to another. 2009/9/25 Ørjan Horpestad orj...@gmail.com Hi Ben Well, im just wondering why the server's own unique IP-address isn't good enough as a valid identifyer; it strikes me to be a bit exhausting to manually set the id for each server in the cluster. Or maybe there is some details im not getting here :-) Regards, Orjan On Fri, Sep 25, 2009 at 3:56 PM, Benjamin Reed br...@yahoo-inc.com wrote: can you clarify what you are asking for? are you just looking for motivation? or are you trying to find out how to use it? the myid file just has the unique identifier (number) of the server in the cluster. that number is matched against the id in the configuration file. there isn't much to say about it: http://hadoop.apache.org/zookeeper/docs/r3.2.1/zookeeperStarted.html ben Ørjan Horpestad wrote: Hi! Can someone pin-point me to a site (or please explain ) where I can read about the use of the myid-file for configuring the id of the ZooKeeper servers? I'm sure there is a good reason for using this approach, but it is the first time I have come over this type of non-automatic way for administrating replicas. Regards, Orjan -- Ted Dunning, CTO DeepDyve
Re: The idea behind 'myid'
Another way of doing it, though, would be to tell each instance which IP to use at startup. That way the config can be identical for all users, and there can be whatever logic is required to figure out the right IP address, in the place where logic executing anyhow. I do agree that maintaining the myid file is ackward compared to other approaches that are working elsewhere. It's not really clear what purpose the my id serves except to bind an ip address to a running instance. cheers, Eric Ted Dunning wrote: A server doesn't have a unique IP address. Each interface can have 1 or more IP addresses and there can be many interfaces. Furthermore, an IP address can move from one machine to another. 2009/9/25 Ørjan Horpestad orj...@gmail.com Hi Ben Well, im just wondering why the server's own unique IP-address isn't good enough as a valid identifyer; it strikes me to be a bit exhausting to manually set the id for each server in the cluster. Or maybe there is some details im not getting here :-) Regards, Orjan On Fri, Sep 25, 2009 at 3:56 PM, Benjamin Reed br...@yahoo-inc.com wrote: can you clarify what you are asking for? are you just looking for motivation? or are you trying to find out how to use it? the myid file just has the unique identifier (number) of the server in the cluster. that number is matched against the id in the configuration file. there isn't much to say about it: http://hadoop.apache.org/zookeeper/docs/r3.2.1/zookeeperStarted.html ben Ørjan Horpestad wrote: Hi! Can someone pin-point me to a site (or please explain ) where I can read about the use of the myid-file for configuring the id of the ZooKeeper servers? I'm sure there is a good reason for using this approach, but it is the first time I have come over this type of non-automatic way for administrating replicas. Regards, Orjan -- Eric Bowman Boboco Ltd ebow...@boboco.ie http://www.boboco.ie/ebowman/pubkey.pgp +35318394189/+353872801532
Re: The idea behind 'myid'
you and ted are correct. the id gives zookeeper a stable identifier to use even if the ip address changes. if the ip address doesn't change, we could use that, but we didn't want to make that a built in assumption. if you really do have a rock solid ip address, you could make a wrapper startup script that starts up and creates the myid file based on the ip address. i gotta say though, i've found that such assumptions are often found to be invalid. ben Eric Bowman wrote: Another way of doing it, though, would be to tell each instance which IP to use at startup. That way the config can be identical for all users, and there can be whatever logic is required to figure out the right IP address, in the place where logic executing anyhow. I do agree that maintaining the myid file is ackward compared to other approaches that are working elsewhere. It's not really clear what purpose the my id serves except to bind an ip address to a running instance. cheers, Eric Ted Dunning wrote: A server doesn't have a unique IP address. Each interface can have 1 or more IP addresses and there can be many interfaces. Furthermore, an IP address can move from one machine to another. 2009/9/25 Ørjan Horpestad orj...@gmail.com Hi Ben Well, im just wondering why the server's own unique IP-address isn't good enough as a valid identifyer; it strikes me to be a bit exhausting to manually set the id for each server in the cluster. Or maybe there is some details im not getting here :-) Regards, Orjan On Fri, Sep 25, 2009 at 3:56 PM, Benjamin Reed br...@yahoo-inc.com wrote: can you clarify what you are asking for? are you just looking for motivation? or are you trying to find out how to use it? the myid file just has the unique identifier (number) of the server in the cluster. that number is matched against the id in the configuration file. there isn't much to say about it: http://hadoop.apache.org/zookeeper/docs/r3.2.1/zookeeperStarted.html ben Ørjan Horpestad wrote: Hi! Can someone pin-point me to a site (or please explain ) where I can read about the use of the myid-file for configuring the id of the ZooKeeper servers? I'm sure there is a good reason for using this approach, but it is the first time I have come over this type of non-automatic way for administrating replicas. Regards, Orjan
How to expire a session
In the FAQ, there is a question
4. Is there an easy way to expire a session for testing?
And the last part of the answer reads:
In the case of testing we want to cause a problem, so to explicitly
expire a session an application connects to ZooKeeper, saves the
session id and password, creates another ZooKeeper handle with that
id and password, and then closes the new handle. Since both handles
reference the same session, the close on second handle will
invalidate the session causing a SESSION_EXPIRED on the first handle.
(I assume when it says ³creates another ZooKeeper handle² I¹m assuming it
means do that by calling init_zookeeper. Is that correct?
Here¹s my skeleton code, which doesn¹t work. ...
clientid_t myid;
clientid_t another_id;
zhandle_tzh_1;
zhandle_tzh_2;
zoo_deterministic_conn_order(1);
zh_1 = zookeeper_init ( servers, watcher, 1, myid, 0, 0);
if ( !zh_1 ) {
...error...
}
// Catch sigusr1 and set the havoc flag
if ( cry_havoc_and_let_loose_the_dogs_of_war ) {
memcpy ( another_id, myid, sizeof (clientid_t));
zh_2 = zookeeper_init ( servers, destroy_watcher, 1,
another_id, 0, 0);
if ( ! zh_2 ) {
errror ...
}
if ( !nzh ) {
... error ...
}
zookeeper_close ( zh_2);// Shouldn't I get a session expire
shortly after this?
}
But I don¹t get a session expire. Can someone tell me what I¹m doing wrong?
TIA,
Leonard
Leonard Cuff
lc...@valueclick.com
³This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use of the
intended recipient(s). Any disclosure, copying, distribution, posting, or
use of the information contained in or attached to this email is prohibited
unless permitted by the sender. If you have received this email in error,
please immediately notify the sender via return e-mail, telephone, or fax
and destroy this original transmission and its included files without
reading or saving it in any manner. Thank you.²
This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use
of the intended recipient(s). Any disclosure, copying, distribution,
posting, or use of the information contained in or attached to this
email is prohibited unless permitted by the sender. If you have
received this email in error, please immediately notify the sender
via return email, telephone, or fax and destroy this original transmission
and its included files without reading or saving it in any manner.
Thank you.
Re: The idea behind 'myid'
Benjamin Reed wrote: you and ted are correct. the id gives zookeeper a stable identifier to use even if the ip address changes. if the ip address doesn't change, we could use that, but we didn't want to make that a built in assumption. if you really do have a rock solid ip address, you could make a wrapper startup script that starts up and creates the myid file based on the ip address. i gotta say though, i've found that such assumptions are often found to be invalid. Yeah, it can be tricky. In more than one cluster, I've seen a set of static configuration files that gets replicated everywhere. If an individual instance needs per-instance configuration, we do that from the command line (using -D). Maybe logic can do it, or maybe a start script has to load a machine local file, whatever. It's a pretty common paradigm, though. It's hardly the end of the world, but it is definitely something my ops people stumbled over. -- Eric Bowman Boboco Ltd ebow...@boboco.ie http://www.boboco.ie/ebowman/pubkey.pgp +35318394189/+353872801532
Re: How to expire a session
so you have two problems going on. both have the same root:
zookeeper_init returns before a connection and session is established
with zookeeper, so you will not be able to fill in myid until a
connection is made. you can do something with a mutex in the watcher to
wait for a connection, or you could do something simple like:
while(zoo_state(zh_1) != ZOO_CONNECTED_STATE) {
sleep(1);
}
myid = *zoo_client_id(zh_1);
the second part of the problem is related. you need to make sure you are
connected before you do the close.
ben
Leonard Cuff wrote:
In the FAQ, there is a question
4. Is there an easy way to expire a session for testing?
And the last part of the answer reads:
In the case of testing we want to cause a problem, so to explicitly
expire a session an application connects to ZooKeeper, saves the
session id and password, creates another ZooKeeper handle with that
id and password, and then closes the new handle. Since both handles
reference the same session, the close on second handle will
invalidate the session causing a SESSION_EXPIRED on the first handle.
(I assume when it says ³creates another ZooKeeper handle² I¹m assuming it
means do that by calling init_zookeeper. Is that correct?
Here¹s my skeleton code, which doesn¹t work. ...
clientid_t myid;
clientid_t another_id;
zhandle_tzh_1;
zhandle_tzh_2;
zoo_deterministic_conn_order(1);
zh_1 = zookeeper_init ( servers, watcher, 1, myid, 0, 0);
if ( !zh_1 ) {
...error...
}
// Catch sigusr1 and set the havoc flag
if ( cry_havoc_and_let_loose_the_dogs_of_war ) {
memcpy ( another_id, myid, sizeof (clientid_t));
zh_2 = zookeeper_init ( servers, destroy_watcher, 1,
another_id, 0, 0);
if ( ! zh_2 ) {
errror ...
}
if ( !nzh ) {
... error ...
}
zookeeper_close ( zh_2);// Shouldn't I get a session expire
shortly after this?
}
But I don¹t get a session expire. Can someone tell me what I¹m doing wrong?
TIA,
Leonard
Leonard Cuff
lc...@valueclick.com
³This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use of the
intended recipient(s). Any disclosure, copying, distribution, posting, or
use of the information contained in or attached to this email is prohibited
unless permitted by the sender. If you have received this email in error,
please immediately notify the sender via return e-mail, telephone, or fax
and destroy this original transmission and its included files without
reading or saving it in any manner. Thank you.²
This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use
of the intended recipient(s). Any disclosure, copying, distribution,
posting, or use of the information contained in or attached to this
email is prohibited unless permitted by the sender. If you have
received this email in error, please immediately notify the sender
via return email, telephone, or fax and destroy this original transmission
and its included files without reading or saving it in any manner.
Thank you.
