I agree that we should be more consistent in how we get zk config (Your original report looks like a bug Lars). I also recently tripped over the fact that hbase uses different names for one or two zk configs. We need to fix that too. St.Ack
On Mon, Jul 4, 2011 at 8:59 AM, Jesse Yates <[email protected]> wrote: > Isn't that kind of the point though? If you drop in a zk config file on a > machine, you should be able to update all your apps on that machine to the > new config. > Whats more important though is being able to easily distribute a changed zk > config across your cluster and simultaneously across multiple applications. > Rather than rewriting the confs for a handful of applications, and possibly > making a mistake dealing with each application's own special semantics, and > single conf to update everything just makes sense. > > I would lobby then that we make usage more consistent (as Lars recommends) > and make some of the hbase conf values to more closely match the zk conf > values (though hbase.${zk.value} is really not bad). > > -Jesse > > > From: Ryan Rawson [[email protected]] >> Sent: Monday, July 04, 2011 5:25 AM >> To: [email protected] >> Subject: Re: zoo.cfg vs hbase-site.xml >> >> Should just fully deprecate zoo.cfg, it ended up being more trouble >> than it was worth. When you use zoo.cfg you cannot connect to more >> than 1 cluster from a single JVM. Annoying! >> >> On Sun, Jul 3, 2011 at 10:22 AM, Ted Yu <[email protected]> wrote: >> > I looked at conf/zoo_sample.cfg from zookeeper trunk. The naming of >> > properties is different from the way we name >> > "hbase.zookeeper.property.maxClientCnxns" >> > >> > e.g. >> > # the port at which the clients will connect >> > clientPort=2181 >> > >> > FYI >> > >> > On Sun, Jul 3, 2011 at 9:53 AM, Lars George <[email protected]> >> wrote: >> > >> >> Hi, >> >> >> >> Usually the zoo.cfg overrides *all* settings off the hbase-site.xml >> >> (including the ones from hbase-default.xml) - when present. But in some >> >> places we do not consider this, for example in HConnectionManager: >> >> >> >> static { >> >> // We set instances to one more than the value specified for {@link >> >> // HConstants#ZOOKEEPER_MAX_CLIENT_CNXNS}. By default, the zk default >> >> max >> >> // connections to the ensemble from the one client is 30, so in that >> >> case we >> >> // should run into zk issues before the LRU hit this value of 31. >> >> MAX_CACHED_HBASE_INSTANCES = HBaseConfiguration.create().getInt( >> >> HConstants.ZOOKEEPER_MAX_CLIENT_CNXNS, >> >> HConstants.DEFAULT_ZOOKEPER_MAX_CLIENT_CNXNS) + 1; >> >> HBASE_INSTANCES = new LinkedHashMap<HConnectionKey, >> >> HConnectionImplementation>( >> >> (int) (MAX_CACHED_HBASE_INSTANCES / 0.75F) + 1, 0.75F, true) { >> >> @Override >> >> protected boolean removeEldestEntry( >> >> Map.Entry<HConnectionKey, HConnectionImplementation> eldest) { >> >> return size() > MAX_CACHED_HBASE_INSTANCES; >> >> } >> >> }; >> >> >> >> >> >> This only reads it from hbase-site.xml+hbase-default.xml. This is >> >> inconsistent, I think this should use ZKConfig.makeZKProps(conf) and >> then >> >> get the value. >> >> >> >> Thoughts? >> >> >> >> Lars >> >> >> > >> >
