[
https://issues.apache.org/jira/browse/HBASE-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658786#comment-13658786
]
Ted Yu commented on HBASE-6295:
-------------------------------
{code}
+ public List<? extends Row> getFailedOperation(){
{code}
getFailedOperation -> getFailedOperations
{code}
+ public AsyncProcess(HConnection hci, byte[] tableName, ExecutorService
pool,
+ Batch.Callback<Res> callback){
+ this.hci = (HConnectionImplementation)hci;
{code}
If methods of HConnectionImplementation which are not in HConnection are used,
parameter hci should be declared as HConnectionImplementation.
{code}
+ public void submit(List<? extends Row> rowList) throws IOException {
+ waitForMaximumTaskNumber(maxTotalConcurrentTasks);
+
+ if (!hasError()){
+ submit(rowList, 1, false);
+ }
{code}
For else case, should error condition be conveyed through boolean return value
or some exception ?
{code}
+ * @param rowList
+ * @param numAttempt
+ * @throws IOException - if we can't locate a region after multiple
retries.
+ */
+ private void submit(List<? extends Row> rowList, int numAttempt, boolean
force)
{code}
Please add force parameter to javadoc. Brief explanation for the parameters
should help.
{code}
+ if (loc == null) {
+ throw new IOException("No location found, aborting submit.");
{code}
I think including tableName and row.getRow() in exception message would help
debug.
> Possible performance improvement in client batch operations: presplit and
> send in background
> --------------------------------------------------------------------------------------------
>
> Key: HBASE-6295
> URL: https://issues.apache.org/jira/browse/HBASE-6295
> Project: HBase
> Issue Type: Improvement
> Components: Client, Performance
> Affects Versions: 0.95.2
> Reporter: Nicolas Liochon
> Assignee: Nicolas Liochon
> Labels: noob
> Attachments: 6295.v1.patch, 6295.v2.patch, 6295.v3.patch,
> 6295.v4.patch, 6295.v5.patch, 6295.v6.patch
>
>
> today batch algo is:
> {noformat}
> for Operation o: List<Op>{
> add o to todolist
> if todolist > maxsize or o last in list
> split todolist per location
> send split lists to region servers
> clear todolist
> wait
> }
> {noformat}
> We could:
> - create immediately the final object instead of an intermediate array
> - split per location immediately
> - instead of sending when the list as a whole is full, send it when there is
> enough data for a single location
> It would be:
> {noformat}
> for Operation o: List<Op>{
> get location
> add o to todo location.todolist
> if (location.todolist > maxLocationSize)
> send location.todolist to region server
> clear location.todolist
> // don't wait, continue the loop
> }
> send remaining
> wait
> {noformat}
> It's not trivial to write if you add error management: retried list must be
> shared with the operations added in the todolist. But it's doable.
> It's interesting mainly for 'big' writes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
