subject:"\\\[jira\\\] \\\[Commented\\\] \\\(HBASE\\\-5848\\\) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort"


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261332#comment-13261332
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-TRUNK #2810 (See 
[https://builds.apache.org/job/HBase-TRUNK/2810/])
HBASE-5848 Addendum (Revision 1330105)

 Result = FAILURE
larsh : 
Files : 
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261340#comment-13261340
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-TRUNK-security #183 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/183/])
HBASE-5848 Addendum (Revision 1330105)
HBASE-5848 Create table with EMPTY_START_ROW passed as splitKey causes the 
HMaster to abort (Ram) (Revision 1329819)

 Result = FAILURE
larsh : 
Files : 
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java

ramkrishna : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261342#comment-13261342
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-0.94 #147 (See 
[https://builds.apache.org/job/HBase-0.94/147/])
HBASE-5848 Addendum (Revision 1330106)

 Result = SUCCESS
larsh : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-25 Thread Zhihong Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261648#comment-13261648
 ] 

Zhihong Yu commented on HBASE-5848:
---

Looks like the addendum wasn't applied to trunk.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-25 Thread Lars Hofhansl (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261721#comment-13261721
]

Lars Hofhansl commented on HBASE-5848:
--

Yep, I committed the wrong the patch.
Reverted over in HBASE-5870, and committed the right patch. Sorry about that.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Key: HBASE-5848
URL: https://issues.apache.org/jira/browse/HBASE-5848
Project: HBase
Issue Type: Bug
Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
Fix For: 0.94.0, 0.96.0

Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt,
5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt,
5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch,
HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch

A coworker of mine just had this scenario. It does not make sense the
EMPTY_START_ROW as splitKey (since the region with the empty start key is
implicit), but it should not cause the HMaster to abort.
The abort happens because it tries to bulk assign the same region twice and
then runs into race conditions with ZK.
The same would (presumably) happen when two identical split keys are passed,
but the client blocks that. The simplest solution here is to also block
passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-25 Thread Lars Hofhansl (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261724#comment-13261724
 ] 

Lars Hofhansl commented on HBASE-5848:
--

Also double checked 0.94. All's good now.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261796#comment-13261796
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-TRUNK #2812 (See 
[https://builds.apache.org/job/HBase-TRUNK/2812/])
HBASE-5848 Addendum, try 2 (Revision 1330349)

 Result = FAILURE
larsh : 
Files : 
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261897#comment-13261897
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-0.94-security #21 (See 
[https://builds.apache.org/job/HBase-0.94-security/21/])
HBASE-5848 Addendum (Revision 1330106)

 Result = FAILURE
larsh : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262277#comment-13262277
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-TRUNK-security #184 (See 
[https://builds.apache.org/job/HBase-TRUNK-security/184/])
HBASE-5848 Addendum, try 2 (Revision 1330349)

 Result = FAILURE
larsh : 
Files : 
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260254#comment-13260254
 ] 

Lars Hofhansl commented on HBASE-5848:
--

@Ram: What I meant was doing this:
{code}
createTable(new HTableDescriptor(x), new byte[][] {null});
{code}
splitKeys is not null, but one of the contained keys is.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0

 Attachments: HBASE-5848.patch, HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260257#comment-13260257
]

ramkrishna.s.vasudevan commented on HBASE-5848:
---

@Lars
I tried that. It fails here throwing NPE in HBaseAdmin.createTableAsync
{code}
Arrays.sort(splitKeys, Bytes.BYTES_COMPARATOR);
{code}
Then there should be a prevalidator to check if the splitkeys has a null
element in it.
Ok i will add that validation also.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: HBASE-5848.patch, HBASE-5848.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260269#comment-13260269
]

Lars Hofhansl commented on HBASE-5848:
--

@Ram: That is probably overkill, means another loop over the splitKeys before
they are sorted. As long as it fails on the client (even with an NPE) and does
not cause the master to abort it's fine I think.

If you like to add the extra check now, that fine too.

+1 in either case. Going to bed now, feel free to commit :)

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: HBASE-5848.patch, HBASE-5848.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260667#comment-13260667
 ] 

