date:20120621


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

Lars Hofhansl commented on HBASE-6116:
--

@Andrew: Awesome!
A comparative benchmark is still useful I think. Only if it is not too much 
work, as the standard deviation will be high on EC2. I think you'll see an 
improvement in a write heavy test.


 Allow parallel HDFS writes for HLogs.
 -

 Key: HBASE-6116
 URL: https://issues.apache.org/jira/browse/HBASE-6116
 Project: HBase
  Issue Type: Bug
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
 Attachments: 6116-v1.txt


 In HDFS-1783 I adapted Dhrubas changes to be used in Hadoop trunk.
 This issue will include the necessary reflection changes to optionally enable 
 this for the WALs in HBase.

--
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-6058) Use ZK 3.4 API 'multi' in bulk assignment

2012-06-21 Thread nkeywal (JIRA)

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

nkeywal commented on HBASE-6058:

All the tests I made with multi were successful. But they were only tests :-).
Note it's not totally trivial to use it in bulk assignment, because we have two
levels of asynchronous calls (the callback calls another asynchronous
function). So supporting both ZK version (with without multi) would be
looking for issue imho.
And fixing ZOOKEEPER-1381 would help on deployment, today we hang if we call
multi on a 3.3 ZK server...
Anyway, I will redo some perfo tests to see where we are now with the current
implementation.

Use ZK 3.4 API 'multi' in bulk assignment
-

Key: HBASE-6058
URL: https://issues.apache.org/jira/browse/HBASE-6058
Project: HBase
Issue Type: Improvement
Components: master, zookeeper
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor

We use async API today. This is already much much faster than the sync API.
Still, it makes sense to use the 'multi' function: this will decrease the
network zookeeper load at startup/rolling restart.
On a 500 nodes cluster, we see 3 that 3 seconds are spent on updating ZK per
bulk assignment. This should cut it in half (+ the benefits on the network/zk
load).

--
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] [Updated] (HBASE-6200) KeyComparator.compareWithoutRow can be wrong when families have the same prefix

2012-06-21 Thread Jieshan Bean (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jieshan Bean updated HBASE-6200:


Attachment: HBASE-6200-trunk.patch

A patch of separately comparison for CF and Qualiifer. 

 KeyComparator.compareWithoutRow can be wrong when families have the same 
 prefix
 ---

 Key: HBASE-6200
 URL: https://issues.apache.org/jira/browse/HBASE-6200
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Jieshan Bean
Priority: Blocker
 Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1

 Attachments: HBASE-6200-trunk.patch


 As reported by Desert Rose on IRC and on the ML, {{Result}} has a weird 
 behavior when some families share the same prefix. He posted a link to his 
 code to show how it fails, http://pastebin.com/7TBA1XGh
 Basically {{KeyComparator.compareWithoutRow}} doesn't differentiate families 
 and qualifiers so f:a is said to be bigger than f1:, which is false. Then 
 what happens is that the KVs are returned in the right order from the RS but 
 then doing {{Result.binarySearch}} it uses 
 {{KeyComparator.compareWithoutRow}} which has a different sorting so the end 
 result is undetermined.
 I added some debug and I can see that the data is returned in the right order 
 but {{Arrays.binarySearch}} returned the wrong KV, which is then verified 
 agains the passed family and qualifier which fails so null is returned.
 I don't know how frequent it is for users to have families with the same 
 prefix, but those that do have that and that use those families at the same 
 time will have big correctness issues. This is why I mark this as a blocker.

--
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] [Updated] (HBASE-6200) KeyComparator.compareWithoutRow can be wrong when families have the same prefix


 [ 
https://issues.apache.org/jira/browse/HBASE-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated HBASE-6200:
-

Status: Patch Available  (was: Open)

Thanks Jieshan!
Looks good off-hand (haven't looked too closely, though). Let's get a test-run 
in.

 KeyComparator.compareWithoutRow can be wrong when families have the same 
 prefix
 ---

 Key: HBASE-6200
 URL: https://issues.apache.org/jira/browse/HBASE-6200
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.92.1, 0.90.6
Reporter: Jean-Daniel Cryans
Assignee: Jieshan Bean
Priority: Blocker
 Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1

 Attachments: HBASE-6200-trunk.patch


 As reported by Desert Rose on IRC and on the ML, {{Result}} has a weird 
 behavior when some families share the same prefix. He posted a link to his 
 code to show how it fails, http://pastebin.com/7TBA1XGh
 Basically {{KeyComparator.compareWithoutRow}} doesn't differentiate families 
 and qualifiers so f:a is said to be bigger than f1:, which is false. Then 
 what happens is that the KVs are returned in the right order from the RS but 
 then doing {{Result.binarySearch}} it uses 
 {{KeyComparator.compareWithoutRow}} which has a different sorting so the end 
 result is undetermined.
 I added some debug and I can see that the data is returned in the right order 
 but {{Arrays.binarySearch}} returned the wrong KV, which is then verified 
 agains the passed family and qualifier which fails so null is returned.
 I don't know how frequent it is for users to have families with the same 
 prefix, but those that do have that and that use those families at the same 
 time will have big correctness issues. This is why I mark this as a blocker.

--
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-6248) Jetty init may fail if directory name contains master


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

Hudson commented on HBASE-6248:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #62 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/62/])
HBASE-6248 Jetty init may fail if directory name contains master (Dave 
Revell) (Revision 1352395)

 Result = FAILURE
tedyu : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/InfoServer.java


 Jetty init may fail if directory name contains master
 ---

 Key: HBASE-6248
 URL: https://issues.apache.org/jira/browse/HBASE-6248
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 0.94.0
Reporter: Dave Revell
Assignee: Dave Revell
Priority: Minor
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6248-0.94.0-0.diff, HBASE-6248-0.94.0-1.diff


 InfoServer.getWebAppsPath() unsafely assumes that any instance of the string 
 master in the full path to hbase-webapps can be truncated. This breaks in 
 the case where hbase is installed in a directory such as /my/hbasemaster/.
 The result is that Jetty initialization will fail since the master determines 
 an incorrect path to hbase-webapps. The master still runs but the web UI 
 returns 503.
 I have a patch for this problem that I'll upload soon.

--
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-6200) KeyComparator.compareWithoutRow can be wrong when families have the same prefix


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

Zhihong Ted Yu commented on HBASE-6200:
---

Hadoop QA is not functioning due to svn version.
Running tests locally.

 KeyComparator.compareWithoutRow can be wrong when families have the same 
 prefix
 ---

 Key: HBASE-6200
 URL: https://issues.apache.org/jira/browse/HBASE-6200
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Jieshan Bean
Priority: Blocker
 Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1

 Attachments: HBASE-6200-trunk.patch


 As reported by Desert Rose on IRC and on the ML, {{Result}} has a weird 
 behavior when some families share the same prefix. He posted a link to his 
 code to show how it fails, http://pastebin.com/7TBA1XGh
 Basically {{KeyComparator.compareWithoutRow}} doesn't differentiate families 
 and qualifiers so f:a is said to be bigger than f1:, which is false. Then 
 what happens is that the KVs are returned in the right order from the RS but 
 then doing {{Result.binarySearch}} it uses 
 {{KeyComparator.compareWithoutRow}} which has a different sorting so the end 
 result is undetermined.
 I added some debug and I can see that the data is returned in the right order 
 but {{Arrays.binarySearch}} returned the wrong KV, which is then verified 
 agains the passed family and qualifier which fails so null is returned.
 I don't know how frequent it is for users to have families with the same 
 prefix, but those that do have that and that use those families at the same 
 time will have big correctness issues. This is why I mark this as a blocker.

--
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] [Created] (HBASE-6253) isLegalTableName API should check for the _acl_ table name

Gopinathan A created HBASE-6253:
---

 Summary: isLegalTableName API should check for the _acl_ table name
 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1


Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
table name, due to this user can able to disable/enable/drop/create the acl 
table. 

--
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] [Updated] (HBASE-6253) isLegalTableName API should check for the _acl_ table name


 [ 
https://issues.apache.org/jira/browse/HBASE-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gopinathan A updated HBASE-6253:


Attachment: HBASE-6253.patch

 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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] [Updated] (HBASE-6253) isLegalTableName API should check for the _acl_ table name


 [ 
https://issues.apache.org/jira/browse/HBASE-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gopinathan A updated HBASE-6253:


Status: Patch Available  (was: Open)

 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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-6200) KeyComparator.compareWithoutRow can be wrong when families have the same prefix


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

Zhihong Ted Yu commented on HBASE-6200:
---

Patch looks great.
Minor comments:
{code}
+ * validate that assumption here.
+ * 
{code}
There is a whitespace at the end of second line above.
{code}
+  int lqualifierlength = llength - TIMESTAMP_TYPE_SIZE
+  - (lfamilyoffset - loffset) - lfamilylength;
{code}
lfamilyoffset - loffset is actually commonLength. Replace it with commonLength 
makes code easier to read.
Same with the computation of rqualifierlength

There're 5 new white spaces in TestKeyValue

 KeyComparator.compareWithoutRow can be wrong when families have the same 
 prefix
 ---

 Key: HBASE-6200
 URL: https://issues.apache.org/jira/browse/HBASE-6200
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Jieshan Bean
Priority: Blocker
 Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1

 Attachments: HBASE-6200-trunk.patch


 As reported by Desert Rose on IRC and on the ML, {{Result}} has a weird 
 behavior when some families share the same prefix. He posted a link to his 
 code to show how it fails, http://pastebin.com/7TBA1XGh
 Basically {{KeyComparator.compareWithoutRow}} doesn't differentiate families 
 and qualifiers so f:a is said to be bigger than f1:, which is false. Then 
 what happens is that the KVs are returned in the right order from the RS but 
 then doing {{Result.binarySearch}} it uses 
 {{KeyComparator.compareWithoutRow}} which has a different sorting so the end 
 result is undetermined.
 I added some debug and I can see that the data is returned in the right order 
 but {{Arrays.binarySearch}} returned the wrong KV, which is then verified 
 agains the passed family and qualifier which fails so null is returned.
 I don't know how frequent it is for users to have families with the same 
 prefix, but those that do have that and that use those families at the same 
 time will have big correctness issues. This is why I mark this as a blocker.

--
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] [Updated] (HBASE-5875) Process RIT and Master restart may remove an online server considering it as a dead server

