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-3634) Fix JavaDoc for put(List<Put> puts) in HTableInterface
Date Fri, 18 Mar 2011 09:53:29 GMT

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

Lars George commented on HBASE-3634:

Hmm, the get(List<Get> gets) seems equally outdated:

   * Extracts certain cells from the given rows, in batch.
   * @param gets The objects that specify what data to fetch and from which rows.
   * @return The data coming from the specified rows, if it exists.  If the row
   *         specified doesn't exist, the {@link Result} instance returned won't
   *         contain any {@link KeyValue}, as indicated by {@link Result#isEmpty()}.
   *         A null in the return array means that the get operation for that
   *         Get failed, even after retries.
   * @throws IOException if a remote or network exception occurs.
   * @since 0.90.0
  Result[] get(List<Get> gets) throws IOException;

The description of the return values is wrong it seems, I tested it with a bogus colfam and
the processBatchCallback() is doing this:

      if (!exceptions.isEmpty()) {
        throw new RetriesExhaustedWithDetailsException(exceptions,

This trows an exception that is bubbled up the chain and skips the entire copying of the results
in the get() call:

     Object [] r1 = batch((List)gets);

       // translate.
       Result [] results = new Result[r1.length];
       int i=0;
       for (Object o : r1) {
         // batch ensures if there is a failure we get an exception instead
         results[i++] = (Result) o;

The batch() is throwing the exception and the subsequent code is not triggered. 

Apart from put(List)/delete(List) and get(List) being inconsistent to report the errors back,
we should decide what is wanted from the API. If the described behavior is what is intended
then the newer batch() backed approach has broken it. 

The batch itself does what is advertised, so the thing to fix would be the get(List) call
to catch the exception and copy the results over. I am going to open a new issue for that,
this seems broke.

> Fix JavaDoc for put(List<Put> puts) in HTableInterface
> ------------------------------------------------------
>                 Key: HBASE-3634
>                 URL: https://issues.apache.org/jira/browse/HBASE-3634
>             Project: HBase
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 0.90.1
>            Reporter: Lars George
>            Priority: Trivial
>             Fix For: 0.92.0
> We say this in the interface:
> {code}
>   /**
>    * Puts some data in the table, in batch.
>    * <p>
>    * If {@link #isAutoFlush isAutoFlush} is false, the update is buffered
>    * until the internal buffer is full.
>    * @param puts The list of mutations to apply.  The list gets modified by this
>    * method (in particular it gets re-ordered, so the order in which the elements
>    * are inserted in the list gives no guarantee as to the order in which the
>    * {@link Put}s are executed).
>    * @throws IOException if a remote or network exception occurs. In that case
>    * the {@code puts} argument will contain the {@link Put} instances that
>    * have not be successfully applied.
>    * @since 0.20.0
>    */
>   void put(List<Put> puts) throws IOException;
> {code}
> This is outdated and needs to be updated to reflect that this is nothing else but a client
side iteration over all puts, but using the write buffer to aggregate to one RPC. The list
is never modified and after the call contains the same number of elements.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message