anchor.diff:  Out of the box, HBase runs in standalone mode.
   Whatever your mode, you will need to configure HBase by editing files in the HBase _conf_ directory.
   At a minimum, you must edit [code]+conf/hbase-env.sh+ to tell HBase which +java+ to use.
  -In this file you set HBase environment variables such as the heapsize and other options for the `JVM`, the preferred location for log files, etc.
  -Set [var]+JAVA_HOME+ to point at the root of your +java+ install.
  +In this file you set HBase environment variables such as the heapsize and other options for the
  +`JVM`, the preferred location for log files, etc. Set [var]+JAVA_HOME+ to point at the root of
  +your +java+ install.
   
   [[standalone]]
   === Standalone HBase
   
   This is the default mode.
   Standalone mode is what is described in the <<quickstart,quickstart>> section.
  -In standalone mode, HBase does not use HDFS -- it uses the local filesystem instead -- and it runs all HBase daemons and a local ZooKeeper all up in the same JVM.
  -ZooKeeper binds to a well known port so clients may talk to HBase.
  +In standalone mode, HBase does not use HDFS -- it uses the local filesystem instead -- and it runs
  +all HBase daemons and a local ZooKeeper all up in the same JVM. ZooKeeper binds to a well-known
  +port so clients may talk to HBase.
   
   [[standalone.over.hdfs]]
   ==== Standalone HBase over HDFS
  
positive.code: * hbase.client.scanner.timeout.period
  
  The `hbase.rpc.timeout` property limits how long a single RPC call can run before timing out.
  To fine tune read or write related RPC timeouts set `hbase.rpc.read.timeout` and `hbase.rpc.write.timeout` configuration properties.
  In the absence of these properties `hbase.rpc.timeout` will be used.
  
  A higher-level timeout is `hbase.client.operation.timeout` which is valid for each client call.
  When an RPC call fails for instance for a timeout due to `hbase.rpc.timeout` it will be retried until `hbase.client.operation.timeout` is reached.
  Client operation timeout for system tables can be fine tuned by setting `hbase.client.meta.operation.timeout` configuration value.
  When this is not set its value will use `hbase.client.operation.timeout`.
  
  Timeout for scan operations is controlled differently. Use `hbase.client.scanner.timeout.period` property to set this timeout.
  
  [[example_config]]
  == Example Configurations
  
negative.code: [[sect.zookeeper.session.timeout]]
  ===== `zookeeper.session.timeout`
  
  The default timeout is 90 seconds (specified in milliseconds). This means that if a server crashes,
  it will be 90 seconds before the Master notices the crash and starts recovery. You might need to
  tune the timeout down to a minute or even less so the Master notices failures sooner. Before
  changing this value, be sure you have your JVM garbage collection configuration under control,
  otherwise, a long garbage collection that lasts beyond the ZooKeeper session timeout will take out
  your RegionServer. (You might be fine with this -- you probably want recovery to start on the
  server if a RegionServer has been in GC for a long period of time).
  
  To change this configuration, edit _hbase-site.xml_, copy the changed file across the cluster and
  restart.
  
  We set this value high to save our having to field questions up on the mailing lists asking why a
  RegionServer went down during a massive import. The usual cause is that their JVM is untuned and
  they are running into long GC pauses. Our thinking is that while users are getting familiar with
  HBase, we'd save them having to know all of its intricacies. Later when they've built some
  confidence, then they can play with configuration such as this.
  
  [[zookeeper.instances]]
  ===== Number of ZooKeeper Instances
  