Add jsr166e LongAdder.

Because this code isn't available until JDK8 (which is ways out)
and because it's not currently available elsewhere (having it in
Google Guava would be nice), put a copy here for the time being.

Change-Id: I951ca4deb8905c2d9962ae5de7363ea41b4f8ce6
Add a class to use LongAdder from JSR 166e.

Change-Id: I2fb9fbd99644ce94e9c24296766f2ed1e9fbf076
Switch code to JSR 166e atomic counter.

Change-Id: Ic9df25affc4ddf39644519e84e030f8d5f256980
Upgrade to Netty 3.3.1.

Change-Id: I7b477eafa76f3a183075403fcf334b87bc09553f
Update NEWS and set version to 1.3.0-SNAPSHOT.

Change-Id: I59f9ccc1ea743e2b690c5689e94d5d7c4035892d
Add a dependency on Google's Guava library.

Google Guava's code quality far exceeds the requirements to be
used as a dependency in asynchbase.  The first use of Guava will
be their concurrent in-memory cache to implement increment coalescing.

Change-Id: I661cc6a31c4c7ce336356ffa74289ad37e6551f6
Update to suasync 1.2.0.

Change-Id: Ie9a33c12399a1d007d99b1b95ac3324546acaae7
Atomic increment coalescing.

Add a new method, `bufferAtomicIncrement', to allow client-side
coalescing of atomic increments.  This closes #20.

In high-throughput user-facing applications that do a lot of counter
increments with a reasonable working set, this can significantly reduce
the number of RPCs and write load on HBase.  For example, at StumbleUpon
we have user-facing application servers that increment various counters
in HBase to keep track of user activity and URL activity, and increment
coalescing is able to reduce 30000 increments/s down to 2000 RPC/s,
a 15x reduction in write load.

Change-Id: I76e427430258d4281c2d4342ff3469d39a8f71a0
Add an integration test for increment coalescing.

Run it with:
  $ make run CLASS=TestIncrementCoalescing JVM_ARGS='-Xmx2g -Xms2g' \
      ARGS='mytable myfamily'

Sample expected output:
  TestIncrementCoalescing: Deleting existing rows...
  TestIncrementCoalescing: Done deleting existing rows.
  TestIncrementCoalescing: 16000000 increments in 6045ms = 2646815/s
  TestIncrementCoalescing: Increments coalesced: 16009268
  TestIncrementCoalescing: Increments sent to HBase: 9239
  TestIncrementCoalescing:   due to cache evictions: 0
  TestIncrementCoalescing: Reading all counters back from HBase and checking values...
  TestIncrementCoalescing: Done checking counter values.

Change-Id: I8a3b015d5fb767c140513ee24d00493ef94da3ae
Keep track of usage statistics.

Add counters to keep track of various types of activities (RPCs sent,
connections created, etc.) and provide an API to get a snapshot of the
stats.  All counters are using the JSR 166e sharded counter in order
to minimize the overhead of stats collection.

In practice all application servers that use asynchbase need to collect
these stats anyway to expose them to the monitoring system, so we may
as well have the stats built into the client.  At the moment there is
no mechanism to disable stats collection.

Change-Id: I3913b67de69cf32cab01f8aecee392d743f33e62
Clean up any stale temporary file if we already have the right file.

Change-Id: I388d7f8c64f4f8316334a920e78330e311a40315
Add a CAS (Compare And Set) API.

Based on a patch by Guo Sijie.  This closes #22.

Change-Id: I2ce17ccba974292ad69ffc4a99060b8f08252953
Allow passing a time range to a scanner.

Based on a patch by Michael Rose.  This closes #24.

Change-Id: I39e2947ecb0d6003db1248b5997f0024a09979b3
Merge from tsuna fork