[ https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003336#comment-15003336 ]
Lars Hofhansl edited comment on HBASE-14791 at 11/13/15 1:42 AM: ----------------------------------------------------------------- Looks good! [~alexaraujo] Two questions: # Would subclassing (as opposed to delegation as used in the patch) save us a bunch of code? # Would the change from HTable to HTableInterface break compatibility for folks subclasses TableOutputFormat? (would not be an issue too if we do the subclassing of #1) was (Author: lhofhansl): Looks good! Two questions: # Would subclassing (as opposed to delegation as used in the patch) save us a bunch of code? # Would the change from HTable to HTableInterface break compatibility for folks subclasses TableOutputFormat? (would not be an issue too if we do the subclassing of #1) > [0.98] CopyTable is extremely slow when moving delete markers > ------------------------------------------------------------- > > Key: HBASE-14791 > URL: https://issues.apache.org/jira/browse/HBASE-14791 > Project: HBase > Issue Type: Bug > Affects Versions: 0.98.16 > Reporter: Lars Hofhansl > Assignee: Alex Araujo > Attachments: HBASE-14791-0.98-v1.patch > > > We found that some of our copy table job run for many hours, even when there > isn't that much data to copy. > [~vik.karma] did his magic and found that the issue is with copying delete > markers (we use raw mode to also move deletes across). > Looking at the code in 0.98 it's immediately obvious that deletes (unlike > puts) are not batched and hence sent to the other side one by one, causing a > network RTT for each delete marker. > Looks like in trunk it's doing the right thing (using BufferedMutators for > all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1, > 1.2?) issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)