ramkrishna.s.vasudevan commented on HBASE-5848:
---

@Lars
I will commit the version as it is.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0

 Attachments: HBASE-5848.patch, HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-24 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260719#comment-13260719
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-0.94 #143 (See 
[https://builds.apache.org/job/HBase-0.94/143/])
HBASE-5848 Create table with EMPTY_START_ROW passed as splitKey causes the 
HMaster to abort (Ram) (Revision 1329827)

 Result = FAILURE
ramkrishna : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: [jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-24 Thread Ramakrishna s vasudevan

The reason is because of HBASE-5848.  I forgot to do the submit patch option, 
so the hadoop QA did not run.
I will rectify the failures . Sorry for breaking the build.

Regards
Ram

From: Hudson (JIRA) [j...@apache.org]
Sent: Tuesday, April 24, 2012 10:49 PM
To: issues@hbase.apache.org
Subject: [jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW 
passed as splitKey causes the HMaster to abort

[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260719#comment-13260719
 ]

Hudson commented on HBASE-5848:
---

Integrated in HBase-0.94 #143 (See 
[https://builds.apache.org/job/HBase-0.94/143/])
HBASE-5848 Create table with EMPTY_START_ROW passed as splitKey causes the 
HMaster to abort (Ram) (Revision 1329827)

 Result = FAILURE
ramkrishna :
Files :
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch

 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-24 Thread Ramkrishna.S.Vasudevan (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260729#comment-13260729
]

Ramkrishna.S.Vasudevan commented on HBASE-5848:
---

The reason is because of HBASE-5848. I forgot to do the submit patch option,
so the hadoop QA did not run.
I will rectify the failures . Sorry for breaking the build.

Regards
Ram

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-24 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260787#comment-13260787
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-TRUNK #2807 (See 
[https://builds.apache.org/job/HBase-TRUNK/2807/])
HBASE-5848 Create table with EMPTY_START_ROW passed as splitKey causes the 
HMaster to abort (Ram) (Revision 1329819)

 Result = FAILURE
ramkrishna : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: HBASE-5848.patch, HBASE-5848.patch, 
 HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260784#comment-13260784
]

Hadoop QA commented on HBASE-5848:
--

-1 overall. Here are the results of testing the latest attachment

http://issues.apache.org/jira/secure/attachment/12524013/HBASE-5848_addendum.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 3 new or modified tests.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:

org.apache.hadoop.hbase.mapreduce.TestMultithreadedTableMapper
org.apache.hadoop.hbase.master.TestMasterTransitions

org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithRemove
org.apache.hadoop.hbase.TestFullLogReconstruction

org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort
org.apache.hadoop.hbase.client.TestFromClientSide
org.apache.hadoop.hbase.replication.TestReplication
org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan
org.apache.hadoop.hbase.mapred.TestTableMapReduce
org.apache.hadoop.hbase.client.TestMultiParallel
org.apache.hadoop.hbase.master.TestZKBasedOpenCloseRegion
org.apache.hadoop.hbase.mapreduce.TestTableMapReduce

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1628//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1628//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1628//console

This message is automatically generated.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: HBASE-5848.patch, HBASE-5848.patch,
HBASE-5848_0.94.patch, HBASE-5848_addendum.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260809#comment-13260809
 ] 

Zhihong Yu commented on HBASE-5848:
---

TestFullLogReconstruction#testReconstruction gave the following based on 
addendum:
{code}
012-04-24 11:35:48,409 WARN  [Thread-189] 
client.HConnectionManager$HConnectionImplementation(1020): Encountered problems 
when prefetch META table:
org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for 
table: tabletest, row=tabletest,aaa,99
  at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:158)
  at org.apache.hadoop.hbase.client.MetaScanner.access$000(MetaScanner.java:52)
  at org.apache.hadoop.hbase.client.MetaScanner$1.connect(MetaScanner.java:130)
  at org.apache.hadoop.hbase.client.MetaScanner$1.connect(MetaScanner.java:127)
  at 
org.apache.hadoop.hbase.client.HConnectionManager.execute(HConnectionManager.java:385)
  at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:127)
  at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:103)
  at 
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.prefetchRegionCache(HConnectionManager.java:1017)
  at 
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:1071)
  at 
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:959)
  at 
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatchCallback(HConnectionManager.java:1849)
  at 
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatch(HConnectionManager.java:1733)
  at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1020)
  at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:832)
  at org.apache.hadoop.hbase.client.HTable.put(HTable.java:807)
  at 
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:992)
  at 
