Re: Multiple ZK clusters or a single, shared cluster?
This may be true for monster clusters being supported by a ZK cluster or for data-intensive operations like high throughput queuing, but many applications of ZK are incredibly low volume. For instance, with Katta, there is a read-modify-write when a search engine comes up, when a shard is assigned or loaded, a dozen or so when an index is added and a few when the master fails. None of these operations occurs in practice even once an hour. I also log machine state across lots of machines once every few seconds (partly to give ZK something to do). That results in dozens (at most) of transactions per second. I think that a huge proportion of Zk clusters are going to have transactions per day rather than kilo transactions per second. At these rates, all you have to worry about is simultaneous failures ... make sure that the ZK cluster members are on separate power supplies and network switches. Beyond that, everything is over-kill. You could run on a cluster of iPhones and still be happy with performance. On Fri, Jul 17, 2009 at 1:38 PM, Benjamin Reed wrote: > the main thing is that you use dedicated zk machines (with a dedicated disk > for logging). once you have that in place, watch the load on your cluster, > as long as you aren't saturating the cluster you should share. > -- Ted Dunning, CTO DeepDyve
Re: Queue code
Depending on your needs, there may be other recipes as well that would give higher performance. For example, it might be preferable to keep the queue itself in a small-ish set of files that each hold many task items. Different implementations will give different trade-offs on speed, especially for extremely large queues of pending tasks. On Fri, Jul 17, 2009 at 1:20 PM, Mahadev Konar wrote: > > Also are there any performance numbers of zookeeeper based queues. How > does > > it compare with JMS. > -- Ted Dunning, CTO DeepDyve
Leader Elections
Zookeeper-Users, I'm configuring a zookeeper ensemble that will have servers across a WAN. However, I'd like to constrain the leader elections to elected leaders only from a pool of zookeeper servers in a centralized computing center. In this scenario, zookeeper servers at the edge of the WAN can be members of the ensemble, but not leaders. I anticipate that this will perform significantly better than forcing traffic from one edge of the WAN to another, for the case of a leader elected to a WAN edge node. -- WAN [POD (1..N)]* <--> [ DC ]** * contains multiple zk servers, but no leaders ** contains multiple zk servers, each may be a leader -- Are there a configuration parameters that will accomplish this, or do I need to patch ZK? I'm a bit confused by the 3.2.0 admin documentation in this respect: http://hadoop.apache.org/zookeeper/docs/r3.2.0/zookeeperAdmin.html#sc_mo nitoring """ leaderServes (Java system property: zookeeper.leaderServes) Leader accepts client connections. Default value is "yes". The leader machine coordinates updates. For higher update throughput at thes slight expense of read throughput the leader can be configured to not accept clients and focus on coordination. The default to this option is yes, which means that a leader will accept client connections. Note Turning on leader selection is highly recommended when you have more than three ZooKeeper servers in an ensemble. """ Q: The leaderServers property seems to be an optimization that favors updates at the expense of reads. Fine. But the note below that doesn't make sense to me... What does it mean to turn on leader selection? Does this mean to configure leaderServes="yes"? Is serving the same as selecting? Perhaps there is a typo here... Q: The next items on this web page mention configuring groups and assigning a weight to the votes of machines in those groups. If I am defining an ensemble with groups of machines that I do not want elected as leaders, would I assign them to a group and set their voting weight to zero? Is that the expected practice? """ group.x=n[:n] (No Java system property) Enables a hierarchical quorum construction."x" is a group identifier and the numbers following the "=" sign correspond to server identifiers. The left-hand side of the assignment is a colon-separated list of server identifiers. Note that groups must be disjoint and the union of all groups must be the ZooKeeper ensemble. weight.x=n (No Java system property) Used along with "group", it assigns a weight to a server when forming quorums. Such a value corresponds to the weight of a server when voting. There are a few parts of ZooKeeper that require voting such as leader election and the atomic broadcast protocol. By default the weight of server is 1. If the configuration defines groups, but not weights, then a value of 1 will be assigned to all servers. """ -Todd
Re: Multiple ZK clusters or a single, shared cluster?
You don't need a dedicated disk for performance purposes if: You use an SSD (which the decent ones have sub 0.1ms write latency) Or You have a battery backed cache RAID card with write-back cache enabled so that synchronous writes return nearly instantly. Its just the synchronous write latency for write performance. If Linux with ext3 and the default mount options, this can be really bad if shared with other uses. Additionally a separate disk won't have to seek as much if only one app is writing to it. Given the price of a raid card, and the fact that the logs don't need that much space, I'd go for the ~$370 Intel 32GB X-25E SSD if you are performance sensitive. On 7/17/09 2:26 PM, "Benjamin Reed" wrote: you need a dedicated disk for the logDir, but not the dataDir. the reason is that the write to the log is in the critical path: we cannot commit changes until they have been synced to disk, so we want to make sure that we don't contend for the disk. the snapshots in the dataDir are done in an asynchronous thread, so it can be written to a disk used by other applications (usually the OS disk). the problem with running other processes on the zookeeper server is similar to the disk contention: if zookeeper starts contending with a runaway app for CPU and memory, we can start timing out because of starvation. by using a dedicated disk for logs and a dedicated machine you can get very high deterministic performance. make sense? ben Jonathan Gray wrote: > Thanks for the input. > > Honestly, I'm thinking I need to have separate clusters. The version of > ZK is one thing; but also for an application like HBase, we have had > periods where we needed to patch ZK before it became part of a release. > Keeping track of that on a shared cluster will be tricky, if not > impossible. > > And with a small development team and a very fast dev cycle, I'm a > little concerned about a runaway application hosing all the other > dependencies on ZK... > > What are the actual reasons for wanting a separate disk for ZK? > Strictly reliability purposes? Should that disk be dedicated to the > logDir but not the dataDir, or both? > > If I don't give it a dedicated disk or node, but it has 1GB of memory > and a core, what are the downsides? Are they just about reliability? > If I could run 5 or 7 zk nodes, but co-hosted with my HBase cluster, is > that really less reliable than 3 separate nodes, as long as the jvm has > sufficient resources? Or are there performance or usability concerns as > well? > > Sorry for all the questions, just trying to get the story straight so > that we don't spread misinformation to HBase users. Most users start > out on very small clusters, so dedicated ZK nodes are not a realistic > assumption... How big of a deal is that? > > JG > > Benjamin Reed wrote: > >> we designed zk to have high performance so that it can be shared by >> multiple applications. the main thing is that you use dedicated zk >> machines (with a dedicated disk for logging). once you have that in >> place, watch the load on your cluster, as long as you aren't saturating >> the cluster you should share. >> >> as you point out running multiple clusters is a hardware investment, >> plus you miss out on opportunities to improve reliability. for example, >> if you have three applications that have a cluster of 3 zk servers each, >> one failure will result in an outage. if instead of using the 9 servers >> you have the same three applications use a zk cluster with 7 servers you >> can tolerate three failures without an outage. >> >> the key of course is to make sure that you don't oversubscribe the server. >> >> ben >> >> Jonathan Gray wrote: >> >>> Hey guys, >>> >>> Been using ZK indirectly for a few months now in the HBase and Katta >>> realms. Both of these applications make it really easy so you don't >>> have to be involved much with managing your ZK cluster to support it. >>> >>> I'm now using ZK for a bunch of things internally, so now I'm manually >>> configuring, starting, and managing a cluster. >>> >>> What advice is there about whether I should be sharing a single >>> cluster between all my applications, or running separate ones for each >>> use? >>> >>> I've been told that it's strongly recommended to run your ZK nodes >>> separately from the application using them (this is actually what >>> we're telling new users over in HBase, though a majority of >>> installations will likely co-host them with DataNodes and RegionServers). >>> >>> I don't have the resources to maintain a separate 3+ node ZK cluster >>> for each of my applications, so this is not really an option. I'm >>> trying to decide if I should have HBase running/managing it's own ZK >>> cluster that is co-located with some of the regionservers (there will >>> be ample memory, but ZK will not have a dedicated disk), or if I >>> should be pointing it to a dedicated 3 node ZK cluster. >>> >>> I would then also have Katta pointing at this same sha
Hadoop BootCamp in Berlin Aug 27, 28th
Hi All, For the first time in Europe, Scale Unlimited will run a 2 day Hadoop BootCamp in Berlin in August, on Aug 27th and 28th. This 2 day hands-on training is for developers who want to get familiar with Hadoop, and gain the knowledge writing MapReduce applications and discuss related technologies. The BootCamp will train you in Map Reduce Theory, Hadoop Architecture, configuration and API with hands-on labs. Detailed information and registration information is at: http://www.scaleunlimited.com/courses/berlin08 (german) or http://www.scaleunlimited.com/courses/hadoop-boot-camp-berlin-en (english) Greetings. Stefan P.S Apologies for the cross posting. P.P.S. Please spread the word! ~~~ Hadoop training and consulting http://www.scaleunlimited.com
Re: Multiple ZK clusters or a single, shared cluster?
Yup. I would say that the use of ZK by HBase today is very minimal. Very few writes at all, almost exclusively reads and still not that often. Dedicated resources would not make much of a difference. For users who are just testing, developing, or running clusters that are not highly loaded, it is not as important to have dedicated nodes _yet_. The next version of HBase, 0.21, we are planning on widely expanding what we use ZK for. At that time, we will be writing much more often, and reading constantly. Dedicated nodes/disks would be highly recommended at that point. Thanks for the explanation. JG Benjamin Reed wrote: you need a dedicated disk for the logDir, but not the dataDir. the reason is that the write to the log is in the critical path: we cannot commit changes until they have been synced to disk, so we want to make sure that we don't contend for the disk. the snapshots in the dataDir are done in an asynchronous thread, so it can be written to a disk used by other applications (usually the OS disk). the problem with running other processes on the zookeeper server is similar to the disk contention: if zookeeper starts contending with a runaway app for CPU and memory, we can start timing out because of starvation. by using a dedicated disk for logs and a dedicated machine you can get very high deterministic performance. make sense? ben Jonathan Gray wrote: Thanks for the input. Honestly, I'm thinking I need to have separate clusters. The version of ZK is one thing; but also for an application like HBase, we have had periods where we needed to patch ZK before it became part of a release. Keeping track of that on a shared cluster will be tricky, if not impossible. And with a small development team and a very fast dev cycle, I'm a little concerned about a runaway application hosing all the other dependencies on ZK... What are the actual reasons for wanting a separate disk for ZK? Strictly reliability purposes? Should that disk be dedicated to the logDir but not the dataDir, or both? If I don't give it a dedicated disk or node, but it has 1GB of memory and a core, what are the downsides? Are they just about reliability? If I could run 5 or 7 zk nodes, but co-hosted with my HBase cluster, is that really less reliable than 3 separate nodes, as long as the jvm has sufficient resources? Or are there performance or usability concerns as well? Sorry for all the questions, just trying to get the story straight so that we don't spread misinformation to HBase users. Most users start out on very small clusters, so dedicated ZK nodes are not a realistic assumption... How big of a deal is that? JG Benjamin Reed wrote: we designed zk to have high performance so that it can be shared by multiple applications. the main thing is that you use dedicated zk machines (with a dedicated disk for logging). once you have that in place, watch the load on your cluster, as long as you aren't saturating the cluster you should share. as you point out running multiple clusters is a hardware investment, plus you miss out on opportunities to improve reliability. for example, if you have three applications that have a cluster of 3 zk servers each, one failure will result in an outage. if instead of using the 9 servers you have the same three applications use a zk cluster with 7 servers you can tolerate three failures without an outage. the key of course is to make sure that you don't oversubscribe the server. ben Jonathan Gray wrote: Hey guys, Been using ZK indirectly for a few months now in the HBase and Katta realms. Both of these applications make it really easy so you don't have to be involved much with managing your ZK cluster to support it. I'm now using ZK for a bunch of things internally, so now I'm manually configuring, starting, and managing a cluster. What advice is there about whether I should be sharing a single cluster between all my applications, or running separate ones for each use? I've been told that it's strongly recommended to run your ZK nodes separately from the application using them (this is actually what we're telling new users over in HBase, though a majority of installations will likely co-host them with DataNodes and RegionServers). I don't have the resources to maintain a separate 3+ node ZK cluster for each of my applications, so this is not really an option. I'm trying to decide if I should have HBase running/managing it's own ZK cluster that is co-located with some of the regionservers (there will be ample memory, but ZK will not have a dedicated disk), or if I should be pointing it to a dedicated 3 node ZK cluster. I would then also have Katta pointing at this same shared cluster (or a separate cluster would be co-located with katta nodes). Same for my application; could share nodes with the app servers or pointed at a single ZK cluster. Trade-offs I should be aware of? Curre
Re: Multiple ZK clusters or a single, shared cluster?
you need a dedicated disk for the logDir, but not the dataDir. the reason is that the write to the log is in the critical path: we cannot commit changes until they have been synced to disk, so we want to make sure that we don't contend for the disk. the snapshots in the dataDir are done in an asynchronous thread, so it can be written to a disk used by other applications (usually the OS disk). the problem with running other processes on the zookeeper server is similar to the disk contention: if zookeeper starts contending with a runaway app for CPU and memory, we can start timing out because of starvation. by using a dedicated disk for logs and a dedicated machine you can get very high deterministic performance. make sense? ben Jonathan Gray wrote: Thanks for the input. Honestly, I'm thinking I need to have separate clusters. The version of ZK is one thing; but also for an application like HBase, we have had periods where we needed to patch ZK before it became part of a release. Keeping track of that on a shared cluster will be tricky, if not impossible. And with a small development team and a very fast dev cycle, I'm a little concerned about a runaway application hosing all the other dependencies on ZK... What are the actual reasons for wanting a separate disk for ZK? Strictly reliability purposes? Should that disk be dedicated to the logDir but not the dataDir, or both? If I don't give it a dedicated disk or node, but it has 1GB of memory and a core, what are the downsides? Are they just about reliability? If I could run 5 or 7 zk nodes, but co-hosted with my HBase cluster, is that really less reliable than 3 separate nodes, as long as the jvm has sufficient resources? Or are there performance or usability concerns as well? Sorry for all the questions, just trying to get the story straight so that we don't spread misinformation to HBase users. Most users start out on very small clusters, so dedicated ZK nodes are not a realistic assumption... How big of a deal is that? JG Benjamin Reed wrote: we designed zk to have high performance so that it can be shared by multiple applications. the main thing is that you use dedicated zk machines (with a dedicated disk for logging). once you have that in place, watch the load on your cluster, as long as you aren't saturating the cluster you should share. as you point out running multiple clusters is a hardware investment, plus you miss out on opportunities to improve reliability. for example, if you have three applications that have a cluster of 3 zk servers each, one failure will result in an outage. if instead of using the 9 servers you have the same three applications use a zk cluster with 7 servers you can tolerate three failures without an outage. the key of course is to make sure that you don't oversubscribe the server. ben Jonathan Gray wrote: Hey guys, Been using ZK indirectly for a few months now in the HBase and Katta realms. Both of these applications make it really easy so you don't have to be involved much with managing your ZK cluster to support it. I'm now using ZK for a bunch of things internally, so now I'm manually configuring, starting, and managing a cluster. What advice is there about whether I should be sharing a single cluster between all my applications, or running separate ones for each use? I've been told that it's strongly recommended to run your ZK nodes separately from the application using them (this is actually what we're telling new users over in HBase, though a majority of installations will likely co-host them with DataNodes and RegionServers). I don't have the resources to maintain a separate 3+ node ZK cluster for each of my applications, so this is not really an option. I'm trying to decide if I should have HBase running/managing it's own ZK cluster that is co-located with some of the regionservers (there will be ample memory, but ZK will not have a dedicated disk), or if I should be pointing it to a dedicated 3 node ZK cluster. I would then also have Katta pointing at this same shared cluster (or a separate cluster would be co-located with katta nodes). Same for my application; could share nodes with the app servers or pointed at a single ZK cluster. Trade-offs I should be aware of? Current best practices? Any help would be much appreciated. Thanks. Jonathan Gray
Re: Multiple ZK clusters or a single, shared cluster?
Thanks for the input. Honestly, I'm thinking I need to have separate clusters. The version of ZK is one thing; but also for an application like HBase, we have had periods where we needed to patch ZK before it became part of a release. Keeping track of that on a shared cluster will be tricky, if not impossible. And with a small development team and a very fast dev cycle, I'm a little concerned about a runaway application hosing all the other dependencies on ZK... What are the actual reasons for wanting a separate disk for ZK? Strictly reliability purposes? Should that disk be dedicated to the logDir but not the dataDir, or both? If I don't give it a dedicated disk or node, but it has 1GB of memory and a core, what are the downsides? Are they just about reliability? If I could run 5 or 7 zk nodes, but co-hosted with my HBase cluster, is that really less reliable than 3 separate nodes, as long as the jvm has sufficient resources? Or are there performance or usability concerns as well? Sorry for all the questions, just trying to get the story straight so that we don't spread misinformation to HBase users. Most users start out on very small clusters, so dedicated ZK nodes are not a realistic assumption... How big of a deal is that? JG Benjamin Reed wrote: we designed zk to have high performance so that it can be shared by multiple applications. the main thing is that you use dedicated zk machines (with a dedicated disk for logging). once you have that in place, watch the load on your cluster, as long as you aren't saturating the cluster you should share. as you point out running multiple clusters is a hardware investment, plus you miss out on opportunities to improve reliability. for example, if you have three applications that have a cluster of 3 zk servers each, one failure will result in an outage. if instead of using the 9 servers you have the same three applications use a zk cluster with 7 servers you can tolerate three failures without an outage. the key of course is to make sure that you don't oversubscribe the server. ben Jonathan Gray wrote: Hey guys, Been using ZK indirectly for a few months now in the HBase and Katta realms. Both of these applications make it really easy so you don't have to be involved much with managing your ZK cluster to support it. I'm now using ZK for a bunch of things internally, so now I'm manually configuring, starting, and managing a cluster. What advice is there about whether I should be sharing a single cluster between all my applications, or running separate ones for each use? I've been told that it's strongly recommended to run your ZK nodes separately from the application using them (this is actually what we're telling new users over in HBase, though a majority of installations will likely co-host them with DataNodes and RegionServers). I don't have the resources to maintain a separate 3+ node ZK cluster for each of my applications, so this is not really an option. I'm trying to decide if I should have HBase running/managing it's own ZK cluster that is co-located with some of the regionservers (there will be ample memory, but ZK will not have a dedicated disk), or if I should be pointing it to a dedicated 3 node ZK cluster. I would then also have Katta pointing at this same shared cluster (or a separate cluster would be co-located with katta nodes). Same for my application; could share nodes with the app servers or pointed at a single ZK cluster. Trade-offs I should be aware of? Current best practices? Any help would be much appreciated. Thanks. Jonathan Gray
Re: Multiple ZK clusters or a single, shared cluster?
we designed zk to have high performance so that it can be shared by multiple applications. the main thing is that you use dedicated zk machines (with a dedicated disk for logging). once you have that in place, watch the load on your cluster, as long as you aren't saturating the cluster you should share. as you point out running multiple clusters is a hardware investment, plus you miss out on opportunities to improve reliability. for example, if you have three applications that have a cluster of 3 zk servers each, one failure will result in an outage. if instead of using the 9 servers you have the same three applications use a zk cluster with 7 servers you can tolerate three failures without an outage. the key of course is to make sure that you don't oversubscribe the server. ben Jonathan Gray wrote: Hey guys, Been using ZK indirectly for a few months now in the HBase and Katta realms. Both of these applications make it really easy so you don't have to be involved much with managing your ZK cluster to support it. I'm now using ZK for a bunch of things internally, so now I'm manually configuring, starting, and managing a cluster. What advice is there about whether I should be sharing a single cluster between all my applications, or running separate ones for each use? I've been told that it's strongly recommended to run your ZK nodes separately from the application using them (this is actually what we're telling new users over in HBase, though a majority of installations will likely co-host them with DataNodes and RegionServers). I don't have the resources to maintain a separate 3+ node ZK cluster for each of my applications, so this is not really an option. I'm trying to decide if I should have HBase running/managing it's own ZK cluster that is co-located with some of the regionservers (there will be ample memory, but ZK will not have a dedicated disk), or if I should be pointing it to a dedicated 3 node ZK cluster. I would then also have Katta pointing at this same shared cluster (or a separate cluster would be co-located with katta nodes). Same for my application; could share nodes with the app servers or pointed at a single ZK cluster. Trade-offs I should be aware of? Current best practices? Any help would be much appreciated. Thanks. Jonathan Gray
Re: Multiple ZK clusters or a single, shared cluster?
Hi Jonathan, Regarding sharing ZooKeeper servers among applications, we actually recommend doing that. We ask our users to have dedicated 3-5 node clusters with dedicated machines(/disk) for zookeeper and lets applications share those 3-5 nodes clusters. But we do have have users (inside Yahoo!) wherein they want to run these clusters for themselves. The reasons being: - there usage of zookeeper (in terms of reads/writes per second and number of clients - 5K or so) is pretty high and they do not want to share the dedicated cluster with other properties inside Yahoo! - they also want to manage upgrades/administration of cluster on there own There might be more info on administering your own cluster at http://hadoop.apache.org/zookeeper/docs/r3.2.0/zookeeperAdmin.html Thanks mahadev On 7/17/09 12:48 PM, "Jonathan Gray" wrote: > Hey guys, > > Been using ZK indirectly for a few months now in the HBase and Katta > realms. Both of these applications make it really easy so you don't > have to be involved much with managing your ZK cluster to support it. > > I'm now using ZK for a bunch of things internally, so now I'm manually > configuring, starting, and managing a cluster. > > What advice is there about whether I should be sharing a single cluster > between all my applications, or running separate ones for each use? > > I've been told that it's strongly recommended to run your ZK nodes > separately from the application using them (this is actually what we're > telling new users over in HBase, though a majority of installations will > likely co-host them with DataNodes and RegionServers). > > I don't have the resources to maintain a separate 3+ node ZK cluster for > each of my applications, so this is not really an option. I'm trying to > decide if I should have HBase running/managing it's own ZK cluster that > is co-located with some of the regionservers (there will be ample > memory, but ZK will not have a dedicated disk), or if I should be > pointing it to a dedicated 3 node ZK cluster. > > I would then also have Katta pointing at this same shared cluster (or a > separate cluster would be co-located with katta nodes). Same for my > application; could share nodes with the app servers or pointed at a > single ZK cluster. > > Trade-offs I should be aware of? Current best practices? > > Any help would be much appreciated. Thanks. > > Jonathan Gray
Re: Queue code
> Also are there any performance numbers of zookeeeper based queues. How does > it compare with JMS. > > thanks > Kishore G Hi Kishore, We do not have any performance number fr queues on zookeeper. I think you can get a rough idea of those numbers from your usage of zookeeper (number of reads/writes per second) and zookeeper performance numbers on http://hadoop.apache.org/zookeeper/docs/r3.2.0/zookeeperOver.html Hope that helps. Thanks mahadev
Re: Queue code
Thanks for the report, looks like something we need to address, would
you mind going the extra step and adding a JIRA on this?
https://issues.apache.org/jira/browse/ZOOKEEPER
Thanks,
Patrick
kishore g wrote:
Hi All,
Zookeeper recipe queue code has a bug.
byte[] b = zk.getData(root + "/element" + min,
false, stat);
zk.delete(root + "/element" + min, 0);
It throws an error saying the node element0 does not exists.
Node actually created by producer was element00. So along with min
minNodeName must be stored.
Here is the consume method that works.
public int consume() throws KeeperException, InterruptedException{
int retvalue = -1;
Stat stat = null;
// Get the first element available
while (true) {
synchronized (mutex) {
List list = zk.getChildren(root, true);
if (list.size() == 0) {
System.out.println("Going to wait");
mutex.wait();
} else {
Integer min = new Integer(list.get(0).substring(7));
String name = list.get(0);
for(String s : list){
Integer tempValue = new Integer(s.substring(7));
//System.out.println("Temporary value: " + s);
if(tempValue < min) {
min = tempValue;
name = s;
}
}
String zNode = root + "/" + name;
System.out.println("Temporary value: " + zNode);
byte[] b = zk.getData(zNode,false, stat);
zk.delete(zNode, 0);
ByteBuffer buffer = ByteBuffer.wrap(b);
retvalue = buffer.getInt();
return retvalue;
}
}
}
}
Also are there any performance numbers of zookeeeper based queues. How does
it compare with JMS.
thanks
Kishore G
Multiple ZK clusters or a single, shared cluster?
Hey guys, Been using ZK indirectly for a few months now in the HBase and Katta realms. Both of these applications make it really easy so you don't have to be involved much with managing your ZK cluster to support it. I'm now using ZK for a bunch of things internally, so now I'm manually configuring, starting, and managing a cluster. What advice is there about whether I should be sharing a single cluster between all my applications, or running separate ones for each use? I've been told that it's strongly recommended to run your ZK nodes separately from the application using them (this is actually what we're telling new users over in HBase, though a majority of installations will likely co-host them with DataNodes and RegionServers). I don't have the resources to maintain a separate 3+ node ZK cluster for each of my applications, so this is not really an option. I'm trying to decide if I should have HBase running/managing it's own ZK cluster that is co-located with some of the regionservers (there will be ample memory, but ZK will not have a dedicated disk), or if I should be pointing it to a dedicated 3 node ZK cluster. I would then also have Katta pointing at this same shared cluster (or a separate cluster would be co-located with katta nodes). Same for my application; could share nodes with the app servers or pointed at a single ZK cluster. Trade-offs I should be aware of? Current best practices? Any help would be much appreciated. Thanks. Jonathan Gray
Queue code
Hi All,
Zookeeper recipe queue code has a bug.
byte[] b = zk.getData(root + "/element" + min,
false, stat);
zk.delete(root + "/element" + min, 0);
It throws an error saying the node element0 does not exists.
Node actually created by producer was element00. So along with min
minNodeName must be stored.
Here is the consume method that works.
public int consume() throws KeeperException, InterruptedException{
int retvalue = -1;
Stat stat = null;
// Get the first element available
while (true) {
synchronized (mutex) {
List list = zk.getChildren(root, true);
if (list.size() == 0) {
System.out.println("Going to wait");
mutex.wait();
} else {
Integer min = new Integer(list.get(0).substring(7));
String name = list.get(0);
for(String s : list){
Integer tempValue = new Integer(s.substring(7));
//System.out.println("Temporary value: " + s);
if(tempValue < min) {
min = tempValue;
name = s;
}
}
String zNode = root + "/" + name;
System.out.println("Temporary value: " + zNode);
byte[] b = zk.getData(zNode,false, stat);
zk.delete(zNode, 0);
ByteBuffer buffer = ByteBuffer.wrap(b);
retvalue = buffer.getInt();
return retvalue;
}
}
}
}
Also are there any performance numbers of zookeeeper based queues. How does
it compare with JMS.
thanks
Kishore G
Re: zkCleanup.sh is buggy
Hi Fernando,
Please do file a jira ( http://issues.apache.org/jira/browse/ZOOKEEPER )
and the patch below as an attachment to the created jira.
Here is how to contribute:
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
thnaks
Mahadev
On 7/17/09 11:59 AM, "Fernando Padilla" wrote:
> Actually.. this is the patch I would suggest:
>
>
> remove everything below and including the "eval", and change to:
>
>
> ZOODATADIR=$(grep '^dataDir=' $ZOOCFG | sed -e 's/.*=//')
> ZOODATALOGDIR=$(grep '^dataLogDir=' $ZOOCFG | sed -e 's/.*=//')
>
> if [ "x${ZOODATALOGDIR}" = "x" ]
> then
> java "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
> "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
> -cp $CLASSPATH $JVMFLAGS \
> org.apache.zookeeper.server.PurgeTxnLog $ZOODATADIR $*
> else
> java "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
> "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
> -cp $CLASSPATH $JVMFLAGS \
> org.apache.zookeeper.server.PurgeTxnLog $ZOODATALOGDIR $ZOODATADIR $*
> fi
>
>
>
>
> Fernando Padilla wrote:
>> I am playing with the zookeeper 3.2.0 build, and it looks like the
>> zkCleanup.sh script is a little buggy. :)
>>
>> It calls:
>>
>> PurgeTxnLog $dataDir
>>
>> but doesn't pass through the count of snapshots.. you could do it simply
>> by adding:
>>
>> PurgeTxnLog $dataDir $*
>>
>>
>> Though I just realized, it only uses $dataDir, and is not smart enough
>> to realize if it's using a different dataLogDir...
>>
>> Should I file a bug?
Re: zkCleanup.sh is buggy
Actually.. this is the patch I would suggest:
remove everything below and including the "eval", and change to:
ZOODATADIR=$(grep '^dataDir=' $ZOOCFG | sed -e 's/.*=//')
ZOODATALOGDIR=$(grep '^dataLogDir=' $ZOOCFG | sed -e 's/.*=//')
if [ "x${ZOODATALOGDIR}" = "x" ]
then
java "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp $CLASSPATH $JVMFLAGS \
org.apache.zookeeper.server.PurgeTxnLog $ZOODATADIR $*
else
java "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp $CLASSPATH $JVMFLAGS \
org.apache.zookeeper.server.PurgeTxnLog $ZOODATALOGDIR $ZOODATADIR $*
fi
Fernando Padilla wrote:
I am playing with the zookeeper 3.2.0 build, and it looks like the
zkCleanup.sh script is a little buggy. :)
It calls:
PurgeTxnLog $dataDir
but doesn't pass through the count of snapshots.. you could do it simply
by adding:
PurgeTxnLog $dataDir $*
Though I just realized, it only uses $dataDir, and is not smart enough
to realize if it's using a different dataLogDir...
Should I file a bug?
zkCleanup.sh is buggy
I am playing with the zookeeper 3.2.0 build, and it looks like the zkCleanup.sh script is a little buggy. :) It calls: PurgeTxnLog $dataDir but doesn't pass through the count of snapshots.. you could do it simply by adding: PurgeTxnLog $dataDir $* Though I just realized, it only uses $dataDir, and is not smart enough to realize if it's using a different dataLogDir... Should I file a bug?