[
https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

rajeshbabu updated HBASE-5875:
--

Attachment: HBASE-5875_trunk.patch

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Key: HBASE-5875
URL: https://issues.apache.org/jira/browse/HBASE-5875
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 0.94.1

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

If on master restart it finds the ROOT/META to be in RIT state, master tries
to assign the ROOT region through ProcessRIT.
Master will trigger the assignment and next will try to verify the Root
Region Location.
Root region location verification is done seeing if the RS has the region in
its online list.
If the master triggered assignment has not yet been completed in RS then the
verify root region location will fail.
Because it failed
{code}
splitLogAndExpireIfOnline(currentRootServer);
{code}
we do split log and also remove the server from online server list. Ideally
here there is nothing to do in splitlog as no region server was restarted.
So master, though the server is online, master just invalidates the region
server.
In a special case, if i have only one RS then my cluster will become non
operative.

[jira] [Updated] (HBASE-5875) Process RIT and Master restart may remove an online server considering it as a dead server

[
https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

rajeshbabu updated HBASE-5875:
--

Status: Open (was: Patch Available)

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

[jira] [Updated] (HBASE-5875) Process RIT and Master restart may remove an online server considering it as a dead server

[
https://issues.apache.org/jira/browse/HBASE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

rajeshbabu updated HBASE-5875:
--

Status: Patch Available (was: Open)

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

[jira] [Commented] (HBASE-5875) Process RIT and Master restart may remove an online server considering it as a dead server

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

rajeshbabu commented on HBASE-5875:
---

Attached patch for trunk. Please review and provide comments/suggestions.

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

[jira] [Commented] (HBASE-6200) KeyComparator.compareWithoutRow can be wrong when families have the same prefix


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

Zhihong Ted Yu commented on HBASE-6200:
---

@Jieshan:
Please provide patches for other branches after addressing review comments.

Thanks

 KeyComparator.compareWithoutRow can be wrong when families have the same 
 prefix
 ---

 Key: HBASE-6200
 URL: https://issues.apache.org/jira/browse/HBASE-6200
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Jieshan Bean
Priority: Blocker
 Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1

 Attachments: HBASE-6200-trunk.patch


 As reported by Desert Rose on IRC and on the ML, {{Result}} has a weird 
 behavior when some families share the same prefix. He posted a link to his 
 code to show how it fails, http://pastebin.com/7TBA1XGh
 Basically {{KeyComparator.compareWithoutRow}} doesn't differentiate families 
 and qualifiers so f:a is said to be bigger than f1:, which is false. Then 
 what happens is that the KVs are returned in the right order from the RS but 
 then doing {{Result.binarySearch}} it uses 
 {{KeyComparator.compareWithoutRow}} which has a different sorting so the end 
 result is undetermined.
 I added some debug and I can see that the data is returned in the right order 
 but {{Arrays.binarySearch}} returned the wrong KV, which is then verified 
 agains the passed family and qualifier which fails so null is returned.
 I don't know how frequent it is for users to have families with the same 
 prefix, but those that do have that and that use those families at the same 
 time will have big correctness issues. This is why I mark this as a blocker.

--
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-5875) Process RIT and Master restart may remove an online server considering it as a dead server


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

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

@Devs
{code}
+  // Make sure a -ROOT- location is set.
+  if (!isRootLocation()) return false;
+  // This guarantees that the transition assigning -ROOT- has completed
+  this.assignmentManager.waitForAssignment(HRegionInfo.ROOT_REGIONINFO);
+  assigned++;
{code}
and 
{code}
+  // Wait until META region added to region server onlineRegions. See 
HBASE-5875.
+  enableSSHandWaitForMeta();
+  assigned++;
{code}
This will ensure that we wait for ROOT and META.  Now as HBASE-5918 has gone 
in, if any RS goes down inbetween root and META assignment SSH will also be 
triggered.  
The main intention in this patch is to avoid 
{code}
splitLogAndExpireIfOnline(currentRootServer);

splitLogAndExpireIfOnline(currentMetaServer);
{code}
because the above code in case of ROOT and META in rit was removing the current 
active server thinking it as dead in case the ROOT or META is not yet online on 
RS.

 Process RIT and Master restart may remove an online server considering it as 
 a dead server
 --

 Key: HBASE-5875
 URL: https://issues.apache.org/jira/browse/HBASE-5875
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.1
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 0.94.1

 Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch, 
 HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch


 If on master restart it finds the ROOT/META to be in RIT state, master tries 
 to assign the ROOT region through ProcessRIT.
 Master will trigger the assignment and next will try to verify the Root 
 Region Location.
 Root region location verification is done seeing if the RS has the region in 
 its online list.
 If the master triggered assignment has not yet been completed in RS then the 
 verify root region location will fail.
 Because it failed 
 {code}
 splitLogAndExpireIfOnline(currentRootServer);
 {code}
 we do split log and also remove the server from online server list. Ideally 
 here there is nothing to do in splitlog as no region server was restarted.
 So master, though the server is online, master just invalidates the region 
 server.
 In a special case, if i have only one RS then my cluster will become non 
 operative.

--
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-5875) Process RIT and Master restart may remove an online server considering it as a dead server

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

Zhihong Ted Yu commented on HBASE-5875:
---

@Rajesh:
Hadoop QA is not functioning.
Please report back test suite result.

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

[jira] [Commented] (HBASE-6200) KeyComparator.compareWithoutRow can be wrong when families have the same prefix

2012-06-21 Thread Jieshan Bean (JIRA)


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

Jieshan Bean commented on HBASE-6200:
-

Thank you for your review, Ted. I will update the patch and make the patches 
for other branches tommorow.

 KeyComparator.compareWithoutRow can be wrong when families have the same 
 prefix
 ---

 Key: HBASE-6200
 URL: https://issues.apache.org/jira/browse/HBASE-6200
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6, 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Jieshan Bean
Priority: Blocker
 Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1

 Attachments: HBASE-6200-trunk.patch


 As reported by Desert Rose on IRC and on the ML, {{Result}} has a weird 
 behavior when some families share the same prefix. He posted a link to his 
 code to show how it fails, http://pastebin.com/7TBA1XGh
 Basically {{KeyComparator.compareWithoutRow}} doesn't differentiate families 
 and qualifiers so f:a is said to be bigger than f1:, which is false. Then 
 what happens is that the KVs are returned in the right order from the RS but 
 then doing {{Result.binarySearch}} it uses 
 {{KeyComparator.compareWithoutRow}} which has a different sorting so the end 
 result is undetermined.
 I added some debug and I can see that the data is returned in the right order 
 but {{Arrays.binarySearch}} returned the wrong KV, which is then verified 
 agains the passed family and qualifier which fails so null is returned.
 I don't know how frequent it is for users to have families with the same 
 prefix, but those that do have that and that use those families at the same 
 time will have big correctness issues. This is why I mark this as a blocker.

--
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-6195) Increment data will be lost when the memstore is flushed

2012-06-21 Thread Xing Shi (JIRA)


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

Xing Shi commented on HBASE-6195:
-

@Ted,It's not because of the snapshot, but the store files.
When there are serveral same timestamp storefiles, the get will get the row of 
one of the store files' KeyValue. You can  think that the got KeyValue is 
almost random between the same timestamp storefiles.

How to improve it:
   I make all the timestamps (variable now) of the increment the same value to 
simulate there are high parallelism. Then  the flushcache after 2 increments 
and 5 increments, the code like this just in one threads:
{code}
public void runInOneThread() {
  int count = 0;
  while (count  10) {
Increment inc = new Increment(incRow);
inc.addColumn(family, qualifier, ONE);
count++;
try {
  region.increment(inc, null, true);
  Get get = new Get(Incrementer.incRow);
  get.addColumn(Incrementer.family, Incrementer.qualifier);
  get.setMaxVersions();
  ListKeyValue kvs = this.region.get(get, false);
  for (KeyValue tmpKv : kvs) {
System.out.println(get return :  + 
Bytes.toLong(tmpKv.getBuffer(), tmpKv.getValueOffset()) +  after  + count +  
increment);
  }
  if (count == 2) {
System.out.println(We do flush when execute  + count +  
increments);
region.flushcache();
  } else if (count == 5) {
System.out.println(We do flush when execute  + count +  
increments);
region.flushcache();
  }
} catch (Exception e) {
  e.printStackTrace();
  break;
}
  }
}
{code}
the print out result is :
{code}
get return : 1 after 1 increment
get return : 2 after 2 increment
We do flush when execute 2 increments
2012-06-21 23:16:32,847 DEBUG [Thread-3] regionserver.HRegion(1367): Started 
memstore flush for 
testParallelismIncrementWithMemStoreFlush,,1340291792603.b2a89da7ad8457cab8a1c758c32ed418.,
 current region memstore size 176.0
2012-06-21 23:16:32,848 DEBUG [Thread-3] regionserver.HRegion(1415): Finished 
snapshotting 
testParallelismIncrementWithMemStoreFlush,,1340291792603.b2a89da7ad8457cab8a1c758c32ed418.,
 commencing wait for mvcc, flushsize=176
2012-06-21 23:16:32,849 DEBUG [Thread-3] regionserver.HRegion(1425): Finished 
snapshotting, commencing flushing stores
2012-06-21 23:16:32,859 DEBUG [Thread-3] util.FSUtils(149): Creating 
file:/home/shixing/project/0.94.0-ali-1.0/target/test-data/19e96a0f-6721-4fe7-8ede-f5ca359739a0/TestHRegiontestParallelismIncrementWithMemStoreFlush/testParallelismIncrementWithMemStoreFlush/b2a89da7ad8457cab8a1c758c32ed418/.tmp/4382d83027cc48b6b9a3f411157d0749with
 permission:rwxrwxrwx
2012-06-21 23:16:32,871 DEBUG [Thread-3] hfile.HFileWriterV2(141): Initialized 
with CacheConfig:enabled [cacheDataOnRead=true] [cacheDataOnWrite=false] 
[cacheIndexesOnWrite=false] [cacheBloomsOnWrite=false] 
[cacheEvictOnClose=false] [cacheCompressed=false]
2012-06-21 23:16:32,874 INFO  [Thread-3] regionserver.StoreFile$Writer(995): 
Delete Family Bloom filter type for 
/home/shixing/project/0.94.0-ali-1.0/target/test-data/19e96a0f-6721-4fe7-8ede-f5ca359739a0/TestHRegiontestParallelismIncrementWithMemStoreFlush/testParallelismIncrementWithMemStoreFlush/b2a89da7ad8457cab8a1c758c32ed418/.tmp/4382d83027cc48b6b9a3f411157d0749:
 CompoundBloomFilterWriter
2012-06-21 23:16:32,880 INFO  [Thread-3] regionserver.StoreFile$Writer(1218): 
NO General Bloom and NO DeleteFamily was added to HFile 
(/home/shixing/project/0.94.0-ali-1.0/target/test-data/19e96a0f-6721-4fe7-8ede-f5ca359739a0/TestHRegiontestParallelismIncrementWithMemStoreFlush/testParallelismIncrementWithMemStoreFlush/b2a89da7ad8457cab8a1c758c32ed418/.tmp/4382d83027cc48b6b9a3f411157d0749)
 
