[
https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140848#comment-16140848
]
stack commented on HBASE-13271:
-------------------------------
I don't think we can close this yet. On review of the discussion, current state
is as follows:
put(List<Put>) now does the following since HBASE-18500
# Run local checks on the entire List. Throws exception if any Put is bad in
List; i.e. no longer do we "... mix local and remote errors." [Lars].
# Then submits all using batch; i.e. no longer do we use BM as was recommended
above by a few contributors.
Good. I think this makes it so we do not suffer the original complaint; i.e.
getting into a state where we have two edits in the local client buffer but no
means of flushing them after an error.
To do though is this item raised by Lars: "How would we return the list of
results [from the internal batch call] or errors for that call?" i.e. if an
exception on the remote server because of item #3 in the list, how does the
client figure #3 was bad? [~larsgeorge] notes that BM#mutate(List) has same
issue (In BM, you can register for exceptions which is better. It doesn't tell
you which of the batch was bad though). Lars goes on to talk up delete(List)
implementation. put(List) now mostly does what delete does; it is better in
that it does local checks up front which could be added to delete(List). But it
also has this on the end in a finally:
{code}
} finally {
// mutate list so that it is empty for complete success, or contains only
failed records
// results are returned in the same order as the requests in list walk
the list backwards,
// so we can remove from list without impacting the indexes of earlier
members
for (int i = results.length - 1; i>=0; i--) {
// if result is not null, it succeeded
if (results[i] instanceof Result) {
deletes.remove(i);
}
}
}
{code}
It signals what was good/bad by editing the passed in List returning an empty
list if all deletes 'worked'...
# We should do same for put(List), get(List), etc. Given we want to preserve
API, means deprecation in favor of new API. TODO.
# Also in discussion above, what to do when BM has an exception; how to
recover. Could punt this to a new issue.
> Table#puts(List<Put>) operation is indeterminate; needs fixing
> --------------------------------------------------------------
>
> 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
> Priority: Critical
> Fix For: 2.0.0-alpha-3
>
>
> 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" now
> [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
(v6.4.14#64029)
