I agree here but will go farther. Hbase needs an asynchronous api that goes further than its current capability, for example like building lamda functions in the client tier that execute in a java streams manner. Being able to run mapping functions, aggregations, etc without needing coprocessors would be a big win. If Hbase doesn’t do it, the next thing will.

On Oct 5, 2017, at 11:31 AM, James Taylor <jamestaylor@apache.org> wrote:

I do think it would be good for Phoenix to have a netty-based async means of interacting with the server. We've found that to really drive down latency for a parallelized query over a big cluster, you have to have a ridiculously large thread pool on the client side (4000 threads for cluster with 100s of nodes). A netty-based means of interacting would allow us to drive down the latency without resorting to this (though this is pure conjecture at this point - we might run into other, unknown scaling constraints through an async API). Asynchbase, however, has a lot of restrictions in terms of how you can interact with the server. If it could become part of HBase and support the full wire protocol, then it might be an option.


On Thu, Oct 5, 2017 at 7:00 AM, Flavio Pompermaier <pompermaier@okkam.it> wrote:
Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, what do you think?

On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew <kliew@apache.org> wrote:
Wrapping a thread-blocking call in a Future makes it asynchronous, but does not turn it into a non-blocking call.

On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell <stan.campbell3@gmail.com> wrote:

Wrap the call in a Future.  You're home.

On Wed, Oct 4, 2017, 9:36 AM James Taylor <jamestaylor@apache.org> wrote:
Hi Flavio,
Phoenix supports JDBC. The implementation may do gets, scans, etc., but it's completely transparent to the user.

On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier <pompermaier@okkam.it> wrote:
Hi to all,
does Phoenix support async get? I can't find anything about this..