2012-06-21 23:16:32,880 INFO  [Thread-3] regionserver.Store(753): Flushed , 
sequenceid=3, memsize=176.0, into tmp file 
/home/shixing/project/0.94.0-ali-1.0/target/test-data/19e96a0f-6721-4fe7-8ede-f5ca359739a0/TestHRegiontestParallelismIncrementWithMemStoreFlush/testParallelismIncrementWithMemStoreFlush/b2a89da7ad8457cab8a1c758c32ed418/.tmp/4382d83027cc48b6b9a3f411157d0749
2012-06-21 23:16:32,905 DEBUG [Thread-3] regionserver.Store(778): Renaming 
flushed file at 
/home/shixing/project/0.94.0-ali-1.0/target/test-data/19e96a0f-6721-4fe7-8ede-f5ca359739a0/TestHRegiontestParallelismIncrementWithMemStoreFlush/testParallelismIncrementWithMemStoreFlush/b2a89da7ad8457cab8a1c758c32ed418/.tmp/4382d83027cc48b6b9a3f411157d0749
 to 
/home/shixing/project/0.94.0-ali-1.0/target/test-data/19e96a0f-6721-4fe7-8ede-f5ca359739a0/TestHRegiontestParallelismIncrementWithMemStoreFlush/testParallelismIncrementWithMemStoreFlush/b2a89da7ad8457cab8a1c758c32ed418/family/4382d83027cc48b6b9a3f411157d0749
2012-06-21 23:16:32,909 INFO  [Thread-3]

[jira] [Commented] (HBASE-5843) Improve HBase MTTR - Mean Time To Recover

2012-06-21 Thread nkeywal (JIRA)


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

nkeywal commented on HBASE-5843:


@ram Thanks for pointing this one out. I will wait for the fix before redoing a 
perf check.
@andrew Yes, there should be no issue. HBASE-5926 modifies the content of 
HBASE-5844, so the merged patch will be smaller. I will have a look.

 Improve HBase MTTR - Mean Time To Recover
 -

 Key: HBASE-5843
 URL: https://issues.apache.org/jira/browse/HBASE-5843
 Project: HBase
  Issue Type: Umbrella
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal

 A part of the approach is described here: 
 https://docs.google.com/document/d/1z03xRoZrIJmg7jsWuyKYl6zNournF_7ZHzdi0qz_B4c/edit
 The ideal target is:
 - failure impact client applications only by an added delay to execute a 
 query, whatever the failure.
 - this delay is always inferior to 1 second.
 We're not going to achieve that immediately...
 Priority will be given to the most frequent issues.
 Short term:
 - software crash
 - standard administrative tasks as stop/start of a cluster.

--
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-6205) Support an option to keep data of dropped table for some time

2012-06-21 Thread Jesse Yates (JIRA)

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

Jesse Yates commented on HBASE-6205:

I don't know if this feature needs to be so far reaching. We already are
getting preservation of the hfiles on delete via HBASE-5547 and as stack says,
HDFS supports a /trash directory with configurable deletion period
(http://hadoop.apache.org/common/docs/r1.0.3/hdfs_design.html#Space+Reclamation).

It would make more sense that when we delete the table that we just store a
list of the current files in the table in a single file added to /trash, so we
know which files to include and which to exclude when recovering the table.
This solves the issues of periodic cleanup, minimizing possible locations of
old hfiles and still lets you reasonably recover a table.

On the other hand, I would argue that this feature is a bit excessive. This
isn't a feature traditional tables support and is a bit excessive IMO. You
should be _very_ careful when dropping tables and not just do things
willy-nilly on production (in particular, you can make sure all production runs
via (possibly generated) scripts so you can validate and not 'accidentally'
drop tables moving from dev to production). The traditional though here is that
you can recover if you are fast enough from the local fs (in this case hdfs
/trash) or from a backup (everyone takes those periodically, right?). Am I
missing something?

+1 on making this configurable.

Support an option to keep data of dropped table for some time
-

Key: HBASE-6205
URL: https://issues.apache.org/jira/browse/HBASE-6205
Project: HBase
Issue Type: New Feature
Affects Versions: 0.94.0, 0.96.0
Reporter: chunhui shen
Assignee: chunhui shen
Fix For: 0.96.0

Attachments: HBASE-6205.patch, HBASE-6205v2.patch,
HBASE-6205v3.patch, HBASE-6205v4.patch, HBASE-6205v5.patch

User may drop table accidentally because of error code or other uncertain
reasons.
Unfortunately, it happens in our environment because one user make a mistake
between production cluster and testing cluster.
So, I just give a suggestion, do we need to support an option to keep data of
dropped table for some time, e.g. 1 day
In the patch:
We make a new dir named .trashtables in the rood dir.
In the DeleteTableHandler, we move files in dropped table's dir to trash
table dir instead of deleting them directly.
And Create new class TrashCleaner which will clean dropped tables if it is
time out with a period check.
Default keep time for dropped tables is 1 day, and check period is 1 hour.

[jira] [Commented] (HBASE-5875) Process RIT and Master restart may remove an online server considering it as a dead server

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

rajeshbabu commented on HBASE-5875:
---

@Ted,
I will run test suite locally and publish test result.

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

[jira] [Commented] (HBASE-6195) Increment data will be lost when the memstore is flushed

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

Zhihong Ted Yu commented on HBASE-6195:
---

Thanks for the analysis.
In reality, we can consider this issue fixed.

Will resolve again if there is no objection.

Increment data will be lost when the memstore is flushed

Key: HBASE-6195
URL: https://issues.apache.org/jira/browse/HBASE-6195
Project: HBase
Issue Type: Bug
Components: regionserver
Reporter: Xing Shi
Assignee: ShiXing
Fix For: 0.96.0, 0.94.1

Attachments: 6195-trunk-V7.patch, 6195.addendum,
HBASE-6195-trunk-V2.patch, HBASE-6195-trunk-V3.patch,
HBASE-6195-trunk-V4.patch, HBASE-6195-trunk-V5.patch,
HBASE-6195-trunk-V6.patch, HBASE-6195-trunk.patch

There are two problems in increment() now:
First:
I see that the timestamp(the variable now) in HRegion's Increment() is
generated before got the rowLock, so when there are multi-thread increment
the same row, although it generate earlier, it may got the lock later.
Because increment just store one version, so till now, the result will still
be right.
When the region is flushing, these increment will read the kv from snapshot
and memstore with whose timestamp is larger, and write it back to memstore.
If the snapshot's timestamp larger than the memstore, the increment will got
the old data and then do the increment, it's wrong.
Secondly:
Also there is a risk in increment. Because it writes the memstore first and
then HLog, so if it writes HLog failed, the client will also read the
incremented value.

[jira] [Commented] (HBASE-6058) Use ZK 3.4 API 'multi' in bulk assignment

2012-06-21 Thread Jesse Yates (JIRA)


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

Jesse Yates commented on HBASE-6058:


bq. supporting both ZK version (with  without multi) would be looking for 
issue imho

Totally agree.

bq. Anyway, I will redo some perfo tests to see where we are now with the 
current implementation

Great! I'd love to see how big of a difference it makes. 

 Use ZK 3.4 API 'multi' in bulk assignment
 -

 Key: HBASE-6058
 URL: https://issues.apache.org/jira/browse/HBASE-6058
 Project: HBase
  Issue Type: Improvement
  Components: master, zookeeper
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor

 We use async API today. This is already much much faster than the sync API. 
 Still, it makes sense to use the 'multi' function: this will decrease the 
 network  zookeeper load at startup/rolling restart.
 On a 500 nodes cluster, we see 3 that 3 seconds are spent on updating ZK per 
 bulk assignment. This should cut it in half (+ the benefits on the network/zk 
 load).

--
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-6253) isLegalTableName API should check for the _acl_ table name


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

Zhihong Ted Yu commented on HBASE-6253:
---

Have you run all security related tests ?
With this patch, how would _acl_ table be created on a clean cluster ?

 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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-5875) Process RIT and Master restart may remove an online server considering it as a dead server

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

Zhihong Ted Yu commented on HBASE-5875:
---

Patch looks good.

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

[jira] [Resolved] (HBASE-6212) Allow WAL to be disabled perTable.

2012-06-21 Thread Amitanand Aiyer (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amitanand Aiyer resolved HBASE-6212.


Resolution: Fixed
  Assignee: Amitanand Aiyer

 Allow WAL to be disabled perTable.
 --

 Key: HBASE-6212
 URL: https://issues.apache.org/jira/browse/HBASE-6212
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.89-fb
Reporter: Amitanand Aiyer
Assignee: Amitanand Aiyer
Priority: Minor

 There are use cases which want to get better performance by turning off 
 WALEdits. 
 At the server side, the config setting currently allows us to turn on or turn 
 off the WAL edits. But, the setting applies to all the tables.
 We should be able to control this setting at a per table level.

--
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] [Updated] (HBASE-6212) [89-fb] Allow WAL to be disabled perTable.


 [ 
https://issues.apache.org/jira/browse/HBASE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Ted Yu updated HBASE-6212:
--

Summary: [89-fb] Allow WAL to be disabled perTable.  (was: Allow WAL to be 
disabled perTable.)

 [89-fb] Allow WAL to be disabled perTable.
 --

 Key: HBASE-6212
 URL: https://issues.apache.org/jira/browse/HBASE-6212
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.89-fb
Reporter: Amitanand Aiyer
Assignee: Amitanand Aiyer
Priority: Minor

 There are use cases which want to get better performance by turning off 
 WALEdits. 
 At the server side, the config setting currently allows us to turn on or turn 
 off the WAL edits. But, the setting applies to all the tables.
 We should be able to control this setting at a per table level.

--
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-6212) Allow WAL to be disabled perTable.


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

Zhihong Ted Yu commented on HBASE-6212:
---

@Amit:
https://phabricator.fb.com/D495277 isn't accessible outside FB.
Can you attach our patch here so that it can be ported to trunk ?

Thanks

 Allow WAL to be disabled perTable.
 --

 Key: HBASE-6212
 URL: https://issues.apache.org/jira/browse/HBASE-6212
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.89-fb
Reporter: Amitanand Aiyer
Assignee: Amitanand Aiyer
Priority: Minor

 There are use cases which want to get better performance by turning off 
 WALEdits. 
 At the server side, the config setting currently allows us to turn on or turn 
 off the WAL edits. But, the setting applies to all the tables.
 We should be able to control this setting at a per table level.

--
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-6253) isLegalTableName API should check for the _acl_ table name


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

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

@Ted
{code}
if (!MetaReader.tableExists(master.getCatalogTracker(), 
ACL_TABLE_NAME_STR)) {
  master.createTable(ACL_TABLEDESC, null);
}
{code}
The acl creation goes thro' master.createTable. So it should be ok.

 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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-6116) Allow parallel HDFS writes for HLogs.


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

Andrew Purtell commented on HBASE-6116:
---

@Lars, sure. Parallel vs. not only I presume, or are you interested in the 
difference with durable sync enabled also?

 Allow parallel HDFS writes for HLogs.
 -

 Key: HBASE-6116
 URL: https://issues.apache.org/jira/browse/HBASE-6116
 Project: HBase
  Issue Type: Bug
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
 Attachments: 6116-v1.txt


 In HDFS-1783 I adapted Dhrubas changes to be used in Hadoop trunk.
 This issue will include the necessary reflection changes to optionally enable 
 this for the WALs in HBase.

