[ https://issues.apache.org/jira/browse/HBASE-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816306#comment-13816306 ]
Jimmy Xiang edited comment on HBASE-9904 at 11/7/13 7:31 PM: ------------------------------------------------------------- I attached the revised TestScanRetries.java that works with trunk, just changed it to fit with the new interfaces. BTW, missed that: need to set caching/batch to 1 at line 133 since there are only 6 rows: {code} scan.setBatch(1); scan.setCaching(1); {code} was (Author: jxiang): I attached the revised TestScanRetries.java that works with trunk, just changed it to fit with the new interfaces. > Solve skipping data in HTable scans > ----------------------------------- > > Key: HBASE-9904 > URL: https://issues.apache.org/jira/browse/HBASE-9904 > Project: HBase > Issue Type: Bug > Components: Client > Affects Versions: 0.89-fb > Reporter: Manukranth Kolloju > Priority: Critical > Fix For: 0.89-fb, 0.98.0 > > Attachments: TestScanRetries.java, scan.diff > > > The HTable client cannot retry a scan operation in the > getRegionServerWithRetries code path. > This will result in the client missing data. This can be worked around using > hbase.client.retries.number to 1. > The whole problem is that Callable knows nothing about retries and the > protocol it dances to as well doesn't support retires. > This fix will keep Callable protocol (ugly thing worth merciless refactoring) > intact but will change > ScannerCallable to anticipate retries. What we want is to make failed > operations to be identities for outside world: > N1 , N2 , F3 , N3 , F4 , F4 , N4 ... = N1 , N2 , N3 , N4 ... > where Nk are successful operation and Fk are failed operations. -- This message was sent by Atlassian JIRA (v6.1#6144)