[jira] [Comment Edited] (HBASE-7546) Obtain a table read lock on region split operations

["Enis Soztutar (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606988#comment-13606988 ] 

Enis Soztutar edited comment on HBASE-7546 at 3/19/13 11:12 PM:
----------------------------------------------------------------

Attaching a rebased patch. I wanted to test this one more time to make sure, which was why I did not commit it for some time. 

Quoting from the updated design doc attached at HBASE-7305: 

Unit tests
TestZKInterProcessReadWriteLock
Tests the pure zk lock implementation. 
TestTableLockManager
public void testAlterAndDisable() throws Exception {
    // Send a request to alter a table, then sleep during
    // the alteration phase. In the mean time, from another
    // thread, send a request to disable, and then delete a table.
}
 public void testTableReadLock() throws Exception {
   // test plan: write some data to the table. Continuously alter the table and
   // force splits
   // concurrently until we have 10 regions. verify the data just in case.
   // Every region should contain the same table descriptor
   // This is not an exact test
}
Sytem tests

Manual tests in 4 node cluster with 10MB flush and split size, and altering table constantly. #regions started with 20 and ended with ~160. The load is created with LoadTestTool.

On 5 node cluster, with 100MB flush size and split size, I tested the patch for HBASE-7305 and HBASE-7546 with IntegrationTestBigLinkedList and ChaosMonkey. A total of 125M rows was inserted and verified without any problems. The number of regions went from 1 to several hundred. I also did 1 or 2 alter tables manually. 

I think Stack already +1'd v3 (this is just a rebase). I will commit if hadoopqa passes, and no objections of course. 

                
      was (Author: enis):
    Attaching a rebased patch. I wanted to test this one more time to make sure, which was why I did not commit it for some time. 

Quoting from the updated design doc attached at HBASE-7403: 

Unit tests
TestZKInterProcessReadWriteLock
Tests the pure zk lock implementation. 
TestTableLockManager
public void testAlterAndDisable() throws Exception {
    // Send a request to alter a table, then sleep during
    // the alteration phase. In the mean time, from another
    // thread, send a request to disable, and then delete a table.
}
 public void testTableReadLock() throws Exception {
   // test plan: write some data to the table. Continuously alter the table and
   // force splits
   // concurrently until we have 10 regions. verify the data just in case.
   // Every region should contain the same table descriptor
   // This is not an exact test
}
Sytem tests

Manual tests in 4 node cluster with 10MB flush and split size, and altering table constantly. #regions started with 20 and ended with ~160. The load is created with LoadTestTool.

On 5 node cluster, with 100MB flush size and split size, I tested the patch for HBASE-7403 and HBASE-7546 with IntegrationTestBigLinkedList and ChaosMonkey. A total of 125M rows was inserted and verified without any problems. The number of regions went from 1 to several hundred. I also did 1 or 2 alter tables manually. 

I think Stack already +1'd v3 (this is just a rebase). I will commit if hadoopqa passes, and no objections of course. 

                  
> Obtain a table read lock on region split operations
> ---------------------------------------------------
>
>                 Key: HBASE-7546
>                 URL: https://issues.apache.org/jira/browse/HBASE-7546
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 0.95.0
>
>         Attachments: hbase-7546_v1.patch, hbase-7546_v2.patch, hbase-7546_v3.patch, hbase-7546_v5.patch
>
>
> As discussed in the parent issue HBASE-7305, we should be coordinating between splits and table operations to ensure that they don't happen at the same time. In this issue we will acquire shared read locks for region splits. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira