hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: zoo.cfg vs hbase-site.xml
Date Wed, 06 Jul 2011 21:14:09 GMT
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 <jesse.k.yates@gmail.com> 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 [ryanobjc@gmail.com]
>> Sent: Monday, July 04, 2011 5:25 AM
>> To: dev@hbase.apache.org
>> 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 <yuzhihong@gmail.com> 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 <lars.george@gmail.com>
>> 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
>> >>
>> >
>>
>

Mime
View raw message