You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@accumulo.apache.org by el...@apache.org on 2015/08/27 18:06:19 UTC
[10/12] accumulo git commit: Merge branch '1.6' into 1.7
Merge branch '1.6' into 1.7
Conflicts:
core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
Project: http://git-wip-us.apache.org/repos/asf/accumulo/repo
Commit: http://git-wip-us.apache.org/repos/asf/accumulo/commit/162acf2f
Tree: http://git-wip-us.apache.org/repos/asf/accumulo/tree/162acf2f
Diff: http://git-wip-us.apache.org/repos/asf/accumulo/diff/162acf2f
Branch: refs/heads/master
Commit: 162acf2f2223e25fa84921eb1fb15749599f7242
Parents: 388e48c 2906895
Author: Josh Elser <el...@apache.org>
Authored: Thu Aug 27 11:54:25 2015 -0400
Committer: Josh Elser <el...@apache.org>
Committed: Thu Aug 27 12:06:14 2015 -0400
----------------------------------------------------------------------
.../accumulo/core/client/BatchScanner.java | 24 ++++++++++++++------
1 file changed, 17 insertions(+), 7 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/accumulo/blob/162acf2f/core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
----------------------------------------------------------------------
diff --cc core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
index 494bf56,af0fd85..0048c42
--- a/core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
+++ b/core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
@@@ -19,20 -21,34 +21,28 @@@ import org.apache.accumulo.core.data.Ra
import java.util.Collection;
import java.util.concurrent.TimeUnit;
- import org.apache.accumulo.core.data.Range;
-
/**
- * Implementations of BatchScanner support efficient lookups of many ranges in accumulo.
- * In exchange for possibly <b>returning scanned entries out of order</b>,
- * BatchScanner implementations may scan an Accumulo table more efficiently by
++ * In exchange for possibly <b>returning scanned entries out of order</b>, BatchScanner implementations may scan an Accumulo table more efficiently by
+ * <ul>
- * <li>Looking up multiple ranges in parallel.
- * Parallelism is constrained by the number of threads available to the BatchScanner, set in its constructor.</li>
- * <li>Breaking up large ranges into subranges.
- * Often the number and boundaries of subranges are determined by a table's split points.</li>
- * <li>Combining multiple ranges into a single RPC call to a tablet server.</li>
++ * <li>Looking up multiple ranges in parallel. Parallelism is constrained by the number of threads available to the BatchScanner, set in its constructor.</li>
++ * <li>Breaking up large ranges into subranges. Often the number and boundaries of subranges are determined by a table's split points.</li>
++ * <li>Combining multiple ranges into a single RPC call to a tablet server.</li>
+ * </ul>
*
- * Use this when looking up lots of ranges and you expect each range to contain a small amount of data. Also only use this when you do not care about the
- * returned data being in sorted order.
+ * The above techniques lead to better performance than a {@link Scanner} in use cases such as
+ * <ul>
- * <li>Retrieving many small ranges</li>
- * <li>Scanning a large range that returns many entries</li>
- * <li>Running server-side iterators that perform computation,
- * even if few entries are returned from the scan itself</li>
++ * <li>Retrieving many small ranges</li>
++ * <li>Scanning a large range that returns many entries</li>
++ * <li>Running server-side iterators that perform computation, even if few entries are returned from the scan itself</li>
+ * </ul>
*
- * If you want to lookup a few ranges and expect those ranges to contain a lot of data, then use the Scanner instead. Also, the Scanner will return data in
- * sorted order, this will not.
- * To re-emphasize, only use a BatchScanner when you do not care whether returned data is in sorted order.
- * Use a {@link Scanner} instead when sorted order is important.
++ * To re-emphasize, only use a BatchScanner when you do not care whether returned data is in sorted order. Use a {@link Scanner} instead when sorted order is
++ * important.
*
+ * <p>
- * A BatchScanner instance will use no more threads than provided in the construction of the BatchScanner
- * implementation. Multiple invocations of <code>iterator()</code> will all share the same resources of the instance.
- * A new BatchScanner instance should be created to use allocate additional threads.
+ * A BatchScanner instance will use no more threads than provided in the construction of the BatchScanner implementation. Multiple invocations of
+ * <code>iterator()</code> will all share the same resources of the instance. A new BatchScanner instance should be created to use allocate additional threads.
*/
-
public interface BatchScanner extends ScannerBase {
/**