org.apache.hadoop.hbase.TestFullLogReconstruction.testReconstruction(TestFullLogReconstruction.java:102)
{code}
Will try to come up with new addendum.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: HBASE-5848.patch, HBASE-5848.patch, 
 HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260985#comment-13260985
]

Hadoop QA commented on HBASE-5848:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12524036/5848-addendum-v3.txt
against trunk revision .

+1 @author. The patch does not contain any @author tags.

-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.client.TestAdmin

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1631//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1631//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1631//console

This message is automatically generated.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt,
HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch,
HBASE-5848_addendum.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261002#comment-13261002
 ] 

Lars Hofhansl commented on HBASE-5848:
--

As I said above, I can kill the HMaster by issuing.
{code}
createTable(new HTableDescriptor(x), new byte[][] 
{HConstants.EMPTY_START_ROW, new byte[] {1,2,3}});
{code}
So it happens also when HConstants.EMPTY_START_ROW is passed along with other 
split keys.


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, 
 HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261068#comment-13261068
 ] 

Zhihong Yu commented on HBASE-5848:
---

I modified testCreateTableWithEmptyRowInTheSplitKeys using the above pattern 
and master didn't crash (with addendum):
{code}
Index: src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java
===
--- src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java (revision 
1330037)
+++ src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java (working copy)
@@ -733,15 +733,13 @@
   @Test
   public void testCreateTableWithEmptyRowInTheSplitKeys() throws IOException{
 byte[] tableName = 
Bytes.toBytes(testCreateTableWithEmptyRowInTheSplitKeys);
-byte[][] splitKeys = new byte[3][];
-splitKeys[0] = region1.getBytes();
-splitKeys[1] = HConstants.EMPTY_BYTE_ARRAY;
-splitKeys[2] = region2.getBytes();
+byte[][] splitKeys = new byte[2][];
+splitKeys[0] = HConstants.EMPTY_BYTE_ARRAY;
+splitKeys[1] = region2.getBytes();
 HTableDescriptor desc = new HTableDescriptor(tableName);
 desc.addFamily(new HColumnDescriptor(col));
 try {
   admin.createTable(desc, splitKeys);
-  fail(Test case should fail as empty split key is passed.);
 } catch (IllegalArgumentException e) {
 }
   }
{code}

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, 
 HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261093#comment-13261093
 ] 

Lars Hofhansl commented on HBASE-5848:
--

The problem is that HBaseTestUtil.KEYS is used to two different things in the 
Tests: in HBaseAdmin.createTable* and in 
HBaseTestUtility.createMultiRegionsInMeta.
Ideally createMultiRegionsInMeta would be similar to HMaster.getHRegionInfos, 
but it is not. At this point it is too risky to change createMultiRegionsInMeta 
and createMultiRegions, so we should have to versions of HBaseTestUtil.KEYS - 
one that has the EMPTY_ROW for the test methods, and one that doesn't for the 
call to HMaster.createTable.


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, HBASE-5848.patch, HBASE-5848.patch, 
 HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261108#comment-13261108
 ] 

Lars Hofhansl commented on HBASE-5848:
--

@Ted: The minicluster (or timing in tests) is sufficiently different so that we 
cannot write a test that crashes the master (see my and Ram's comment above).


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, HBASE-5848.patch, HBASE-5848.patch, 
 HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261120#comment-13261120
]

Hadoop QA commented on HBASE-5848:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12524069/5848-addendum-v4.txt
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 3 new or modified tests.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:

org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1632//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1632//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1632//console

This message is automatically generated.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt,
5848-addendum-v4.txt, HBASE-5848.patch, HBASE-5848.patch,
HBASE-5848_0.94.patch, HBASE-5848_addendum.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261153#comment-13261153
 ] 

Zhihong Yu commented on HBASE-5848:
---