--
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-6253) isLegalTableName API should check for the _acl_ table name


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

Gopinathan A commented on HBASE-6253:
-

Sorry Ted.. I have not run the Security related tests. Your right acl table 
creation will be failed in this case :(
My main intention to avoid user to perform disable/drop acl table.

I think we can set setMetaFlags as true in HTableDescriptor constructor for 
_acl_ table also (like ROOT  META). This will solve the table creation problem.


 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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-6253) isLegalTableName API should check for the _acl_ table name


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

Andrew Purtell commented on HBASE-6253:
---

How can a user drop the ACL table if they are not authorized to do it?

The string _acl_ as table name has no meaning unless the AccessController is 
installed. So -1 a core change that encodes it.

 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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] [Comment Edited] (HBASE-6253) isLegalTableName API should check for the _acl_ table name


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

Andrew Purtell edited comment on HBASE-6253 at 6/21/12 6:03 PM:


How can a user drop the ACL table if they are not authorized to do it?

The string {{_ acl _}} as table name has no special meaning unless the 
AccessController is installed. So -1 a core change that encodes it.

Edit: Fix formatting (kind of)

  was (Author: apurtell):
How can a user drop the ACL table if they are not authorized to do it?

The string _acl_ as table name has no meaning unless the AccessController is 
installed. So -1 a core change that encodes it.
  
 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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] [Created] (HBASE-6254) deletes w/ many column qualifiers overwhelm Region Server

2012-06-21 Thread Ted Tuttle (JIRA)

Ted Tuttle created HBASE-6254:
-

 Summary: deletes w/ many column qualifiers overwhelm Region Server
 Key: HBASE-6254
 URL: https://issues.apache.org/jira/browse/HBASE-6254
 Project: HBase
  Issue Type: Bug
  Components: performance, regionserver
Affects Versions: 0.94.0
 Environment: 5 node Cent OS + 1 master, v0.94 on cdh3u3
Reporter: Ted Tuttle


Execution of Deletes constructed with thousands of calls to 
Delete.deleteColumn(family, qualifier) are very expensive and slow.

On our (quiet) cluster, a Delete w/ 20k qualifiers took about 13s to complete 
(as measured by client).

When 10 such Deletes were sent to the cluster via HTable.delete(ListDelete), 
one of RegionServers ended up w/ 5 of the requests and became 100% CPU utilized 
for about 1 hour.

This lead to the client timing out after 20min (2min x 10 retries).  In one 
case, the client was able to fill the RPC callqueue and received the following 
error:

  Failed all from region=region,hostname=host, port=port 
java.util.concurrent.ExecutionException: java.io.IOException: Call queue is 
full, is ipc.server.max.callqueue.size too small?

Based on feedback (http://search-hadoop.com/m/yITsc1WcDWP), I switched to 
Delete.deleteColumn(family, qual, timestamp) where timestamp came from KeyValue 
retrieved from scan based on domain objects.  This version of the delete ran in 
about 500ms.

User group thread titled RS unresponsive after series of deletes has related 
logs and stacktraces.  

Link to thread: http://search-hadoop.com/m/RmIyr1WcDWP

--
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-6253) isLegalTableName API should check for the _acl_ table name


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

Gopinathan A commented on HBASE-6253:
-

I felt even authorized user should not able to perform disable/drop operation.

 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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-6253) isLegalTableName API should check for the _acl_ table name


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

Andrew Purtell commented on HBASE-6253:
---

-1 any core code change here. Protect against the drop in the AccessController.

 isLegalTableName API should check for the _acl_ table name
 --

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Gopinathan A
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

--
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] [Updated] (HBASE-6252) TABLE ADMIN should be allowed to relocate regions


 [ 
https://issues.apache.org/jira/browse/HBASE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6252:
--

Summary: TABLE ADMIN should be allowed to relocate regions  (was: TABLE 
ADMIN should be allowed to do assign, unassign  move as these are table level 
operations.)

 TABLE ADMIN should be allowed to relocate regions
 -

 Key: HBASE-6252
 URL: https://issues.apache.org/jira/browse/HBASE-6252
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
 Attachments: HBASE-6252.patch




--
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] [Updated] (HBASE-6252) TABLE ADMIN should be allowed to relocate regions


 [ 
https://issues.apache.org/jira/browse/HBASE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6252:
--

   Resolution: Fixed
Fix Version/s: 0.94.1
   0.96.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Committed to trunk and 0.94 branch. TestAccessController passes locally. Thanks 
for the patch Laxman!

 TABLE ADMIN should be allowed to relocate regions
 -

 Key: HBASE-6252
 URL: https://issues.apache.org/jira/browse/HBASE-6252
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6252.patch




--
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-6249) Apply ACLs to new bulk load hooks


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

Andrew Purtell commented on HBASE-6249:
---

We will need to enumerate the list of column families submitted for bulk 
loading and insure the requester has WRITE permission for all families in the 
request.

 Apply ACLs to new bulk load hooks
 -

 Key: HBASE-6249
 URL: https://issues.apache.org/jira/browse/HBASE-6249
 Project: HBase
  Issue Type: Sub-task
Reporter: Andrew Purtell

 HBASE-6224 adds coprocessor hooks for bulk loading. This should require table 
 WRITE permission.

