You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Lars George (JIRA)" <ji...@apache.org> on 2011/03/14 14:38:29 UTC

[jira] Created: (HBASE-3634) Fix JavaDoc for put(List puts) in HTabkeInterface

Fix JavaDoc for put(List<Put> puts) in HTabkeInterface
------------------------------------------------------

                 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

[jira] [Resolved] (HBASE-3634) Fix JavaDoc for put(List puts) in HTableInterface

Posted by "stack (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack resolved HBASE-3634.
--------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 0.92.0)
                   0.90.3
         Assignee: Harsh J Chouraria
     Hadoop Flags: [Reviewed]

Applied branch and trunk.  Thank you for the patch Harsh.

> 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
>            Assignee: Harsh J Chouraria
>            Priority: Trivial
>             Fix For: 0.90.3
>
>         Attachments: HBASE-3634.r1.diff
>
>
> 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

[jira] Updated: (HBASE-3634) Fix JavaDoc for put(List puts) in HTableInterface

Posted by "Lars George (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars George updated HBASE-3634:
-------------------------------

    Summary: Fix JavaDoc for put(List<Put> puts) in HTableInterface  (was: Fix JavaDoc for put(List<Put> puts) in HTabkeInterface)

> 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

[jira] Commented: (HBASE-3634) Fix JavaDoc for put(List puts) in HTabkeInterface

Posted by "Lars George (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006410#comment-13006410 ] 

Lars George commented on HBASE-3634:
------------------------------------

Alternatively we can call processBatchOfPuts() etc. instead that modify the list as advertised.

> Fix JavaDoc for put(List<Put> puts) in HTabkeInterface
> ------------------------------------------------------
>
>                 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

[jira] Commented: (HBASE-3634) Fix JavaDoc for put(List puts) in HTabkeInterface

Posted by "stack (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006466#comment-13006466 ] 

stack commented on HBASE-3634:
------------------------------

Want to put up a patch Lars?  I like your first fix above rather than changing its behavior as you suggest in your second comment.

> Fix JavaDoc for put(List<Put> puts) in HTabkeInterface
> ------------------------------------------------------
>
>                 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

[jira] Commented: (HBASE-3634) Fix JavaDoc for put(List puts) in HTableInterface

Posted by "Lars George (JIRA)" <ji...@apache.org>.
    [ 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:

{code}
  /**
   * 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;
{code}

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

{code}
      if (!exceptions.isEmpty()) {
        throw new RetriesExhaustedWithDetailsException(exceptions,
            actions,
            addresses);
      }
{code}

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

{code}
     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;
       }
{code}

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

[jira] [Updated] (HBASE-3634) Fix JavaDoc for put(List puts) in HTableInterface

Posted by "Harsh J Chouraria (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harsh J Chouraria updated HBASE-3634:
-------------------------------------

    Attachment: HBASE-3634.r1.diff

Since HBASE-3670 covers the Get batch parts, here's a trivial javadocs change for this one (batch Puts' current approach).

> 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
>
>         Attachments: HBASE-3634.r1.diff
>
>
> 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