What about the root cause Ram identified: 
https://issues.apache.org/jira/browse/HBASE-5848?focusedCommentId=13259411page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13259411
 ?

A hacker can call master.createTable(desc, splitKeys) directly, bypassing 
HBaseAdmin. Right ?

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261174#comment-13261174
]

Lars Hofhansl commented on HBASE-5848:
--

Yes, that's also what I said above :)
There're more DOS attacks against HBase (like passing a doctored RPC with a
size of 4GB, etc), though.

+1 on fixing the root cause too, of course.

Lemme do a combined patch quickly...

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt,
5848-addendum-v4.txt, 5848-addendum-v5.txt, HBASE-5848.patch,
HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261176#comment-13261176
]

Hadoop QA commented on HBASE-5848:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12524082/5848-addendum-v5.txt
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 12 new or modified tests.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:

org.apache.hadoop.hbase.coprocessor.TestRowProcessorEndpoint

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1634//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1634//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1634//console

This message is automatically generated.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt,
5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt,
HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch,
HBASE-5848_addendum.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261182#comment-13261182
 ] 

Zhihong Yu commented on HBASE-5848:
---

Addendum v6 looks good.
BTW this is the highest numbered addendum I have ever worked with :-)

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, 
 HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261187#comment-13261187
 ] 

Lars Hofhansl commented on HBASE-5848:
--

:) Yes, was thinking that too.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, 
 HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261194#comment-13261194
 ] 

Lars Hofhansl commented on HBASE-5848:
--

Will wait for HadoopQA, and commit if all is good.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, 
 HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-24 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261225#comment-13261225
 ] 

Hudson commented on HBASE-5848:
---

Integrated in HBase-0.94-security #20 (See 
[https://builds.apache.org/job/HBase-0.94-security/20/])
HBASE-5848 Create table with EMPTY_START_ROW passed as splitKey causes the 
HMaster to abort (Ram) (Revision 1329827)

 Result = SUCCESS
ramkrishna : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, 
 HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261274#comment-13261274
]

ramkrishna.s.vasudevan commented on HBASE-5848:
---

Sorry guys... :(
I was the reason for this trouble. I should have been very careful before
doing this.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261278#comment-13261278
]

Lars Hofhansl commented on HBASE-5848:
--

@Ram: No worries. I looked at the patch too. This is part of doing development.
:)

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261298#comment-13261298
]

Hadoop QA commented on HBASE-5848:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12524107/5848-addendum-v7.txt
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 3 new or modified tests.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

+1 core tests. The patch passed unit tests in .

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1640//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1640//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1640//console

This message is automatically generated.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261304#comment-13261304
]

Hadoop QA commented on HBASE-5848:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12524110/5848-addendum-v7.txt
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 3 new or modified tests.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.client.TestFromClientSide
org.apache.hadoop.hbase.replication.TestReplication

org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1641//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1641//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1641//console

This message is automatically generated.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261306#comment-13261306
 ] 

ramkrishna.s.vasudevan commented on HBASE-5848:
---

@Lars and @Ted
Thank you very much.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: ramkrishna.s.vasudevan
Priority: Minor
 Fix For: 0.94.0, 0.96.0

 Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, 
 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, 
 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, 
 HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259411#comment-13259411
 ] 

ramkrishna.s.vasudevan commented on HBASE-5848:
---

@Lars
I have analysed this problem.
First thing is if we pass an empty byte array it is trying to form two regions 
with empty start and end keys.
But the reason for it to abort is when it tries to form the two regions it so 
happens that the region id generated from the System.currenttimeInMillis 
becomes same and it tries to create the same node twice. And hence we get that 
aborting from the asyncSetOfflineInZooKeeper
{code}
CreateUnassignedAsyncCallback cb =
  new CreateUnassignedAsyncCallback(this.watcher, destination, counter);
for (RegionState state: states) {
  if (!asyncSetOfflineInZooKeeper(state, cb, state)) {
return;
  }
}
{code}
The region Id is formed from
{code}
 public HRegionInfo(final byte[] tableName, final byte[] startKey,
 final byte[] endKey, final boolean split)
  throws IllegalArgumentException {
this(tableName, startKey, endKey, split, System.currentTimeMillis());
  }
{code}

