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 >> >
