hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars George (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13271) Table#puts(List<Put>) operation is indeterminate; remove!
Date Thu, 19 Mar 2015 11:02:38 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368862#comment-14368862

Lars George commented on HBASE-13271:

Good discussion already, let me chime in: yes, this is about the autoflush==true case. And
yes, this is _only_ using the new API. In that case, you have either a BufferedMutator or
a Table. The latter has put(List<Put>) but what it does in case of an error is hard
to handle since we mix local and remote errors. The remote errors can be dealt with when catching
the exception. But inserting mutations into the local write buffer and triggering a local
error (put is empty, or some such) will cause the above scenario.

I also like to have a put(List) option, it is handy. So what could be done. Catching the exception
and doing the flush() in the final does not help much, as it leaves the other Puts uncommitted.
Example: you have 5 puts an the third is empty. You call put(list) and the third triggers
the local exception. If we change to code to have a "finally" clause you commit #1 and #2.
But _not_ #5. The client has to catch the exception, then somehow figure out which mutation
was faulty and where to continue. That is mayhem!

I suggest the following rather, for put(List) disable local checks! What that means is we
send it all mutations to the server and get a list back of those that have failed, while the
others all went through. This is assuming that the majority of API users will have some sense
to created proper put instances.

And that is what batch() apparently does, ie. no local checks. But the only version that is
approved is {{batch(final List<? extends Row> actions, final Object[] results)}} which
needs to be translated into what put(List) is supposed to do. How would we return the list
of results or errors for that call?

BTW, this also applies to BufferedMutation.mutate(List<Mutation>). You still need to
figure out what went wrong client side, which will lead to cumbersome, reinvented boilerplate
code at many API users trying to handle lists of mutations sensibly.

As for 

bq. Wondering if BufferedMutaror should have a method to retrive the number of mutations in
buffer (writeAsyncBuffer.size() in current impl)?

I like the idea of having ways to figure out the status of the local buffer. Right now it
is very tightly guarded.

> Table#puts(List<Put>) operation is indeterminate; remove!
> ---------------------------------------------------------
>                 Key: HBASE-13271
>                 URL: https://issues.apache.org/jira/browse/HBASE-13271
>             Project: HBase
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 1.0.0
>            Reporter: stack
> Another API issue found by [~larsgeorge]:
> "Table.put(List<Put) is questionable after the API change."
> {code}
> [Mar-17 9:21 AM] Lars George: Table.put(List<Put>) is weird since you cannot flush
partial lists
> [Mar-17 9:21 AM] Lars George: Say out of 5 the third is broken, then the put() call returns
with a local exception (say empty Put) and then you have 2 that are in the buffer
> [Mar-17 9:21 AM] Lars George: but how to you force commit them?
> [Mar-17 9:22 AM] Lars George: In the past you would call flushCache(), but that is "gone"
> [Mar-17 9:22 AM] Lars George: and flush() is not available on a Table
> [Mar-17 9:22 AM] Lars George: And you cannot access the underlying BufferedMutation neither
> [Mar-17 9:23 AM] Lars George: You can *only* add more Puts if you can, or call close()
> [Mar-17 9:23 AM] Lars George: that is just weird to explain
> {code}
> So, Table needs to get flush back or we deprecate this method or it flushes immediately
and does not return until complete in the implementation.

This message was sent by Atlassian JIRA

View raw message