[jira] [Updated] (HBASE-13271) Table#puts(List) operation is indeterminate; needs fixing

["Umesh Agashe (JIRA)" <ji...@apache.org>]

     [ 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)