--
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] [Updated] (HBASE-6254) deletes w/ many column qualifiers overwhelm Region Server


 [ 
https://issues.apache.org/jira/browse/HBASE-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Ted Yu updated HBASE-6254:
--

Description: 
Execution of Deletes constructed with thousands of calls to 
Delete.deleteColumn(family, qualifier) are very expensive and slow.

On our (quiet) cluster, a Delete w/ 20k qualifiers took about 13s to complete 
(as measured by client).

When 10 such Deletes were sent to the cluster via HTable.delete(ListDelete), 
one of RegionServers ended up w/ 5 of the requests and became 100% CPU utilized 
for about 1 hour.

This lead to the client timing out after 20min (2min x 10 retries).  In one 
case, the client was able to fill the RPC callqueue and received the following 
error:
{code}
  Failed all from region=region,hostname=host, port=port 
java.util.concurrent.ExecutionException: java.io.IOException: Call queue is 
full, is ipc.server.max.callqueue.size too small?
{code}
Based on feedback (http://search-hadoop.com/m/yITsc1WcDWP), I switched to 
Delete.deleteColumn(family, qual, timestamp) where timestamp came from KeyValue 
retrieved from scan based on domain objects.  This version of the delete ran in 
about 500ms.

User group thread titled RS unresponsive after series of deletes has related 
logs and stacktraces.  

Link to thread: http://search-hadoop.com/m/RmIyr1WcDWP

Here is the stack dump of region server: http://pastebin.com/8y5x4xU7

  was:
Execution of Deletes constructed with thousands of calls to 
Delete.deleteColumn(family, qualifier) are very expensive and slow.

On our (quiet) cluster, a Delete w/ 20k qualifiers took about 13s to complete 
(as measured by client).

When 10 such Deletes were sent to the cluster via HTable.delete(ListDelete), 
one of RegionServers ended up w/ 5 of the requests and became 100% CPU utilized 
for about 1 hour.

This lead to the client timing out after 20min (2min x 10 retries).  In one 
case, the client was able to fill the RPC callqueue and received the following 
error:

  Failed all from region=region,hostname=host, port=port 
java.util.concurrent.ExecutionException: java.io.IOException: Call queue is 
full, is ipc.server.max.callqueue.size too small?

Based on feedback (http://search-hadoop.com/m/yITsc1WcDWP), I switched to 
Delete.deleteColumn(family, qual, timestamp) where timestamp came from KeyValue 
retrieved from scan based on domain objects.  This version of the delete ran in 
about 500ms.

User group thread titled RS unresponsive after series of deletes has related 
logs and stacktraces.  

Link to thread: http://search-hadoop.com/m/RmIyr1WcDWP


 deletes w/ many column qualifiers overwhelm Region Server
 -

 Key: HBASE-6254
 URL: https://issues.apache.org/jira/browse/HBASE-6254
 Project: HBase
  Issue Type: Bug
  Components: performance, regionserver
Affects Versions: 0.94.0
 Environment: 5 node Cent OS + 1 master, v0.94 on cdh3u3
Reporter: Ted Tuttle

 Execution of Deletes constructed with thousands of calls to 
 Delete.deleteColumn(family, qualifier) are very expensive and slow.
 On our (quiet) cluster, a Delete w/ 20k qualifiers took about 13s to complete 
 (as measured by client).
 When 10 such Deletes were sent to the cluster via 
 HTable.delete(ListDelete), one of RegionServers ended up w/ 5 of the 
 requests and became 100% CPU utilized for about 1 hour.
 This lead to the client timing out after 20min (2min x 10 retries).  In one 
 case, the client was able to fill the RPC callqueue and received the 
 following error:
 {code}
   Failed all from region=region,hostname=host, port=port 
 java.util.concurrent.ExecutionException: java.io.IOException: Call queue is 
 full, is ipc.server.max.callqueue.size too small?
 {code}
 Based on feedback (http://search-hadoop.com/m/yITsc1WcDWP), I switched to 
 Delete.deleteColumn(family, qual, timestamp) where timestamp came from 
 KeyValue retrieved from scan based on domain objects.  This version of the 
 delete ran in about 500ms.
 User group thread titled RS unresponsive after series of deletes has 
 related logs and stacktraces.  
 Link to thread: http://search-hadoop.com/m/RmIyr1WcDWP
 Here is the stack dump of region server: http://pastebin.com/8y5x4xU7

--
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-6254) deletes w/ many column qualifiers overwhelm Region Server


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

Zhihong Ted Yu commented on HBASE-6254:
---

From HRegion, prepareDeleteTimestamps() performs one get operation per column 
qualifier:
{code}
  for (KeyValue kv: kvs) {
//  Check if time is LATEST, change to time of most recent addition if 
so
//  This is expensive.
if (kv.isLatestTimestamp()  kv.isDeleteType()) {
...
  ListKeyValue result = get(get, false);
{code}
We perform get() for each kv whose time is LATEST.
This explains the unresponsiveness.

I think we can group some configurable number of qualifiers in each get and 
perform classification on result.
This way we can reduce the number of times HRegion$RegionScannerImpl.next() is 
called.

 deletes w/ many column qualifiers overwhelm Region Server
 -

 Key: HBASE-6254
 URL: https://issues.apache.org/jira/browse/HBASE-6254
 Project: HBase
  Issue Type: Bug
  Components: performance, regionserver
Affects Versions: 0.94.0
 Environment: 5 node Cent OS + 1 master, v0.94 on cdh3u3
Reporter: Ted Tuttle

 Execution of Deletes constructed with thousands of calls to 
 Delete.deleteColumn(family, qualifier) are very expensive and slow.
 On our (quiet) cluster, a Delete w/ 20k qualifiers took about 13s to complete 
 (as measured by client).
 When 10 such Deletes were sent to the cluster via 
 HTable.delete(ListDelete), one of RegionServers ended up w/ 5 of the 
 requests and became 100% CPU utilized for about 1 hour.
 This lead to the client timing out after 20min (2min x 10 retries).  In one 
 case, the client was able to fill the RPC callqueue and received the 
 following error:
 {code}
   Failed all from region=region,hostname=host, port=port 
 java.util.concurrent.ExecutionException: java.io.IOException: Call queue is 
 full, is ipc.server.max.callqueue.size too small?
 {code}
 Based on feedback (http://search-hadoop.com/m/yITsc1WcDWP), I switched to 
 Delete.deleteColumn(family, qual, timestamp) where timestamp came from 
 KeyValue retrieved from scan based on domain objects.  This version of the 
 delete ran in about 500ms.
 User group thread titled RS unresponsive after series of deletes has 
 related logs and stacktraces.  
 Link to thread: http://search-hadoop.com/m/RmIyr1WcDWP
 Here is the stack dump of region server: http://pastebin.com/8y5x4xU7

--
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-6195) Increment data will be lost when the memstore is flushed


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

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

@Xing
{code}
  // Negate this comparison so later edits show up first
  return -Longs.compare(left.getMemstoreTS(), right.getMemstoreTS());
{code}
You mean this gives 0 as the memStoreTS is zero, right?

 Increment data will be lost when the memstore is flushed
 

 Key: HBASE-6195
 URL: https://issues.apache.org/jira/browse/HBASE-6195
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Reporter: Xing Shi
Assignee: ShiXing
 Fix For: 0.96.0, 0.94.1

 Attachments: 6195-trunk-V7.patch, 6195.addendum, 
 HBASE-6195-trunk-V2.patch, HBASE-6195-trunk-V3.patch, 
 HBASE-6195-trunk-V4.patch, HBASE-6195-trunk-V5.patch, 
 HBASE-6195-trunk-V6.patch, HBASE-6195-trunk.patch


 There are two problems in increment() now:
 First:
 I see that the timestamp(the variable now) in HRegion's Increment() is 
 generated before got the rowLock, so when there are multi-thread increment 
 the same row, although it generate earlier, it may got the lock later. 
 Because increment just store one version, so till now, the result will still 
 be right.
 When the region is flushing, these increment will read the kv from snapshot 
 and memstore with whose timestamp is larger, and write it back to memstore. 
 If the snapshot's timestamp larger than the memstore, the increment will got 
 the old data and then do the increment, it's wrong.
 Secondly:
 Also there is a risk in increment. Because it writes the memstore first and 
 then HLog, so if it writes HLog failed, the client will also read the 
 incremented value.

--
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-5875) Process RIT and Master restart may remove an online server considering it as a dead server

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

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

I will integrate this tomorrow if there are no objections/comments.

Process RIT and Master restart may remove an online server considering it as
a dead server
--

Attachments: HBASE-5875.patch, HBASE-5875_0.94.patch,
HBASE-5875_0.94_1.patch, HBASE-5875_trunk.patch, HBASE-5875v2.patch

[jira] [Commented] (HBASE-6254) deletes w/ many column qualifiers overwhelm Region Server


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

Zhihong Ted Yu commented on HBASE-6254:
---

Since KeyValue implements HeapSize, we can keep adding column qualifiers until 
we reach configurable threshold.
After get(get, false) returns, we can parse out the column qualifiers from 
result.

 deletes w/ many column qualifiers overwhelm Region Server
 -

 Key: HBASE-6254
 URL: https://issues.apache.org/jira/browse/HBASE-6254
 Project: HBase
  Issue Type: Bug
  Components: performance, regionserver
Affects Versions: 0.94.0
 Environment: 5 node Cent OS + 1 master, v0.94 on cdh3u3
Reporter: Ted Tuttle

 Execution of Deletes constructed with thousands of calls to 
 Delete.deleteColumn(family, qualifier) are very expensive and slow.
 On our (quiet) cluster, a Delete w/ 20k qualifiers took about 13s to complete 
 (as measured by client).
 When 10 such Deletes were sent to the cluster via 
 HTable.delete(ListDelete), one of RegionServers ended up w/ 5 of the 
 requests and became 100% CPU utilized for about 1 hour.
 This lead to the client timing out after 20min (2min x 10 retries).  In one 
 case, the client was able to fill the RPC callqueue and received the 
 following error:
 {code}
   Failed all from region=region,hostname=host, port=port 
 java.util.concurrent.ExecutionException: java.io.IOException: Call queue is 
 full, is ipc.server.max.callqueue.size too small?
 {code}
 Based on feedback (http://search-hadoop.com/m/yITsc1WcDWP), I switched to 
 Delete.deleteColumn(family, qual, timestamp) where timestamp came from 
 KeyValue retrieved from scan based on domain objects.  This version of the 
 delete ran in about 500ms.
 User group thread titled RS unresponsive after series of deletes has 
 related logs and stacktraces.  
 Link to thread: http://search-hadoop.com/m/RmIyr1WcDWP
 Here is the stack dump of region server: http://pastebin.com/8y5x4xU7

--
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] [Updated] (HBASE-5206) Port HBASE-5155 to 0.92, 0.94, and TRUNK


 [ 
https://issues.apache.org/jira/browse/HBASE-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-5206:
--

Fix Version/s: (was: 0.92.2)

 Port HBASE-5155 to 0.92, 0.94, and TRUNK
 

 Key: HBASE-5206
 URL: https://issues.apache.org/jira/browse/HBASE-5206
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.2, 0.94.0, 0.96.0
Reporter: Zhihong Ted Yu
Assignee: Ashutosh Jindal
 Fix For: 0.94.0, 0.96.0

 Attachments: 5206_92_1.patch, 5206_92_latest_1.patch, 
 5206_92_latest_2.patch, 5206_92_latest_3.patch, 5206_trunk_1.patch, 
 5206_trunk_latest_1.patch, 5206_trunk_latest_2.patch, 
 5206_trunk_latest_3.patch


 This JIRA ports HBASE-5155 (ServerShutDownHandler And Disable/Delete should 
 not happen parallely leading to recreation of regions that were deleted) to 
 0.92 and TRUNK

--
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-6229) AM.assign() should not set table state to ENABLED directly.


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

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

@Ted
This change is not applicable in 0.92.  As HBASE-5206 is not committed to 0.92

 AM.assign() should not set table state to ENABLED directly.
 ---

 Key: HBASE-6229
 URL: https://issues.apache.org/jira/browse/HBASE-6229
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.2, 0.94.1
Reporter: rajeshbabu
Assignee: rajeshbabu
 Fix For: 0.96.0, 0.94.1, 0.92.3

 Attachments: 6229_trunk_2.patch, HBASE-6229_94.patch, 
 HBASE-6229_94_1.patch, HBASE-6229_94_2.patch, HBASE-6229_trunk.patch, 
 HBASE-6229_trunk_1.patch


 In case of assign from EnableTableHandler table state is ENABLING. Any how 
 EnableTableHandler will set ENABLED after assigning all the the table 
 regions. If we try to set to ENABLED directly then client api may think 
 ENABLE table is completed. When we have a case like all the regions are added 
 directly into META and we call assignRegion then we need to make the table 
 ENABLED.  Hence in such case the table will not be in ENABLING or ENABLED 
 state.

--
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-6116) Allow parallel HDFS writes for HLogs.


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

Lars Hofhansl commented on HBASE-6116:
--

Any datapoint is helpful. :)
Parallel vs. not will be most interesting.
Durable sync on EC2 might be interesting as it might be slow on EC2.

Whatever time permits... I know you're busy. Thanks so much for spending time 
on this.
We'll be testing too when I'm back in the US.


 Allow parallel HDFS writes for HLogs.
 -

 Key: HBASE-6116
 URL: https://issues.apache.org/jira/browse/HBASE-6116
 Project: HBase
  Issue Type: Bug
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
 Attachments: 6116-v1.txt


 In HDFS-1783 I adapted Dhrubas changes to be used in Hadoop trunk.
 This issue will include the necessary reflection changes to optionally enable 
 this for the WALs in HBase.

--
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-6252) TABLE ADMIN should be allowed to relocate regions


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

Hudson commented on HBASE-6252:
---

Integrated in HBase-TRUNK #3054 (See 
[https://builds.apache.org/job/HBase-TRUNK/3054/])
HBASE-6252. TABLE ADMIN should be allowed to relocate regions (Laxman) 
(Revision 1352644)

 Result = FAILURE
apurtell : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java


 TABLE ADMIN should be allowed to relocate regions
 -

 Key: HBASE-6252
 URL: https://issues.apache.org/jira/browse/HBASE-6252
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6252.patch




--
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-5547) Don't delete HFiles when in backup mode

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

Lars Hofhansl commented on HBASE-5547:
--

Rethinking the whole previous discussion... There is another thought:
Simply never delete HFile, but instead always move them to an archive location
instead. Then have an aynchronous thread using a pluggable policy to delete (or
not) the HFiles from the archive location.

That would completely sidestep any ZK synchronization issues. The removal of
the archived files is not time critical and does not need to be synchronous on
any path.
Disadvantage is that a single thread in the master would have to do the cleanup
(right?)

Don't delete HFiles when in backup mode
-

Key: HBASE-5547
URL: https://issues.apache.org/jira/browse/HBASE-5547
Project: HBase
Issue Type: New Feature
Reporter: Lars Hofhansl
Assignee: Jesse Yates
Attachments: hbase-5447-v8.patch, hbase-5447-v8.patch,
java_HBASE-5547_v4.patch, java_HBASE-5547_v5.patch, java_HBASE-5547_v6.patch,
java_HBASE-5547_v7.patch

This came up in a discussion I had with Stack.
It would be nice if HBase could be notified that a backup is in progress (via
a znode for example) and in that case either:
1. rename HFiles to be delete to file.bck
2. rename the HFiles into a special directory
3. rename them to a general trash directory (which would not need to be tied
to backup mode).
That way it should be able to get a consistent backup based on HFiles (HDFS
snapshots or hard links would be better options here, but we do not have
those).
#1 makes cleanup a bit harder.

[jira] [Commented] (HBASE-5547) Don't delete HFiles when in backup mode

2012-06-21 Thread Jesse Yates (JIRA)

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

Jesse Yates commented on HBASE-5547:

@Lars: I was thinking that we should have this cleanup thread anyways (similar
to the old logs). I could see moving the ZK stuff to just be monitored from
that thread for what files it should delete or not (less a timeout on file
movement). This would follow the same chaining that we are doing for the
.oldlogs directory.

I don't see it as all that bad to have an async thread from the master that
does the cleanup (and we could remove the synchronous requirement in zk).

I'm +1 on this - its not significantly more overhead than we have already and
notably less overhead than the current implementation. Only downside is that
the current implementation is pretty solid (been using it in my testing for
snapshots and have yet to have a problem).

Don't delete HFiles when in backup mode
-

[jira] [Commented] (HBASE-6252) TABLE ADMIN should be allowed to relocate regions


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

Hudson commented on HBASE-6252:
---

Integrated in HBase-0.94 #269 (See 
[https://builds.apache.org/job/HBase-0.94/269/])
HBASE-6252. TABLE ADMIN should be allowed to relocate regions (Laxman) 
(Revision 1352645)

 Result = SUCCESS
apurtell : 
Files : 
* 
/hbase/branches/0.94/security/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* 
/hbase/branches/0.94/security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java


 TABLE ADMIN should be allowed to relocate regions
 -

 Key: HBASE-6252
 URL: https://issues.apache.org/jira/browse/HBASE-6252
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6252.patch




--
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] [Updated] (HBASE-5953) Expose the current state of the balancerSwitch

2012-06-21 Thread Gregory Chanan (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gregory Chanan updated HBASE-5953:
--

Attachment: HBASE-5953-v2.patch

* Attached HBASE-5953-v2.patch *

Incorporate Anoop's suggestion.

 Expose the current state of the balancerSwitch
 --

 Key: HBASE-5953
 URL: https://issues.apache.org/jira/browse/HBASE-5953
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 0.96.0
Reporter: David S. Wang
Assignee: Gregory Chanan
Priority: Minor
 Attachments: HBASE-5953-v2.patch, HBASE-5953.patch


 The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way 
 that it is impossible to retrieve its value without changing it:
 /**
 Turn the load balancer on or off.
 @param b If true, enable balancer. If false, disable balancer.
 @return Previous balancer value
 */
 public boolean balanceSwitch(final boolean b);
 It would be nice to have a way to just get the current state.

--
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] [Assigned] (HBASE-6243) New UI should space detailed latency columns equally


 [ 
https://issues.apache.org/jira/browse/HBASE-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark reassigned HBASE-6243:


Assignee: Elliott Clark

 New UI should space detailed latency columns equally
 

 Key: HBASE-6243
 URL: https://issues.apache.org/jira/browse/HBASE-6243
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor

 Spacing between the columns of the detailed latencies tab should be roughly 
 equal. Round latencies to two digits right of decimal point.

--
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] [Updated] (HBASE-6243) New UI should space detailed latency columns equally


 [ 
https://issues.apache.org/jira/browse/HBASE-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark updated HBASE-6243:
-

Attachment: HBASE-6243-0.patch

Quick patch for latency formatting.

 New UI should space detailed latency columns equally
 

 Key: HBASE-6243
 URL: https://issues.apache.org/jira/browse/HBASE-6243
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-6243-0.patch


 Spacing between the columns of the detailed latencies tab should be roughly 
 equal. Round latencies to two digits right of decimal point.

--
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] [Updated] (HBASE-6243) New UI should space detailed latency columns equally


 [ 
https://issues.apache.org/jira/browse/HBASE-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark updated HBASE-6243:
-

Status: Patch Available  (was: Open)

 New UI should space detailed latency columns equally
 

 Key: HBASE-6243
 URL: https://issues.apache.org/jira/browse/HBASE-6243
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-6243-0.patch


 Spacing between the columns of the detailed latencies tab should be roughly 
 equal. Round latencies to two digits right of decimal point.

--
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] [Updated] (HBASE-5953) Expose the current state of the balancerSwitch


 [ 
https://issues.apache.org/jira/browse/HBASE-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Ted Yu updated HBASE-5953:
--

Attachment: 5953-v2.patch

Patch v2 with formatting.

Will integrate after test suite completes.

 Expose the current state of the balancerSwitch
 --

 Key: HBASE-5953
 URL: https://issues.apache.org/jira/browse/HBASE-5953
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 0.96.0
Reporter: David S. Wang
Assignee: Gregory Chanan
Priority: Minor
 Attachments: 5953-v2.patch, HBASE-5953-v2.patch, HBASE-5953.patch


 The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way 
 that it is impossible to retrieve its value without changing it:
 /**
 Turn the load balancer on or off.
 @param b If true, enable balancer. If false, disable balancer.
 @return Previous balancer value
 */
 public boolean balanceSwitch(final boolean b);
 It would be nice to have a way to just get the current state.

--
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] [Updated] (HBASE-5953) Expose the current state of the balancerSwitch


 [ 
https://issues.apache.org/jira/browse/HBASE-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Ted Yu updated HBASE-5953:
--

Fix Version/s: 0.96.0
 Hadoop Flags: Reviewed

 Expose the current state of the balancerSwitch
 --

 Key: HBASE-5953
 URL: https://issues.apache.org/jira/browse/HBASE-5953
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 0.96.0
Reporter: David S. Wang
Assignee: Gregory Chanan
Priority: Minor
 Fix For: 0.96.0

 Attachments: 5953-v2.patch, HBASE-5953-v2.patch, HBASE-5953.patch


 The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way 
 that it is impossible to retrieve its value without changing it:
 /**
 Turn the load balancer on or off.
 @param b If true, enable balancer. If false, disable balancer.
 @return Previous balancer value
 */
 public boolean balanceSwitch(final boolean b);
 It would be nice to have a way to just get the current state.

--
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] [Updated] (HBASE-6211) Put latencies in jmx


 [ 
https://issues.apache.org/jira/browse/HBASE-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark updated HBASE-6211:
-

Resolution: Fixed
Status: Resolved  (was: Patch Available)

 Put latencies in jmx
 

 Key: HBASE-6211
 URL: https://issues.apache.org/jira/browse/HBASE-6211
 Project: HBase
  Issue Type: Bug
  Components: metrics, monitoring
 Environment: RegionServerMetrics pushes latency histograms to hadoop 
 metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6211-0.patch, HBASE-6211-1.patch, 
 HBASE-6211-2.patch




--
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] [Updated] (HBASE-6242) New UI should color task list entries


 [ 
https://issues.apache.org/jira/browse/HBASE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark updated HBASE-6242:
-

Attachment: HBASE-6242-0.patch

Added colors for aborted and completed tasks.

 New UI should color task list entries
 -

 Key: HBASE-6242
 URL: https://issues.apache.org/jira/browse/HBASE-6242
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Priority: Minor
 Attachments: HBASE-6242-0.patch


 The old UI changed the background color of tasklist entries according to 
 their final status: green if successful, yellow if aborted, red if failed. 
 Bring this back in the new UI.

--
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] [Updated] (HBASE-6242) New UI should color task list entries


 [ 
https://issues.apache.org/jira/browse/HBASE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark updated HBASE-6242:
-

Status: Patch Available  (was: Open)

 New UI should color task list entries
 -

 Key: HBASE-6242
 URL: https://issues.apache.org/jira/browse/HBASE-6242
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-6242-0.patch


 The old UI changed the background color of tasklist entries according to 
 their final status: green if successful, yellow if aborted, red if failed. 
 Bring this back in the new UI.

--
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] [Assigned] (HBASE-6242) New UI should color task list entries


 [ 
https://issues.apache.org/jira/browse/HBASE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark reassigned HBASE-6242:


Assignee: Elliott Clark

 New UI should color task list entries
 -

 Key: HBASE-6242
 URL: https://issues.apache.org/jira/browse/HBASE-6242
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-6242-0.patch


 The old UI changed the background color of tasklist entries according to 
 their final status: green if successful, yellow if aborted, red if failed. 
 Bring this back in the new UI.

--
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] [Updated] (HBASE-5539) asynchbase PerformanceEvaluation


 [ 
https://issues.apache.org/jira/browse/HBASE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Ted Yu updated HBASE-5539:
--

Attachment: 5539-asynchbase-PerformanceEvaluation-v2.txt

Benoit's patch rebased on trunk.
Also updated asynchbase version to 1.3.1

 asynchbase PerformanceEvaluation
 

 Key: HBASE-5539
 URL: https://issues.apache.org/jira/browse/HBASE-5539
 Project: HBase
  Issue Type: New Feature
  Components: performance
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
  Labels: benchmark
 Attachments: 0001-asynchbase-PerformanceEvaluation.patch, 
 0001-asynchbase-PerformanceEvaluation.patch, 
 5539-asynchbase-PerformanceEvaluation-v2.txt


 I plugged [asynchbase|https://github.com/stumbleupon/asynchbase] into 
 {{PerformanceEvaluation}}.  This enables testing asynchbase from 
 {{PerformanceEvaluation}} and comparing its performance to {{HTable}}.  Also 
 asynchbase doesn't come with any benchmark, so it was good that I was able to 
 plug it into {{PerformanceEvaluation}} relatively easily.
 I am in the processing of collecting results on a dev cluster running 0.92.1 
 and will publish them once they're ready.

--
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] [Updated] (HBASE-6242) New UI should color task list entries


 [ 
https://issues.apache.org/jira/browse/HBASE-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6242:
--

   Resolution: Fixed
Fix Version/s: 0.96.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Committed to trunk. Confirmed successful local build. Thanks for the patch 
Elliott!

 New UI should color task list entries
 -

 Key: HBASE-6242
 URL: https://issues.apache.org/jira/browse/HBASE-6242
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-6242-0.patch


 The old UI changed the background color of tasklist entries according to 
 their final status: green if successful, yellow if aborted, red if failed. 
 Bring this back in the new UI.

--
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] [Updated] (HBASE-6243) New UI should space detailed latency columns equally


 [ 
https://issues.apache.org/jira/browse/HBASE-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6243:
--

   Resolution: Fixed
Fix Version/s: 0.96.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

I think this is good enough for now, this is all we did before. Issue can be 
reopened if another similar consideration arises. 

Committed to trunk. Confirmed successful local build. Thanks for the patch 
Elliott!

 New UI should space detailed latency columns equally
 

 Key: HBASE-6243
 URL: https://issues.apache.org/jira/browse/HBASE-6243
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-6243-0.patch


 Spacing between the columns of the detailed latencies tab should be roughly 
 equal. Round latencies to two digits right of decimal point.

--
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] [Created] (HBASE-6255) Right align hbase logo in web ui

Elliott Clark created HBASE-6255:


 Summary: Right align hbase logo in web ui
 Key: HBASE-6255
 URL: https://issues.apache.org/jira/browse/HBASE-6255
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Trivial


Make the Hbase logo float right to keep the right edge in the ui clean.

--
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] [Updated] (HBASE-6255) Right align hbase logo in web ui


 [ 
https://issues.apache.org/jira/browse/HBASE-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6255:
--

  Component/s: regionserver
   master
Affects Version/s: 0.96.0

 Right align hbase logo in web ui
 

 Key: HBASE-6255
 URL: https://issues.apache.org/jira/browse/HBASE-6255
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Trivial
  Labels: noob

 Make the Hbase logo float right to keep the right edge in the ui clean.

--
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] [Updated] (HBASE-6255) Right align hbase logo in web ui


 [ 
https://issues.apache.org/jira/browse/HBASE-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliott Clark updated HBASE-6255:
-

Labels: noob  (was: )

 Right align hbase logo in web ui
 

 Key: HBASE-6255
 URL: https://issues.apache.org/jira/browse/HBASE-6255
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Trivial
  Labels: noob

 Make the Hbase logo float right to keep the right edge in the ui clean.

--
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-5953) Expose the current state of the balancerSwitch


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

Zhihong Ted Yu commented on HBASE-5953:
---

No issue turned up from test suite run.

Integrated to trunk.

Thanks for the patch Gregory.

Thanks for the review Anoop.

 Expose the current state of the balancerSwitch
 --

 Key: HBASE-5953
 URL: https://issues.apache.org/jira/browse/HBASE-5953
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 0.96.0
Reporter: David S. Wang
Assignee: Gregory Chanan
Priority: Minor
 Fix For: 0.96.0

 Attachments: 5953-v2.patch, HBASE-5953-v2.patch, HBASE-5953.patch


 The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way 
 that it is impossible to retrieve its value without changing it:
 /**
 Turn the load balancer on or off.
 @param b If true, enable balancer. If false, disable balancer.
 @return Previous balancer value
 */
 public boolean balanceSwitch(final boolean b);
 It would be nice to have a way to just get the current state.

--
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-5953) Expose the current state of the balancerSwitch

