Fix hard-coded family names.
Add support for scanning with multiple qualifiers.

This closes #35.
Based on an original patch from Nicolas Thiébaud.
Use Junit to run the individual regression tests.
Allow specifying a single integration test to run.

If the environment variable TEST_NAME is set, then only that
test will be run.  The value is expected to be the name of the
method of the test to run.
Add a basic scan integration test.
Disallow changing time ranges once scanner started.

This check should have been there in the first place.
Do not attempt to deserialize 0-length byte arrays to avoid a Netty bug.

Add a regression test for this bug and upgrade Netty to 3.5.9.
Thanks to Andrey Stepachev for providing the workaround code.
This closes #40.
Minor NEWS updates.
Add a regression test for issue #41.
Add a stress test for buffered counter increments.
Allows specifying the number of versions to return in get/scan.

This closes #26.
Clarify the current semantics of flush().

No code change, just javadoc.
Minor style fix.

No code change.
Avoid re-creating new FlushBufferedIncrementsTimer objects.
Update to suasync 1.3.0.
Update number of increments/thread to avoid issue #41.

This is needed after the update to suasync 1.3.0, which now correctly
enforces the limit on the number of callbacks that can be chained.
Catch possible exception when timers fire while we're shutting down.

This is just to log a better warning message than the one provided by
default by Netty.  It doesn't actually change anything otherwise.
Factor out some code to access RPCs pending / in flight.
Have flush() take into account buffered increments in its return value.

Calling client.flush().join() would correctly flush all buffered atomic
increments, but would return too early, potentially before all the RPCs
doing increments have completed. This was due to the fact that when the
increment buffer gets flushed,  the RPCs sent out weren't tied together
to the Deferred returned.

Getting access to the Deferreds of the atomic increments sent out as the
result of a flush() is hard, because these Deferreds are created from a
callback invoked by Guava upon clearing the increment_buffer.  Instead,
to workaround this problem, call sync() on the RegionClients, a method
introduced to provide a semantic similar to Linux's sync(2) system call.

This closes #38.
Flush buffered increments only from one thread at a time.

Concurrent flushes introduce subtle issues, such as in the
following scenario:
  1. Main thread calls client.flush().
  2. Client calls increment_buffer.invalidateAll().
  3. Guava executes clear() on the first segment of the cache.
  4. Guava locks first segment, removes all entries.
  5. The timer thread makes its periodic call to flush().
  6. Steps 2-3 happen in the timer thread, followed by:
  7. Guava attempts to lock the first segment, gets blocked.
  8. Main thread releases the lock on the first segment.
  9. Main thread processes eviction callbacks for entries removed from
     first segment.
 10. Timer thread grabs lock on first segment, finds it empty.
 11. Main thread is still busy with eviction callbacks.
 12. Timer thread locks second segment, starts clearing it.
 13. Main thread will never see the buffered increments cleared by the
     timer thread, and the Deferred returned from client.flush() may
     not include the increments handled by the timer thread if the
     timer thread doesn't put them fast enough in the rpcs_inflight
     map, which easily happened during stress testing.

By locking around the call to increment_buffer.invalidateAll(), in the
scenario above, the main thread will either see all entries in the map
or none, depending on which thread manages to execute its flush() first.
This is better because this way the second call to flush() is guaranteed
to find the flushed RPCs in rpcs_inflight.