[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332391#comment-15332391 ] Jeff Zhang commented on HBASE-15410: I did some testing against Ted's patch and was able to reproduce the error he mentioned above. I think the error was due to FilterList being unable to reset the "seekHintFilter" set until nextRow() is called which effectively led the scan to a standstill if the max seek value returned points to the current row (i.e. column filter) which in turn caused the client timeout. To fix the issue, I suggest we clear the "seekHintFilter" set before we further execute any logic defined in the fiterKeyValue method. [~tedyu], what do you think of this approach? > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Attachments: 15410-wip.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > an optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] Created: (HBASE-3148) Duplicate check table name in HBaseAdmin's createTable method
Duplicate check table name in HBaseAdmin's createTable method - Key: HBASE-3148 URL: https://issues.apache.org/jira/browse/HBASE-3148 Project: HBase Issue Type: Improvement Components: client Reporter: Jeff Zhang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-3148) Duplicate check table name in HBaseAdmin's createTable method
[ https://issues.apache.org/jira/browse/HBASE-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924456#action_12924456 ] Jeff Zhang commented on HBASE-3148: --- When I learn the hbase code, I found that there's a duplicate check table name in HBaseAdmin's createTable method. Line 282 in createTable method do one check and line 332 do another check in createTableAsync which is called by createTable. I believe one check can been removed. Duplicate check table name in HBaseAdmin's createTable method - Key: HBASE-3148 URL: https://issues.apache.org/jira/browse/HBASE-3148 Project: HBase Issue Type: Improvement Components: client Reporter: Jeff Zhang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HBASE-3109) Support deletion of whole region
Support deletion of whole region - Key: HBASE-3109 URL: https://issues.apache.org/jira/browse/HBASE-3109 Project: HBase Issue Type: New Feature Reporter: Jeff Zhang Like the bulk import, bulk deletion would also be useful and efficiency for users. The following the instruction from stack: I think you could script it easy enough in TRUNK (I think you need TRUNK because you can ask it when a region is closed since there is no synchronous close of regions currently). 1. Close the region (See shell for how to send a close message or look at HBaseAdmin API doc). 2. While its closing, you may have to disable the region in .META. (See bin/*.rb scripts for how to mangle .META.). This may not be necessary IIRC in TRUNK (In 0.20.x, it is necessary to prevent the region being opened elsewhere when the regionserver reports sucessful close). 3. Check the regionserver periodically for the closing region. When its no longer mentioned in online regions, you know its closed. 4. Close the region that falls just after the one you just closed (Same trick w/ offlining above). Do fixup on meta where you extend the key scope of this region so that it covers the region just closed by making its startkey that of the region just closed. 5. Reenable (in 0.20. this would mean flipping region to be enabled again -- in TRUNK, you might have to explicitly open it on a regionserver -- would have to check). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