2012-06-21 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-5953:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12532936/5953-v2.patch
  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 patch.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/2212//console

This message is automatically generated.

 Expose the current state of the balancerSwitch
 --

 Key: HBASE-5953
 URL: https://issues.apache.org/jira/browse/HBASE-5953
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 0.96.0
Reporter: David S. Wang
Assignee: Gregory Chanan
Priority: Minor
 Fix For: 0.96.0

 Attachments: 5953-v2.patch, HBASE-5953-v2.patch, HBASE-5953.patch


 The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way 
 that it is impossible to retrieve its value without changing it:
 /**
 Turn the load balancer on or off.
 @param b If true, enable balancer. If false, disable balancer.
 @return Previous balancer value
 */
 public boolean balanceSwitch(final boolean b);
 It would be nice to have a way to just get the current state.

--
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] [Updated] (HBASE-6207) Add jitter to client retry timer

2012-06-21 Thread Jean-Daniel Cryans (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Daniel Cryans updated HBASE-6207:
--

   Resolution: Fixed
Fix Version/s: 0.96.0
 Release Note: The retries in the client now have a jitter of up to 1% of 
the normal computed sleep time.
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

To close the debate on initializing Random, here's the 1.6 code:

{code}
public Random() { this(++seedUniquifier + System.nanoTime()); }
private static volatile long seedUniquifier = 8682522807148012L;
{code}

Thus I'm +1 and I committed it to trunk. Thanks Elliott!

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6207-0.patch




--
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-5539) asynchbase PerformanceEvaluation

