You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org> on 2011/03/15 22:06:35 UTC
[jira] Created: (HBASE-3650) HBA.delete can return too fast
HBA.delete can return too fast
------------------------------
Key: HBASE-3650
URL: https://issues.apache.org/jira/browse/HBASE-3650
Project: HBase
Issue Type: Bug
Affects Versions: 0.90.1
Reporter: Jean-Daniel Cryans
Assignee: Jean-Daniel Cryans
Priority: Blocker
Fix For: 0.90.2
One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (HBASE-3650) HBA.delete can return too fast
Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Daniel Cryans resolved HBASE-3650.
---------------------------------------
Resolution: Fixed
Hadoop Flags: [Reviewed]
Committed to branch and trunk, thanks for the review Stack.
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650-v2.patch, HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3650) HBA.delete can return too fast
Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007287#comment-13007287 ]
Jean-Daniel Cryans commented on HBASE-3650:
-------------------------------------------
Here's what we accept in tables' names:
{code}
Character.isLetterOrDigit(b[i]) || b[i] == '_' || b[i] == '-' ||
b[i] == '.'
{code}
So Space is smaller than any of those.
I'll clean the rest, thanks for taking a look!
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HBASE-3650) HBA.delete can return too fast
Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Daniel Cryans updated HBASE-3650:
--------------------------------------
Attachment: HBASE-3650.patch
This patch adds a new utility in MetaReader to configure a Scan that only reads the rows from a single table, then refactors both HBA and MetaReader to use it. Finally it adds a test to make sure the method is getting the right rows from .META.
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HBASE-3650) HBA.delete can return too fast
Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Daniel Cryans updated HBASE-3650:
--------------------------------------
Attachment: HBASE-3650-v2.patch
Cleans up what Stack pointed at and adds more refactoring in MetaReader.
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650-v2.patch, HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3650) HBA.delete can return too fast
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007862#comment-13007862 ]
Hudson commented on HBASE-3650:
-------------------------------
Integrated in HBase-TRUNK #1792 (See [https://hudson.apache.org/hudson/job/HBase-TRUNK/1792/])
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650-v2.patch, HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3650) HBA.delete can return too fast
Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007480#comment-13007480 ]
Jean-Daniel Cryans commented on HBASE-3650:
-------------------------------------------
All the unit tests are passing with this patch:
{quote}
Tests run: 629, Failures: 0, Errors: 0, Skipped: 9
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 82 minutes 37 seconds
[INFO] Finished at: Tue Mar 15 23:36:03 PDT 2011
[INFO] Final Memory: 63M/123M
[INFO] ------------------------------------------------------------------------
{quote}
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650-v2.patch, HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3650) HBA.delete can return too fast
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007542#comment-13007542 ]
stack commented on HBASE-3650:
------------------------------
+1 I love to see removal of dup'd code.
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650-v2.patch, HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3650) HBA.delete can return too fast
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007285#comment-13007285 ]
stack commented on HBASE-3650:
------------------------------
Do we allow tables w/ '+' in their name? Or anything < ','?
THere is a system.out that you probably want to remove on commit.
Add javadoc to this method, + public static Scan getScanForTableName(byte[] tableName) {, since its going to be come really popular really quickly.
+1
> HBA.delete can return too fast
> ------------------------------
>
> Key: HBASE-3650
> URL: https://issues.apache.org/jira/browse/HBASE-3650
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.2
>
> Attachments: HBASE-3650.patch
>
>
> One of our engineers got a weird TableExistsException in his code and I see that the client-side logging says the table was deleted in less than a second while it took the master 5 seconds to do it. Doing code inspection, the .META. scanner in HBA.delete can set _found_ to _true_ and then set it back to _false_ in the case where the deleted table isn't the last one. We should just do a scan that would get the rows specific to the table instead of scanning *all* the rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira