Re: Async Table API

[Jurriaan Mous]

  With a new interface we enable ourselves to rethink a bit of the API to be
  simpler.
 
  I am currently proposing the following methods in the simpler AsyncTable
  interface:
  exists(Get): ResponsePromiseBoolean
  exists(ListGet): ResponsePromiseBoolean[]
  get(Get): ResponsePromiseResult
  get(ListGet): ResponsePromiseResult[]
  mutate(Mutation): ResponsePromiseVoid - Instead of separate Put, Delete,
  Increment, IncrementValue and Append methods
  checkAndMutate(byte[], byte[], byte[], CompareOp, byte[], Mutation):
  ResponsePromiseVoid - Will not accept Append and Increment
 
 
 Over in issue, you are thinking 'not accept Append and Increment' because
 they are one-at-a-time-nonce-dependent... Is the above call one-at-a-time?
Indeed. I did this because it seems the current API was designed this way to 
not allow multiple nonce calls at once.
  checkAndMutate(byte[], byte[], byte[], CompareOp, byte[], RowMutations):
  ResponsePromiseVoid - Will not accept Append and Increment
 
 
 The thinking on the above method is that if doing bulk checkAndMutate, that
 they should all be inside a single row?
That is correct. Although you can send out multiple requests to different rows 
at once with the Async api.
 PromiseKeeper is a loaded term! See https://promisekeepers.org/#what ...
 (smile)
Ah I did not know since we don’t have those here. So it is better to rename? 
Any nice suggestions?
  There will be a new AsyncResultScanner which handles incoming batches of
  result. It will not be possible to do next on it since this does not makes
  sense in an async context. There will be however a way to request a new
  batch with a promise.
 
 
 I like this no next. What you thinking as means of specifying
 'batches'? We've been trying to move away from specifying batches in terms
 of row count to instead do batches of a particular size (See HBASE-13441).
As I currently implemented them you can request nextBatch promises until 
isClosed() is true. So if batches are based on size in the future it is easy to 
change the internals.

Re: Async Table API

[Stack]

On Fri, May 29, 2015 at 3:34 AM, Jurriaan Mous jurm...@jurmo.us wrote:

 Dear HBase Developers,

 I am currently working on issue HBASE-13784 
 https://issues.apache.org/jira/browse/HBASE-13784 to provide an Async
 Table api which builds on my previous work in HBASE-12684 
 https://issues.apache.org/jira/browse/HBASE-12684
  which added a new AsyncRpcClient.

 For this I am proposing a new AsyncTable interface and implementation.
 This way the method signatures will not conflict with Table methods and
 AsyncTable can be more lightweight since it does not need Executors and
 more.


That'll be sweet if more lightweight than Table implementation.



 Also some existing Table implementations like RemoteHTable are difficult
 to turn async so a new interface is easier.



New (Async)Table Interface with asyncy ops  sounds right to me.

Looking at list of methods, it doesn't look like an implementation will be
able to implement Table and AsyncTable ... but that is fine I'd say
(different chassis involved).


 With a new interface we enable ourselves to rethink a bit of the API to be
 simpler.

 I am currently proposing the following methods in the simpler AsyncTable
 interface:
 exists(Get): ResponsePromiseBoolean
 exists(ListGet): ResponsePromiseBoolean[]
 get(Get): ResponsePromiseResult
 get(ListGet): ResponsePromiseResult[]
 mutate(Mutation): ResponsePromiseVoid - Instead of separate Put, Delete,
 Increment, IncrementValue and Append methods
 checkAndMutate(byte[], byte[], byte[], CompareOp, byte[], Mutation):
 ResponsePromiseVoid - Will not accept Append and Increment


Over in issue, you are thinking 'not accept Append and Increment' because
they are one-at-a-time-nonce-dependent... Is the above call one-at-a-time?


 checkAndMutate(byte[], byte[], byte[], CompareOp, byte[], RowMutations):
 ResponsePromiseVoid - Will not accept Append and Increment


The thinking on the above method is that if doing bulk checkAndMutate, that
they should all be inside a single row?




 getScanner(Scan): ResponsePromiseVoid - AsyncResultScanner
 coprocessorService(byte[]): AsyncCoprocessorRpcService
 coprocessorService(ClassT extends Service, byte[] startkey, byte[]
 endkey, Batch.CallT,R callable): ResponsePromiseMapbyte[], R
 batchCoprocessorService(Descriptors.MethodDescriptor, Message, byte[]
 startKey, byte[] endKey, R responsePrototype): ResponsePromiseMapbyte[],
 R

 To send multiple mutations you need to use a BufferedMutator which handles
 writeBuffers internally. I will look into making it possible to use it with
 Promises.


Nice.


 Batch operations will be able to be done by a PromiseKeeper which is a
 promise to which other promises can be added.


PromiseKeeper is a loaded term! See https://promisekeepers.org/#what ...
(smile)


 There will be a new AsyncResultScanner which handles incoming batches of
 result. It will not be possible to do next on it since this does not makes
 sense in an async context. There will be however a way to request a new
 batch with a promise.


I like this no next. What you thinking as means of specifying
'batches'? We've been trying to move away from specifying batches in terms
of row count to instead do batches of a particular size (See HBASE-13441).


 If you have any insights/comments/suggestions/questions please add them to
 the issue. There is also already a first working patch with get and exists
 methods.

 https://issues.apache.org/jira/browse/HBASE-13784 
 https://issues.apache.org/jira/browse/HBASE-13784


Nice work Jurriaan,
St.Ack



 Thanks!
 Jurriaan