[
https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe updated HBASE-13271:
---------------------------------
Attachment: hbase-13271.master.001.patch
Thanks for the good discussion and feedback here. Over time lot of the changes
suggested here are already included in the code. A few things are out dated
because of code changes related to batch, async client etc. After going through
the code and discussion here, I would like to summarize the current behavior
for following methods:
{code}
Result[] get(List<Get> gets) throws IOException;
void put(List<Put> puts) throws IOException;
void delete(List<Delete> deletes) throws IOException;
{code}
* all these methods take list of operations and use batch() which in turn uses
async client to send operations to region servers. No client side buffering
done so no need to flush()
Puts:
* on client side validation errors, runtime exception: IllegalArgumentException
is thrown. Verified with 1.1 in the attached test (001).
* on server side validation errors, RetriesExhaustedWithDetailsException is
thrown which contains list of failed actions/ operations and corresponding
exceptions. Verified with 1.2 in the attached test (001).
* input list is never modified.
Gets:
* no client side validations.
* on server side validation errors, RetriesExhaustedWithDetailsException is
thrown which contains list of failed actions/ operations and corresponding
exceptions. Verified with 2.2 in the attached test.
* if input list contains operations for combination of existing and no-existing
rows then results contain NONE/ NULL for non-existing rows. No exception is
thrown. Verified with 2.1 in the attached test.
* input list is never modified.
Deletes:
* no client side validation.
* on server side validation errors, RetriesExhaustedWithDetailsException is
thrown which contains list of failed actions/ operations and corresponding
exceptions. Verified with 3.1 in the attached test.
* no exception is thrown if input list contains operations for combination of
existing and no-existing rows. Verified with 3.2 in the attached test.
* successful operations are *_always_* removed from the input list
Though there is no consistency, as listed above, the current behavior of each
method tries to suit the unique use case for individual operations.
Javadoc of these methods along with the attached test can be updated. Let me
know your thoughts.
> 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
> Assignee: Umesh Agashe
> Priority: Critical
> Fix For: 2.0.0-alpha-3
>
> Attachments: hbase-13271.master.001.patch
>
>
> 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)