2012-06-21 Thread Benoit Sigoure (JIRA)


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

Benoit Sigoure commented on HBASE-5539:
---

+1, thanks.

 asynchbase PerformanceEvaluation
 

 Key: HBASE-5539
 URL: https://issues.apache.org/jira/browse/HBASE-5539
 Project: HBase
  Issue Type: New Feature
  Components: performance
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
  Labels: benchmark
 Attachments: 0001-asynchbase-PerformanceEvaluation.patch, 
 0001-asynchbase-PerformanceEvaluation.patch, 
 5539-asynchbase-PerformanceEvaluation-v2.txt


 I plugged [asynchbase|https://github.com/stumbleupon/asynchbase] into 
 {{PerformanceEvaluation}}.  This enables testing asynchbase from 
 {{PerformanceEvaluation}} and comparing its performance to {{HTable}}.  Also 
 asynchbase doesn't come with any benchmark, so it was good that I was able to 
 plug it into {{PerformanceEvaluation}} relatively easily.
 I am in the processing of collecting results on a dev cluster running 0.92.1 
 and will publish them once they're ready.

--
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-6246) Admin.move() without specifying destination calls am.unassign() and does not go through AccessController.


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

Andrew Purtell commented on HBASE-6246:
---

+1 fix on 0.94. Good catch.

 Admin.move() without specifying destination calls am.unassign() and does not 
 go through AccessController.
 -

 Key: HBASE-6246
 URL: https://issues.apache.org/jira/browse/HBASE-6246
 Project: HBase
  Issue Type: Bug
  Components: coprocessors, security
Affects Versions: 0.94.0, 0.94.1
Reporter: ramkrishna.s.vasudevan
  Labels: coprocessors, security

 {code}
 if (destServerName == null || destServerName.length == 0) {
   LOG.info(Passed destination servername is null/empty so  +
 choosing a server at random);
   this.assignmentManager.clearRegionPlan(hri);
   // Unassign will reassign it elsewhere choosing random server.
   this.assignmentManager.unassign(hri);
 {code}
 I think we should go through security to see if there is sufficient 
 permissions to do this operation?

--
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-6207) Add jitter to client retry timer


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

Andrew Purtell commented on HBASE-6207:
---

Trivial backport to 0.94 complete and ready to go. Commit?

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6207-0.patch




--
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-6207) Add jitter to client retry timer

2012-06-21 Thread Jean-Daniel Cryans (JIRA)


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

Jean-Daniel Cryans commented on HBASE-6207:
---

I'm 0, it doesn't seem necessary.

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6207-0.patch




--
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-6207) Add jitter to client retry timer


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

Andrew Purtell commented on HBASE-6207:
---

Ok, I'll leave it be.

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6207-0.patch




--
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] [Updated] (HBASE-5539) asynchbase PerformanceEvaluation


 [ 
https://issues.apache.org/jira/browse/HBASE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Ted Yu updated HBASE-5539:
--

Attachment: 5539-asynchbase-PerformanceEvaluation-v3.txt

I got the code base to compile.
But:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
(default-testCompile) on project hbase-server: Compilation failure
[ERROR] 
/home/hduser/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java:[884,56]
 cannot find symbol
[ERROR] symbol  : method getNumClientThreads()
[ERROR] location: class 
org.apache.hadoop.hbase.PerformanceEvaluation.TestOptions
{code}

 asynchbase PerformanceEvaluation
 

 Key: HBASE-5539
 URL: https://issues.apache.org/jira/browse/HBASE-5539
 Project: HBase
  Issue Type: New Feature
  Components: performance
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
  Labels: benchmark
 Attachments: 0001-asynchbase-PerformanceEvaluation.patch, 
 0001-asynchbase-PerformanceEvaluation.patch, 
 5539-asynchbase-PerformanceEvaluation-v2.txt, 
 5539-asynchbase-PerformanceEvaluation-v3.txt


 I plugged [asynchbase|https://github.com/stumbleupon/asynchbase] into 
 {{PerformanceEvaluation}}.  This enables testing asynchbase from 
 {{PerformanceEvaluation}} and comparing its performance to {{HTable}}.  Also 
 asynchbase doesn't come with any benchmark, so it was good that I was able to 
 plug it into {{PerformanceEvaluation}} relatively easily.
 I am in the processing of collecting results on a dev cluster running 0.92.1 
 and will publish them once they're ready.

--
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-6207) Add jitter to client retry timer


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

Elliott Clark commented on HBASE-6207:
--

As in lets backport.  It helps mitigate the replication issues that are logged 
in HBASE-6165

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6207-0.patch




--
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-6207) Add jitter to client retry timer


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

Elliott Clark commented on HBASE-6207:
--

Yes please.

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6207-0.patch




--
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] [Comment Edited] (HBASE-5539) asynchbase PerformanceEvaluation


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

Zhihong Ted Yu edited comment on HBASE-5539 at 6/21/12 9:52 PM:


I got the code base to get past netty dependency download.
But:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
(default-testCompile) on project hbase-server: Compilation failure
[ERROR] 
/home/hduser/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java:[884,56]
 cannot find symbol
[ERROR] symbol  : method getNumClientThreads()
[ERROR] location: class 
org.apache.hadoop.hbase.PerformanceEvaluation.TestOptions
{code}

  was (Author: zhi...@ebaysf.com):
I got the code base to compile.
But:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
(default-testCompile) on project hbase-server: Compilation failure
[ERROR] 
/home/hduser/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java:[884,56]
 cannot find symbol
[ERROR] symbol  : method getNumClientThreads()
[ERROR] location: class 
org.apache.hadoop.hbase.PerformanceEvaluation.TestOptions
{code}
  
 asynchbase PerformanceEvaluation
 

 Key: HBASE-5539
 URL: https://issues.apache.org/jira/browse/HBASE-5539
 Project: HBase
  Issue Type: New Feature
  Components: performance
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
  Labels: benchmark
 Attachments: 0001-asynchbase-PerformanceEvaluation.patch, 
 0001-asynchbase-PerformanceEvaluation.patch, 
 5539-asynchbase-PerformanceEvaluation-v2.txt, 
 5539-asynchbase-PerformanceEvaluation-v3.txt


 I plugged [asynchbase|https://github.com/stumbleupon/asynchbase] into 
 {{PerformanceEvaluation}}.  This enables testing asynchbase from 
 {{PerformanceEvaluation}} and comparing its performance to {{HTable}}.  Also 
 asynchbase doesn't come with any benchmark, so it was good that I was able to 
 plug it into {{PerformanceEvaluation}} relatively easily.
 I am in the processing of collecting results on a dev cluster running 0.92.1 
 and will publish them once they're ready.

--
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] [Updated] (HBASE-6207) Add jitter to client retry timer


 [ 
https://issues.apache.org/jira/browse/HBASE-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6207:
--

Fix Version/s: 0.94.1

Committed to 0.94 branch also at Elliott's recommendation. New test 
TestConnectionUtils passes locally. Running full test suite now to confirm 
remainder and will back out if there's a problem.

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6207-0.patch




--
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-5953) Expose the current state of the balancerSwitch

2012-06-21 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-5953:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12532934/HBASE-5953-v2.patch
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 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

+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 11 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.security.access.TestAccessController

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

This message is automatically generated.

Expose the current state of the balancerSwitch
--

Key: HBASE-5953
URL: https://issues.apache.org/jira/browse/HBASE-5953
Project: HBase
Issue Type: Improvement
Components: master
Affects Versions: 0.96.0
Reporter: David S. Wang
Assignee: Gregory Chanan
Priority: Minor
Fix For: 0.96.0

Attachments: 5953-v2.patch, HBASE-5953-v2.patch, HBASE-5953.patch

The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way
that it is impossible to retrieve its value without changing it:
/**
Turn the load balancer on or off.
@param b If true, enable balancer. If false, disable balancer.
@return Previous balancer value
*/
public boolean balanceSwitch(final boolean b);
It would be nice to have a way to just get the current state.