So there is always a chance that we get same region id but just because the 
start key and end key changes we were not encountering this problem.
I suggest we add a logic explicitly to avoid 2 regions from getting formed and 
also the main thing is can we take System.nanoTime for the region id.?

Even i was not able to get this repeatedly in testcases but a real cluster 
gives you the problem.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor

 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259721#comment-13259721
 ] 

ramkrishna.s.vasudevan commented on HBASE-5848:
---

@Lars
Are you working on this? If not i will take up this?

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor

 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-23 Thread Zhihong Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259740#comment-13259740
 ] 

Zhihong Yu commented on HBASE-5848:
---

According to 
http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29:
This method can only be used to measure elapsed time and is not related to any 
other notion of system or wall-clock time

So we shouldn't use nanoTime().

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor

 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-23 Thread Zhihong Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259829#comment-13259829
 ] 

Zhihong Yu commented on HBASE-5848:
---

+1 on patch.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Attachments: HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-23 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259935#comment-13259935
 ] 

stack commented on HBASE-5848:
--

@Ram This is a nit comment for future patches, not for this one.

I would suggest you avoid changes like below going forward:

{code}
-  hRegionInfos = new HRegionInfo[]{
-  new HRegionInfo(hTableDescriptor.getName(), null, null)};
+  hRegionInfos = new HRegionInfo[] { new HRegionInfo(hTableDescriptor
+  .getName(), null, null) };
{code}

The replacement is harder to read w/ its break in the middle of a phrase.

Patch lgtm.

Lars, does this fix the issue you saw?


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Attachments: HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-23 Thread Lars Hofhansl (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260016#comment-13260016
 ] 

Lars Hofhansl commented on HBASE-5848:
--

Thanks for the patch Ram.

The problem also occurs with 
{code}
createTable(new HTableDescriptor(x), new byte[][] 
{HConstants.EMPTY_START_ROW, new byte[] {1,2,3}});
{code}
I do not think the patch would address that.


 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Attachments: HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-23 Thread Lars Hofhansl (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260040#comment-13260040
 ] 

Lars Hofhansl commented on HBASE-5848:
--

The client already checks for duplicate keys in splitKeys, we could just check 
for the empty key as well (no sense passing the empty key to createTable 
anyway), and throw an error as well.
Obviously that does not guard against rogue clients and it would be extremely 
simple to DOS an HBase cluster.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Attachments: HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

[
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260184#comment-13260184
]

ramkrishna.s.vasudevan commented on HBASE-5848:
---

@Lars
Yes, i was just checking that part of the issue that you have said.
I was first thinking not to throw an error if empty key is passed but
considering the other case where an empty key is passed along with other keys
then ideally that should be the choice. I will update my patch with tat.

Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to
abort

Key: HBASE-5848
URL: https://issues.apache.org/jira/browse/HBASE-5848
Project: HBase
Issue Type: Bug
Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
Attachments: HBASE-5848.patch

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260229#comment-13260229
 ] 

ramkrishna.s.vasudevan commented on HBASE-5848:
---

Latest patch tries to avoid empty split keys from the HBaseAdmin side itself.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Attachments: HBASE-5848.patch, HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort

2012-04-23 Thread Lars Hofhansl (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260235#comment-13260235
 ] 

Lars Hofhansl commented on HBASE-5848:
--

Should also check for null (which is interpreted as empty key at the server).
+1 otherwise.

 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to 
 abort
 

 Key: HBASE-5848
 URL: https://issues.apache.org/jira/browse/HBASE-5848
 Project: HBase
  Issue Type: Bug
  Components: client
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.94.0

 Attachments: HBASE-5848.patch, HBASE-5848.patch


 A coworker of mine just had this scenario. It does not make sense the 
 EMPTY_START_ROW as splitKey (since the region with the empty start key is 
 implicit), but it should not cause the HMaster to abort.
 The abort happens because it tries to bulk assign the same region twice and 
 then runs into race conditions with ZK.
 The same would (presumably) happen when two identical split keys are passed, 
 but the client blocks that. The simplest solution here is to also block 
 passed null or EMPTY_START_ROW as split key by the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort