hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject Re: zoo.cfg vs hbase-site.xml
Date Mon, 04 Jul 2011 15:59:49 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message