Maven SDL compatibility & plugin updates.

maven-sources-plugin simply jars the sourceDirectory to create the
-sources artifact. We don't have empty dirs for the package path and
there's no way to configure maven-sources-plugin to prepend path.
Create a .mvn-compat directory at top level and symlink it
src/main/java/<pkg-path> to top level src/ directory.

Update's `pom.xml.in' with the new `sourceDirectory' and while there
add the missing version decleration to maven-sources-plugin and update
maven-jar-plugin.

Change-Id: Iea9882a52dee293be2d916c45c65b5bc878e16c3
Signed-off-by: Benoit Sigoure <tsuna@stumbleupon.com>
Use `:=' more.

Change-Id: Ieee1493dff56d3524821c8d8eadd3fe2a7825da0
Have distclean remove Maven's target directory.

Change-Id: Id12de927474bca71d09fe6b9345b6c6b6788e705
Make PleaseThrottleException easier to handle.

Add a `getDeferred' method so that throttling can easily be achieved by
join()ing that Deferred, or stopping further writes until it completes.

Change-Id: Ie399a27164ca4a3ca2695ac7d07c570a161b910a
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
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 ARGS='mytable myfamily'

Sample expected output:
  TestIncrementCoalescing: Deleting existing rows...
  TestIncrementCoalescing: Done deleting existing rows.
  TestIncrementCoalescing: 16000000 increments in 2298ms = 6962576/s
  TestIncrementCoalescing: Increments coalesced: 15996204
  TestIncrementCoalescing: Increments evicted from cache: 1061
  TestIncrementCoalescing: Reading all counters back from HBase and checking values...
  TestIncrementCoalescing: Done checking counter values.

Change-Id: I8a3b015d5fb767c140513ee24d00493ef94da3ae
Merge branch 'master' of git://github.com/tsuna/asynchbase