[jira] [Updated] (HBASE-5539) asynchbase PerformanceEvaluation


 [ 
https://issues.apache.org/jira/browse/HBASE-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhihong Ted Yu updated HBASE-5539:
--

Attachment: 5539-asynchbase-PerformanceEvaluation-v4.txt

Patch v4 compiles.

 asynchbase PerformanceEvaluation
 

 Key: HBASE-5539
 URL: https://issues.apache.org/jira/browse/HBASE-5539
 Project: HBase
  Issue Type: New Feature
  Components: performance
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
  Labels: benchmark
 Attachments: 0001-asynchbase-PerformanceEvaluation.patch, 
 0001-asynchbase-PerformanceEvaluation.patch, 
 5539-asynchbase-PerformanceEvaluation-v2.txt, 
 5539-asynchbase-PerformanceEvaluation-v3.txt, 
 5539-asynchbase-PerformanceEvaluation-v4.txt


 I plugged [asynchbase|https://github.com/stumbleupon/asynchbase] into 
 {{PerformanceEvaluation}}.  This enables testing asynchbase from 
 {{PerformanceEvaluation}} and comparing its performance to {{HTable}}.  Also 
 asynchbase doesn't come with any benchmark, so it was good that I was able to 
 plug it into {{PerformanceEvaluation}} relatively easily.
 I am in the processing of collecting results on a dev cluster running 0.92.1 
 and will publish them once they're ready.

--
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-6243) New UI should space detailed latency columns equally


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

Hudson commented on HBASE-6243:
---

Integrated in HBase-TRUNK #3055 (See 
[https://builds.apache.org/job/HBase-TRUNK/3055/])
HBASE-6243. New UI should space detailed latency columns equally (Elliott 
Clark) (Revision 1352694)

 Result = FAILURE
apurtell : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/ServerMetricsTmpl.jamon


 New UI should space detailed latency columns equally
 

 Key: HBASE-6243
 URL: https://issues.apache.org/jira/browse/HBASE-6243
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-6243-0.patch


 Spacing between the columns of the detailed latencies tab should be roughly 
 equal. Round latencies to two digits right of decimal point.

--
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-6207) Add jitter to client retry timer


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

Hudson commented on HBASE-6207:
---

Integrated in HBase-TRUNK #3055 (See 
[https://builds.apache.org/job/HBase-TRUNK/3055/])
HBASE-6207  Add jitter to client retry timer (Elliott Clark via JD) 
(Revision 1352699)

 Result = FAILURE
jdcryans : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/client/ConnectionUtils.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestConnectionUtils.java


 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6207-0.patch




--
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-6242) New UI should color task list entries


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

Hudson commented on HBASE-6242:
---

Integrated in HBase-TRUNK #3055 (See 
[https://builds.apache.org/job/HBase-TRUNK/3055/])
HBASE-6242. New UI should color task list entries (Elliott Clark) (Revision 
1352690)

 Result = FAILURE
apurtell : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/common/TaskMonitorTmpl.jamon


 New UI should color task list entries
 -

 Key: HBASE-6242
 URL: https://issues.apache.org/jira/browse/HBASE-6242
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.96.0
Reporter: Andrew Purtell
Assignee: Elliott Clark
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-6242-0.patch


 The old UI changed the background color of tasklist entries according to 
 their final status: green if successful, yellow if aborted, red if failed. 
 Bring this back in the new UI.

--
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-5933) Hide HBaseProtos.ServerLoad and HBaseProtos.RegionLoad from ClusterStatus

2012-06-21 Thread Gregory Chanan (JIRA)


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

Gregory Chanan commented on HBASE-5933:
---

It looks like reviewboard isn't posting to the JIRA anymore, so here's the 
review request:
https://reviews.apache.org/r/5415/

 Hide HBaseProtos.ServerLoad and HBaseProtos.RegionLoad from ClusterStatus
 -

 Key: HBASE-5933
 URL: https://issues.apache.org/jira/browse/HBASE-5933
 Project: HBase
  Issue Type: Task
  Components: ipc
Affects Versions: 0.96.0
Reporter: Gregory Chanan
Assignee: Gregory Chanan
Priority: Minor
 Attachments: HBASE-5933.patch


 From Stack's comments on HBASE-5444:
 We need this import?  Its for cp.  Thats ok I'd say One day we can hide 
 that too..

--
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-5953) Expose the current state of the balancerSwitch


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

Hudson commented on HBASE-5953:
---

Integrated in HBase-TRUNK #3055 (See 
[https://builds.apache.org/job/HBase-TRUNK/3055/])
HBASE-5953 Expose the current state of the balancerSwitch (Gregory Chanan) 
(Revision 1352696)

 Result = FAILURE
tedyu : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/ClusterStatus.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ClusterStatusProtos.java
* /hbase/trunk/hbase-server/src/main/protobuf/ClusterStatus.proto


 Expose the current state of the balancerSwitch
 --

 Key: HBASE-5953
 URL: https://issues.apache.org/jira/browse/HBASE-5953
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 0.96.0
Reporter: David S. Wang
Assignee: Gregory Chanan
Priority: Minor
 Fix For: 0.96.0

 Attachments: 5953-v2.patch, HBASE-5953-v2.patch, HBASE-5953.patch


 The balancerSwitch as in both 0.90 and 0.92.1 is implemented in such a way 
 that it is impossible to retrieve its value without changing it:
 /**
 Turn the load balancer on or off.
 @param b If true, enable balancer. If false, disable balancer.
 @return Previous balancer value
 */
 public boolean balanceSwitch(final boolean b);
 It would be nice to have a way to just get the current state.

--
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-6039) Remove HMasterInterface and replace with something similar to RegionServerStatusProtocol

2012-06-21 Thread Gregory Chanan (JIRA)


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

Gregory Chanan commented on HBASE-6039:
---

Here's my idea for a breakdown into two protocols: Administrative and 
Monitoring.  Below lists the functions for each.  Any comments welcome.

Administrative Master Actions (MasterAdminProtocol):
addColumn
modifyColumn
deleteColumn
offlineRegion
assignRegion
unassignRegion
moveRegion
createTable
deleteTable
disableTable
modifyTable
enableTable
shutdown
stopMaster
balance
setBalancerRunning

Monitoring Master Actions (MasterMonitorProtocol):
isMasterRunning
getSchemaAlterStatus
getClusterStatus
getTableDescriptors


 Remove HMasterInterface and replace with something similar to 
 RegionServerStatusProtocol
 

 Key: HBASE-6039
 URL: https://issues.apache.org/jira/browse/HBASE-6039
 Project: HBase
  Issue Type: Task
  Components: ipc, master
Reporter: Gregory Chanan
Assignee: Gregory Chanan
 Fix For: 0.96.0


 Me: Once everything in HMasterInterface is converted to use PB, we can either 
 declare a new class for the representation (similar to 
 RegionServerStatusProtocol) or just re-purpose HMasterInterface for that. 
 What is your preference?
 Stack: Lets do what Jimmy did, make a new class and kill the old.

--
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-5539) asynchbase PerformanceEvaluation

2012-06-21 Thread Benoit Sigoure (JIRA)


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

Benoit Sigoure commented on HBASE-5539:
---

Yeah someone first needs to commit HBASE-5539.

 asynchbase PerformanceEvaluation
 

 Key: HBASE-5539
 URL: https://issues.apache.org/jira/browse/HBASE-5539
 Project: HBase
  Issue Type: New Feature
  Components: performance
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
  Labels: benchmark
 Attachments: 0001-asynchbase-PerformanceEvaluation.patch, 
 0001-asynchbase-PerformanceEvaluation.patch, 
 5539-asynchbase-PerformanceEvaluation-v2.txt, 
 5539-asynchbase-PerformanceEvaluation-v3.txt, 
 5539-asynchbase-PerformanceEvaluation-v4.txt


 I plugged [asynchbase|https://github.com/stumbleupon/asynchbase] into 
 {{PerformanceEvaluation}}.  This enables testing asynchbase from 
 {{PerformanceEvaluation}} and comparing its performance to {{HTable}}.  Also 
 asynchbase doesn't come with any benchmark, so it was good that I was able to 
 plug it into {{PerformanceEvaluation}} relatively easily.
 I am in the processing of collecting results on a dev cluster running 0.92.1 
 and will publish them once they're ready.

--
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-5933) Hide HBaseProtos.ServerLoad and HBaseProtos.RegionLoad from ClusterStatus


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

Zhihong Ted Yu commented on HBASE-5933:
---

I put a few comments on review board.

 Hide HBaseProtos.ServerLoad and HBaseProtos.RegionLoad from ClusterStatus
 -

 Key: HBASE-5933
 URL: https://issues.apache.org/jira/browse/HBASE-5933
 Project: HBase
  Issue Type: Task
  Components: ipc
Affects Versions: 0.96.0
Reporter: Gregory Chanan
Assignee: Gregory Chanan
Priority: Minor
 Attachments: HBASE-5933.patch


 From Stack's comments on HBASE-5444:
 We need this import?  Its for cp.  Thats ok I'd say One day we can hide 
 that too..

--
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-5933) Hide HBaseProtos.ServerLoad and HBaseProtos.RegionLoad from ClusterStatus


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

Elliott Clark commented on HBASE-5933:
--

I posted a few as well.

 Hide HBaseProtos.ServerLoad and HBaseProtos.RegionLoad from ClusterStatus
 -

 Key: HBASE-5933
 URL: https://issues.apache.org/jira/browse/HBASE-5933
 Project: HBase
  Issue Type: Task
  Components: ipc
Affects Versions: 0.96.0
Reporter: Gregory Chanan
Assignee: Gregory Chanan
Priority: Minor
 Attachments: HBASE-5933.patch


 From Stack's comments on HBASE-5444:
 We need this import?  Its for cp.  Thats ok I'd say One day we can hide 
 that too..

--
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-5539) asynchbase PerformanceEvaluation


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

Zhihong Ted Yu commented on HBASE-5539:
---

@Benoit:
This is HBASE-5539 :-)
What do you think of patch v4 ?

 asynchbase PerformanceEvaluation
 

 Key: HBASE-5539
 URL: https://issues.apache.org/jira/browse/HBASE-5539
 Project: HBase
  Issue Type: New Feature
  Components: performance
Reporter: Benoit Sigoure
Assignee: Benoit Sigoure
Priority: Minor
  Labels: benchmark
 Attachments: 0001-asynchbase-PerformanceEvaluation.patch, 
 0001-asynchbase-PerformanceEvaluation.patch, 
 5539-asynchbase-PerformanceEvaluation-v2.txt, 
 5539-asynchbase-PerformanceEvaluation-v3.txt, 
 5539-asynchbase-PerformanceEvaluation-v4.txt


 I plugged [asynchbase|https://github.com/stumbleupon/asynchbase] into 
 {{PerformanceEvaluation}}.  This enables testing asynchbase from 
 {{PerformanceEvaluation}} and comparing its performance to {{HTable}}.  Also 
 asynchbase doesn't come with any benchmark, so it was good that I was able to 
 plug it into {{PerformanceEvaluation}} relatively easily.
 I am in the processing of collecting results on a dev cluster running 0.92.1 
 and will publish them once they're ready.

--
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-5539) asynchbase PerformanceEvaluation