[jira] [Updated] (HBASE-9904) Solve skipping data in HTable scans
[ https://issues.apache.org/jira/browse/HBASE-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9904: - Resolution: Won't Fix Status: Resolved (was: Patch Available) 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 Fix For: 0.89-fb 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.3.4#6332)
[jira] [Updated] (HBASE-9904) Solve skipping data in HTable scans
[ https://issues.apache.org/jira/browse/HBASE-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-9904: - Priority: Critical (was: Major) Fix Version/s: 0.98.0 We should try Manukranth's unit test against trunk. [~jxiang] You might be interested in this finding? 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: 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)
[jira] [Updated] (HBASE-9904) Solve skipping data in HTable scans
[ https://issues.apache.org/jira/browse/HBASE-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-9904: --- Attachment: TestScanRetries.java 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)
[jira] [Updated] (HBASE-9904) Solve skipping data in HTable scans
[ https://issues.apache.org/jira/browse/HBASE-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-9904: - Priority: Major (was: Critical) Fix Version/s: (was: 0.98.0) Thanks for taking a look [~jxiang] 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 Fix For: 0.89-fb 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)
[jira] [Updated] (HBASE-9904) Solve skipping data in HTable scans
[ https://issues.apache.org/jira/browse/HBASE-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manukranth Kolloju updated HBASE-9904: -- Hadoop Flags: Reviewed Status: Patch Available (was: Open) 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 Fix For: 0.89-fb 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)
[jira] [Updated] (HBASE-9904) Solve skipping data in HTable scans
[ https://issues.apache.org/jira/browse/HBASE-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manukranth Kolloju updated HBASE-9904: -- Attachment: scan.diff 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 Fix For: 0.89-fb Attachments: 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)
