date:20130116

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

Hadoop QA commented on HBASE-7579:
--

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12565094/HBASE-7579-v1.patch
against trunk revision .

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:red}-1 tests included{color}. 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.

{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:red}-1 lineLengths{color}. The patch introduces lines longer than
100

{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestLocalHBaseCluster

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4044//console

This message is automatically generated.

HTableDescriptor equals method fails if results are returned in a different
order
-

Key: HBASE-7579
URL: https://issues.apache.org/jira/browse/HBASE-7579
Project: HBase
Issue Type: Bug
Components: Admin
Reporter: Aleksandr Shulman
Assignee: Aleksandr Shulman
Priority: Minor
Fix For: 0.96.0, 0.94.5

Attachments: HBASE-7579-v1.patch

HTableDescriptor's compareTo function compares a set of HColumnDescriptors
against another set of HColumnDescriptors. It iterates through both, relying
on the fact that they will be in the same order.
In my testing, I may have seen this issue come up, so I decided to fix it.
It's a straightforward fix. I convert the sets into a hashset for O(1)
lookups (at least in theory), then I check that all items in the first set
are found in the second.
Since the sizes are the same, we know that if all elements showed up in the
second set, then they must be equal.

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

[jira] [Commented] (HBASE-7329) remove flush-related records from WAL and reduce locking

2013-01-16 Thread chunhui shen (JIRA)


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

chunhui shen commented on HBASE-7329:
-

Agree with removing that flush-related log.
PatchV2 is good after a review



 remove flush-related records from WAL and reduce locking
 

 Key: HBASE-7329
 URL: https://issues.apache.org/jira/browse/HBASE-7329
 Project: HBase
  Issue Type: Improvement
  Components: wal
Affects Versions: 0.96.0
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
 Attachments: HBASE-7329-v0.patch, HBASE-7329-v0.patch, 
 HBASE-7329-v0-tmp.patch, HBASE-7329-v1.patch, HBASE-7329-v1.patch, 
 HBASE-7329-v2.patch


 Comments from many people in HBASE-6466 and HBASE-6980 indicate that flush 
 records in WAL are not useful. If so, they should be removed.

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

[jira] [Commented] (HBASE-7507) Make memstore flush be able to retry after exception

2013-01-16 Thread chunhui shen (JIRA)


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

chunhui shen commented on HBASE-7507:
-

Commit it tomorrow if no objections
Thanks for the review， Ted, Ram, Lars

 Make memstore flush be able to retry after exception
 

 Key: HBASE-7507
 URL: https://issues.apache.org/jira/browse/HBASE-7507
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0, 0.94.5

 Attachments: 7507-trunk v1.patch, 7507-trunk v2.patch, 
 7507-trunkv3.patch


 We will abort regionserver if memstore flush throws exception.
 I thinks we could do retry to make regionserver more stable because file 
 system may be not ok in a transient time. e.g. Switching namenode in the 
 NamenodeHA environment
 {code}
 HRegion#internalFlushcache(){
 ...
 try {
 ...
 }catch(Throwable t){
 DroppedSnapshotException dse = new DroppedSnapshotException(region:  +
   Bytes.toStringBinary(getRegionName()));
 dse.initCause(t);
 throw dse;
 }
 ...
 }
 MemStoreFlusher#flushRegion(){
 ...
 region.flushcache();
 ...
  try {
 }catch(DroppedSnapshotException ex){
 server.abort(Replay of HLog required. Forcing server shutdown, ex);
 }
 ...
 }
 {code}

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

[jira] [Commented] (HBASE-7573) How to migrate to a hbase cluster with kerberos from a hbase cluster without kerberos

2013-01-16 Thread Liu Shaohui (JIRA)


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

Liu Shaohui commented on HBASE-7573:


Ok, thx.

 How to migrate to a hbase cluster with kerberos from  a hbase cluster without 
 kerberos 
 ---

 Key: HBASE-7573
 URL: https://issues.apache.org/jira/browse/HBASE-7573
 Project: HBase
  Issue Type: Improvement
  Components: migration
 Environment: hbase 0.94.3
Reporter: Liu Shaohui

 We have deployed a hbase cluster without kerberos.And for security issue, we 
 want to upgrade it to a hbase cluster with kerberos. After we config hbase 
 cluster with kerberos, we found that the hmaster can not read/write the data 
 in zookeeper the the hbase cluster without kerberos left.
 How can we migrate to a hbase cluster with kerberos from  a hbase cluster 
 without kerberos? We want to keep the data in the hbase cluster.

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

[jira] [Updated] (HBASE-7574) Migrate to JUnit 4.11


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

nkeywal updated HBASE-7574:
---

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

 Migrate to JUnit 4.11
 -

 Key: HBASE-7574
 URL: https://issues.apache.org/jira/browse/HBASE-7574
 Project: HBase
  Issue Type: Bug
  Components: build, test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7574.v1.patch, 7574.v1.patch




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

[jira] [Commented] (HBASE-6015) HBCK rerun should check all the regions which it checked in the first run

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

Anoop Sam John commented on HBASE-6015:
---

bq.is it possible to add a test?
Ok. I will try adding a test
bq.maybe print out the list of skipped regions in the rerun?
Do we really need to print this? In the 1st run are we priniting the list of
skipper regions in that run? IMHO we need to print there only. In the rerun it
is by default we need to run only those regions which were run in 1st run and
avoid those excluded in the 1st run. The rerun is to check whether the fix is
done or not :) Correct me if I am wrong Jon. You are the master of HBCK and
you judge better than me

HBCK rerun should check all the regions which it checked in the first run
-

Key: HBASE-6015
URL: https://issues.apache.org/jira/browse/HBASE-6015
Project: HBase
Issue Type: Bug
Components: hbck
Reporter: Anoop Sam John
Assignee: Anoop Sam John
Attachments: HBASE-6015_94.patch

When after the 1st round of run and possible fixes, HBCK does a rerun to
check the consistency of the regions. At this rerun
1.It should check all the regions which it checked in the 1st round.
2.It should check only those regions which it checked in the 1st round. Might
be some other regions can come out of the timelag check at rerun time.

[jira] [Commented] (HBASE-7549) Make HTableInterface#batch() javadoc proper


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

Hudson commented on HBASE-7549:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #350 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/350/])
HBASE-7549 Make HTableInterface#batch() javadoc proper (Anoop) (Revision 
1433805)

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


 Make HTableInterface#batch() javadoc proper
 ---

 Key: HBASE-7549
 URL: https://issues.apache.org/jira/browse/HBASE-7549
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.94.0, 0.96.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
Priority: Trivial
 Fix For: 0.96.0, 0.94.5

 Attachments: HBASE-7549_94.patch, HBASE-7549_trunk.patch, 
 HBASE-7549_trunk_v2.patch


 We can pass Put, Get, Delete, Append, Increment in the batch.  But the 
 javadoc do cover Put, Delete and Get only. Better to correct this.

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

[jira] [Commented] (HBASE-7213) Have HLog files for .META. and -ROOT- edits only


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

Hudson commented on HBASE-7213:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #350 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/350/])
HBASE-7213 Addendum tries to fix premature LogRoller exit (Chunhui) 
(Revision 1433830)

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


 Have HLog files for .META. and -ROOT- edits only
 

 Key: HBASE-7213
 URL: https://issues.apache.org/jira/browse/HBASE-7213
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Reporter: Devaraj Das
Assignee: Devaraj Das
Priority: Critical
 Fix For: 0.96.0

 Attachments: 7213-15.patch, 7213-2.10.patch, 7213-2.11.patch, 
 7213-2.12.patch, 7213-2.14.patch, 7213-2.14.patch, 7213-2.16.patch, 
 7213-2.4.patch, 7213-2.6.patch, 7213-2.8.patch, 7213-2.9.patch, 
 7213-addendum.patch, 7213-in-progress.2.2.patch, 7213-in-progress.2.patch, 
 7213-in-progress.patch, 7213v13.txt, 
 TEST-org.apache.hadoop.hbase.client.TestMultiParallel.xml


 Over on HBASE-6774, there is a discussion on separating out the edits for 
 .META. regions from the other regions' edits w.r.t where the edits are 
 written. This jira is to track an implementation of that.

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

[jira] [Commented] (HBASE-7574) Migrate to JUnit 4.11


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

Hudson commented on HBASE-7574:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #350 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/350/])
HBASE-7574 Migrate to JUnit 4.11 (Revision 1433890)

 Result = FAILURE
nkeywal : 
Files : 
* /hbase/trunk/pom.xml


 Migrate to JUnit 4.11
 -

 Key: HBASE-7574
 URL: https://issues.apache.org/jira/browse/HBASE-7574
 Project: HBase
  Issue Type: Bug
  Components: build, test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7574.v1.patch, 7574.v1.patch




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

[jira] [Commented] (HBASE-7574) Migrate to JUnit 4.11


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

Hudson commented on HBASE-7574:
---

Integrated in HBase-TRUNK #3756 (See 
[https://builds.apache.org/job/HBase-TRUNK/3756/])
HBASE-7574 Migrate to JUnit 4.11 (Revision 1433890)

 Result = FAILURE
nkeywal : 
Files : 
* /hbase/trunk/pom.xml


 Migrate to JUnit 4.11
 -

 Key: HBASE-7574
 URL: https://issues.apache.org/jira/browse/HBASE-7574
 Project: HBase
  Issue Type: Bug
  Components: build, test
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7574.v1.patch, 7574.v1.patch




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

[jira] [Commented] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time


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

Jean-Marc Spaggiari commented on HBASE-7503:


I will update the proposed patch and use getStartEndKeys. I will also add some 
regions on the test table to make sure this region-sorted approach is tested 
correctly...

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

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

[jira] [Commented] (HBASE-7579) HTableDescriptor equals method fails if results are returned in a different order

2013-01-16 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-7579:
---

Patch looks good.
{code}
+ HashSetHColumnDescriptor otherFamiliesAsHashSet = new
HashSetHColumnDescriptor(other.families.values());
{code}
Wrap long line.
otherFamiliesAsHashSet can be declared as Set.

HTableDescriptor equals method fails if results are returned in a different
order
-

Attachments: HBASE-7579-v1.patch

[jira] [Created] (HBASE-7580) TestAccessController fails in trunk

2013-01-16 Thread Ted Yu (JIRA)

Ted Yu created HBASE-7580:
-

 Summary: TestAccessController fails in trunk
 Key: HBASE-7580
 URL: https://issues.apache.org/jira/browse/HBASE-7580
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
 Fix For: 0.96.0


It failed in build #3756.
I can reproduce the failure locally:
{code}
testReadWrite(org.apache.hadoop.hbase.security.access.TestAccessController)  
Time elapsed: 39.306 sec   ERROR!
org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after 
attempts=10, exceptions:
Wed Jan 16 04:31:13 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:14 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:16 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:17 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:19 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:21 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:25 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:29 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:37 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException
Wed Jan 16 04:31:53 PST 2013, 
org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
java.io.IOException: java.lang.NullPointerException

  at 
org.apache.hadoop.hbase.client.ServerCallable.withRetries(ServerCallable.java:186)
  at org.apache.hadoop.hbase.client.HTable.checkAndDelete(HTable.java:843)
  at 
org.apache.hadoop.hbase.security.access.TestAccessController$27.run(TestAccessController.java:668)
{code}

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

[jira] [Updated] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time


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

Jean-Marc Spaggiari updated HBASE-7503:
---

Status: Open  (was: Patch Available)

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

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

[jira] [Updated] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time


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

Jean-Marc Spaggiari updated HBASE-7503:
---

Status: Patch Available  (was: Open)

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

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

[jira] [Updated] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time


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

Jean-Marc Spaggiari updated HBASE-7503:
---

Attachment: HBASE-7503-v7-trunk.patch

Updated patch using getStartEndKeys() instead of connection.getRegionLocation() 
and adding more robust tests (multi-regions).

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

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

[jira] [Created] (HBASE-7581) TestAccessController depends on the execution order

nkeywal created HBASE-7581:
--

 Summary: TestAccessController depends on the execution order
 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0




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

[jira] [Commented] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time

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

Hadoop QA commented on HBASE-7503:
--

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment

http://issues.apache.org/jira/secure/attachment/12565120/HBASE-7503-v7-trunk.patch
against trunk revision .

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.

{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:red}-1 lineLengths{color}. The patch introduces lines longer than
100

{color:red}-1 core tests{color}. The patch failed these unit tests:

org.apache.hadoop.hbase.security.access.TestAccessController
org.apache.hadoop.hbase.TestLocalHBaseCluster

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4045//console

This message is automatically generated.

Add exists(List) in HTableInterface to allow multiple parallel exists at one
time
-

Key: HBASE-7503
URL: https://issues.apache.org/jira/browse/HBASE-7503
Project: HBase
Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
Fix For: 0.96.0

Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v1-trunk.patch,
HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch,
HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch,
HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch

Original Estimate: 5m
Remaining Estimate: 5m

We need to have a Boolean[] exists(ListGet gets) throws IOException method
implemented in HTableInterface.

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order


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

nkeywal commented on HBASE-7581:


The stack is surprising...

org.apache.hadoop.hbase.client.ServerCallable.withRetries(ServerCallable.java:186)
at org.apache.hadoop.hbase.client.HTable.checkAndDelete(HTable.java:843)
at 
org.apache.hadoop.hbase.security.access.TestAccessController$27.run(TestAccessController.java:668)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at 
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1136)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.hbase.util.Methods.call(Methods.java:41)
at org.apache.hadoop.hbase.security.User.call(User.java:404)
at org.apache.hadoop.hbase.security.User.access$300(User.java:52)
at 
org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:258)
at 
org.apache.hadoop.hbase.security.access.TestAccessController.verifyAllowed(TestAccessController.java:192)
at 
org.apache.hadoop.hbase.security.access.TestAccessController.verifyAllowed(TestAccessController.java:201)
at 
org.apache.hadoop.hbase.security.access.TestAccessController.verifyReadWrite(TestAccessController.java:579)
at 
org.apache.hadoop.hbase.security.access.TestAccessController.testReadWrite(TestAccessController.java:673)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.io.IOException: java.io.IOException: 
java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order

2013-01-16 Thread Ted Yu (JIRA)


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

Ted Yu commented on HBASE-7581:
---

{code}
public long getMaxTimestamp() {
  return timeRangeTracker.maximumTimestamp;
}
{code}
NPE was caused by timeRangeTracker being null.

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0




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

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order


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

nkeywal commented on HBASE-7581:


Yes. I wonder if the error is not a real bug. I haven't found a test on 
checkAndDelete, so... It would be something that occurs only with a StoreFile...

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0




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

[jira] [Commented] (HBASE-7579) HTableDescriptor equals method fails if results are returned in a different order


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

Matteo Bertozzi commented on HBASE-7579:


Add a unit test, to verify equals() and compareTo().

{code}
 result = families.size() - other.families.size();
+  
+  if(result!=0 ) {
+return result;
+  }
 }
 if (result == 0  families.size() != other.families.size()) {
{code}
There're lots of redundant check here... 
why we check two times for families.size()?
why we check for == 0 when we return on != 0?



 HTableDescriptor equals method fails if results are returned in a different 
 order
 -

 Key: HBASE-7579
 URL: https://issues.apache.org/jira/browse/HBASE-7579
 Project: HBase
  Issue Type: Bug
  Components: Admin
Reporter: Aleksandr Shulman
Assignee: Aleksandr Shulman
Priority: Minor
 Fix For: 0.96.0, 0.94.5

 Attachments: HBASE-7579-v1.patch


 HTableDescriptor's compareTo function compares a set of HColumnDescriptors 
 against another set of HColumnDescriptors. It iterates through both, relying 
 on the fact that they will be in the same order.
 In my testing, I may have seen this issue come up, so I decided to fix it.
 It's a straightforward fix. I convert the sets into a hashset for O(1) 
 lookups (at least in theory), then I check that all items in the first set 
 are found in the second.
 Since the sizes are the same, we know that if all elements showed up in the 
 second set, then they must be equal.

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

[jira] [Updated] (HBASE-7034) Bad version, failed OPENING to OPENED but master thinks it is open anyways


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

Anoop Sam John updated HBASE-7034:
--

Attachment: HBASE-7034_94_V2.patch

Patch for 94. Added the test case also. As Ram said the data check is also 
added.

 Bad version, failed OPENING to OPENED but master thinks it is open anyways
 --

 Key: HBASE-7034
 URL: https://issues.apache.org/jira/browse/HBASE-7034
 Project: HBase
  Issue Type: Bug
  Components: Region Assignment
Affects Versions: 0.94.2
Reporter: stack
Assignee: Anoop Sam John
 Attachments: HBASE-7034_94.patch, HBASE-7034_94_V2.patch, 
 TestRecoverableZooKeeper.java


 I have this in RS log:
 {code}
 2012-10-22 02:21:50,698 ERROR 
 org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed 
 transitioning node 
 b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.
  from OPENING to OPENED -- closing region
 org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode = 
 BadVersion for /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 {code}
 Master says this (it is bulk assigning):
 {code}
 
 2012-10-22 02:21:40,673 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 ...
 then this
 
 2012-10-22 02:23:47,089 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 
 2012-10-22 02:24:34,176 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Retrieved 112 byte(s) of data from znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f and set watcher; 
 region=b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.,
  origin=sv4r17s44,10304,1350872216778, state=RS_ZK_REGION_OPENED
 etc.
 {code}
 Disagreement as to what is going on here.

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

[jira] [Updated] (HBASE-7034) Bad version, failed OPENING to OPENED but master thinks it is open anyways


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

Anoop Sam John updated HBASE-7034:
--

Attachment: (was: HBASE-7034_94_V2.patch)

 Bad version, failed OPENING to OPENED but master thinks it is open anyways
 --

 Key: HBASE-7034
 URL: https://issues.apache.org/jira/browse/HBASE-7034
 Project: HBase
  Issue Type: Bug
  Components: Region Assignment
Affects Versions: 0.94.2
Reporter: stack
Assignee: Anoop Sam John
 Attachments: HBASE-7034_94.patch, TestRecoverableZooKeeper.java


 I have this in RS log:
 {code}
 2012-10-22 02:21:50,698 ERROR 
 org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed 
 transitioning node 
 b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.
  from OPENING to OPENED -- closing region
 org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode = 
 BadVersion for /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 {code}
 Master says this (it is bulk assigning):
 {code}
 
 2012-10-22 02:21:40,673 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 ...
 then this
 
 2012-10-22 02:23:47,089 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 
 2012-10-22 02:24:34,176 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Retrieved 112 byte(s) of data from znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f and set watcher; 
 region=b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.,
  origin=sv4r17s44,10304,1350872216778, state=RS_ZK_REGION_OPENED
 etc.
 {code}
 Disagreement as to what is going on here.

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

[jira] [Updated] (HBASE-7034) Bad version, failed OPENING to OPENED but master thinks it is open anyways


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

Anoop Sam John updated HBASE-7034:
--

Attachment: HBASE-7034_94_V2.patch

 Bad version, failed OPENING to OPENED but master thinks it is open anyways
 --

 Key: HBASE-7034
 URL: https://issues.apache.org/jira/browse/HBASE-7034
 Project: HBase
  Issue Type: Bug
  Components: Region Assignment
Affects Versions: 0.94.2
Reporter: stack
Assignee: Anoop Sam John
 Attachments: HBASE-7034_94.patch, HBASE-7034_94_V2.patch, 
 TestRecoverableZooKeeper.java


 I have this in RS log:
 {code}
 2012-10-22 02:21:50,698 ERROR 
 org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed 
 transitioning node 
 b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.
  from OPENING to OPENED -- closing region
 org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode = 
 BadVersion for /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 {code}
 Master says this (it is bulk assigning):
 {code}
 
 2012-10-22 02:21:40,673 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 ...
 then this
 
 2012-10-22 02:23:47,089 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 
 2012-10-22 02:24:34,176 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Retrieved 112 byte(s) of data from znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f and set watcher; 
 region=b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.,
  origin=sv4r17s44,10304,1350872216778, state=RS_ZK_REGION_OPENED
 etc.
 {code}
 Disagreement as to what is going on here.

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

[jira] [Updated] (HBASE-7575) FSUtils#getTableStoreFilePathMap should all ignore non-table folders

2013-01-16 Thread Jimmy Xiang (JIRA)


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

Jimmy Xiang updated HBASE-7575:
---

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

 FSUtils#getTableStoreFilePathMap should all ignore non-table folders
 

 Key: HBASE-7575
 URL: https://issues.apache.org/jira/browse/HBASE-7575
 Project: HBase
  Issue Type: Bug
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
 Fix For: 0.96.0, 0.94.5

 Attachments: trunk_7575.patch, trunk_7575_v2.patch


 Currently it just ignores .log.  It should ignore all non-table folders.

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

[jira] [Updated] (HBASE-7581) TestAccessController depends on the execution order


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

nkeywal updated HBASE-7581:
---

Attachment: 7581.v1.patch

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Updated] (HBASE-7034) Bad version, failed OPENING to OPENED but master thinks it is open anyways


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

Anoop Sam John updated HBASE-7034:
--

Attachment: (was: HBASE-7034_94_V2.patch)

 Bad version, failed OPENING to OPENED but master thinks it is open anyways
 --

 Key: HBASE-7034
 URL: https://issues.apache.org/jira/browse/HBASE-7034
 Project: HBase
  Issue Type: Bug
  Components: Region Assignment
Affects Versions: 0.94.2
Reporter: stack
Assignee: Anoop Sam John
 Attachments: HBASE-7034_94.patch, HBASE-7034_94_V2.patch, 
 TestRecoverableZooKeeper.java


 I have this in RS log:
 {code}
 2012-10-22 02:21:50,698 ERROR 
 org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed 
 transitioning node 
 b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.
  from OPENING to OPENED -- closing region
 org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode = 
 BadVersion for /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 {code}
 Master says this (it is bulk assigning):
 {code}
 
 2012-10-22 02:21:40,673 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 ...
 then this
 
 2012-10-22 02:23:47,089 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 
 2012-10-22 02:24:34,176 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Retrieved 112 byte(s) of data from znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f and set watcher; 
 region=b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.,
  origin=sv4r17s44,10304,1350872216778, state=RS_ZK_REGION_OPENED
 etc.
 {code}
 Disagreement as to what is going on here.

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

[jira] [Updated] (HBASE-7034) Bad version, failed OPENING to OPENED but master thinks it is open anyways


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

Anoop Sam John updated HBASE-7034:
--

Attachment: HBASE-7034_94_V2.patch

 Bad version, failed OPENING to OPENED but master thinks it is open anyways
 --

 Key: HBASE-7034
 URL: https://issues.apache.org/jira/browse/HBASE-7034
 Project: HBase
  Issue Type: Bug
  Components: Region Assignment
Affects Versions: 0.94.2
Reporter: stack
Assignee: Anoop Sam John
 Attachments: HBASE-7034_94.patch, HBASE-7034_94_V2.patch, 
 TestRecoverableZooKeeper.java


 I have this in RS log:
 {code}
 2012-10-22 02:21:50,698 ERROR 
 org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed 
 transitioning node 
 b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.
  from OPENING to OPENED -- closing region
 org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode = 
 BadVersion for /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 {code}
 Master says this (it is bulk assigning):
 {code}
 
 2012-10-22 02:21:40,673 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 ...
 then this
 
 2012-10-22 02:23:47,089 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Set watcher on existing znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f
 
 2012-10-22 02:24:34,176 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: 
 master:10302-0xb3a862e57a503ba Retrieved 112 byte(s) of data from znode 
 /hbase/unassigned/9af7cfc9b15910a0b3d714bf40a3248f and set watcher; 
 region=b9,\xEE\xAE\x9BiQO\x89]+a\xE0\x7F\xB7'X?,1349052737638.9af7cfc9b15910a0b3d714bf40a3248f.,
  origin=sv4r17s44,10304,1350872216778, state=RS_ZK_REGION_OPENED
 etc.
 {code}
 Disagreement as to what is going on here.

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

[jira] [Resolved] (HBASE-7580) TestAccessController fails in trunk

2013-01-16 Thread Nick Dimiduk (JIRA)


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

Nick Dimiduk resolved HBASE-7580.
-

Resolution: Duplicate

 TestAccessController fails in trunk
 ---

 Key: HBASE-7580
 URL: https://issues.apache.org/jira/browse/HBASE-7580
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
 Fix For: 0.96.0


 It failed in build #3756.
 I can reproduce the failure locally:
 {code}
 testReadWrite(org.apache.hadoop.hbase.security.access.TestAccessController)  
 Time elapsed: 39.306 sec   ERROR!
 org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after 
 attempts=10, exceptions:
 Wed Jan 16 04:31:13 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:14 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:16 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:17 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:19 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:21 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:25 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:29 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:37 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
 Wed Jan 16 04:31:53 PST 2013, 
 org.apache.hadoop.hbase.client.HTable$10@124d998e, java.io.IOException: 
 java.io.IOException: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.client.ServerCallable.withRetries(ServerCallable.java:186)
   at org.apache.hadoop.hbase.client.HTable.checkAndDelete(HTable.java:843)
   at 
 org.apache.hadoop.hbase.security.access.TestAccessController$27.run(TestAccessController.java:668)
 {code}

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

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order


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

stack commented on HBASE-7581:
--

+1

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Commented] (HBASE-2611) Handle RS that fails while processing the failure of another one

2013-01-16 Thread Himanshu Vashishtha (JIRA)

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

Himanshu Vashishtha commented on HBASE-2611:

bq. But what can happen is that the region server who wins the race to take
over the dead region server's queues could die before it even manages to call
multi.
Not following your question. How can a regionserver wins a race before calling
multi? If regionserver A fails, *all* regionserver will call multi to do the
failover, and only one (let's say B) will succeed. Now, if B also dies
meanwhile (while it has succeeded in transferring the queue from zk
perspective), the regionserver doing the failover for B will also process A's
znodes (as they are with B now). Therefore, I don't see we really need a retry.
Did I miss anything?

Handle RS that fails while processing the failure of another one

Key: HBASE-2611
URL: https://issues.apache.org/jira/browse/HBASE-2611
Project: HBase
Issue Type: Sub-task
Components: Replication
Reporter: Jean-Daniel Cryans
Assignee: Himanshu Vashishtha
Fix For: 0.94.5

Attachments: HBase-2611-upstream-v1.patch, HBASE-2611-v2.patch

HBASE-2223 doesn't manage region servers that fail while doing the transfer
of HLogs queues from other region servers that failed. Devise a reliable way
to do it.

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order

2013-01-16 Thread Nick Dimiduk (JIRA)


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

Nick Dimiduk commented on HBASE-7581:
-

{code}
-  final ListThrowableWithExtraContext exceptions) {
-super(getMessage(numTries, exceptions));
+   final ListThrowableWithExtraContext 
exceptions) {
+super(getMessage(numTries, exceptions),
{code}

nit: ws

{code}
 for (Throwable t : exceptions) {
-  buffer.append(t.toString());
+  buffer.append(toString(t));
   buffer.append(\n);
 }
{code}

not: what's the reason for this change? Will {{toString}} avoid an NPE to which 
{{t.toString()}} is susceptible?

{code}
---
 T E S T S
---
Running org.apache.hadoop.hbase.security.access.TestAccessController
2013-01-16 09:07:57.810 java[47087:1203] Unable to load realm info from 
SCDynamicStore
Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.99 sec

Results :

Tests run: 34, Failures: 0, Errors: 0, Skipped: 0
{code}

Looks good to me. nits aside, +1

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Updated] (HBASE-7560) TestCompactionState failures


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

Matteo Bertozzi updated HBASE-7560:
---

Fix Version/s: 0.96.0

 TestCompactionState failures
 

 Key: HBASE-7560
 URL: https://issues.apache.org/jira/browse/HBASE-7560
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0, 0.94.4
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.96.0

 Attachments: HBASE-7560-v0.patch


 The TestCompactionState has a fixed waitTime for the compaction state, and on 
 a busy jenkins those tests fails.
 {code}
 java.lang.AssertionError: expected:NONE but was:MAJOR
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:147)
   at 
 org.apache.hadoop.hbase.regionserver.TestCompactionState.compaction(TestCompactionState.java:180)
   at 
 org.apache.hadoop.hbase.regionserver.TestCompactionState.testMajorCompaction(TestCompactionState.java:63)
 {code}

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

[jira] [Updated] (HBASE-7560) TestCompactionState failures


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

Matteo Bertozzi updated HBASE-7560:
---

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

committed to trunk without the extra comment

 TestCompactionState failures
 

 Key: HBASE-7560
 URL: https://issues.apache.org/jira/browse/HBASE-7560
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0, 0.94.4
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Attachments: HBASE-7560-v0.patch


 The TestCompactionState has a fixed waitTime for the compaction state, and on 
 a busy jenkins those tests fails.
 {code}
 java.lang.AssertionError: expected:NONE but was:MAJOR
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:147)
   at 
 org.apache.hadoop.hbase.regionserver.TestCompactionState.compaction(TestCompactionState.java:180)
   at 
 org.apache.hadoop.hbase.regionserver.TestCompactionState.testMajorCompaction(TestCompactionState.java:63)
 {code}

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

[jira] [Updated] (HBASE-7537) .regioninfo not created by createHRegion()


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

Matteo Bertozzi updated HBASE-7537:
---

Fix Version/s: 0.96.0

 .regioninfo not created by createHRegion()
 --

 Key: HBASE-7537
 URL: https://issues.apache.org/jira/browse/HBASE-7537
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 0.96.0
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.96.0

 Attachments: HBASE-7537-v0.patch


 After HBASE-5683 we have no longer the .regioninfo written on disk during the 
 table creation.
 so, if we fail before adding entries to .META. we end up with regions on disk 
 that has no information, and hbck is not able to recover this situation.
 The .regioninfo is written in checkRegioninfoOnFilesystem() that was called 
 by initialize(), during the table creation and region opening. With 
 HBASE-5683 we skip the call to initialize(), in during the region creation, 
 to avoid to initialize the memstore  co.

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

[jira] [Updated] (HBASE-7558) Client not able to access /hbase/unassigned in secure cluster


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

Matteo Bertozzi updated HBASE-7558:
---

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

 Client not able to access /hbase/unassigned in secure cluster
 -

 Key: HBASE-7558
 URL: https://issues.apache.org/jira/browse/HBASE-7558
 Project: HBase
  Issue Type: Sub-task
Affects Versions: 0.96.0, 0.94.4
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.96.0

 Attachments: HBASE-7558-v0.patch


 HBASE-6068, /hbase/unassigned is not listed as open node
 and catalogTracker tries to read from both: RootRegionTracker 
 (/hbase/root-region-server) and MetaNodeTracker (/hbase/unassigned)
 {code}
 Unable to get data of znode /hbase/unassigned/1028785192
 org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = 
 NoAuth for /hbase/unassigned/1028785192
 {code}

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

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order


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

nkeywal commented on HBASE-7581:


bq.  what's the reason for this change? Will toString avoid an NPE to which 
t.toString() is susceptible?
Actually it's stupid, I've just checked it does exactly what the default 
toString does. I was not getting the right info, but it was only because of the 
cause issue that I fixed at the same time. I'm going to fix this on commit.

Thanks for the review!

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Updated] (HBASE-7526) create table does not log the table name in audit log


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

Matteo Bertozzi updated HBASE-7526:
---

Fix Version/s: 0.96.0

 create table does not log the table name in audit log
 -

 Key: HBASE-7526
 URL: https://issues.apache.org/jira/browse/HBASE-7526
 Project: HBase
  Issue Type: Improvement
  Components: security
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Trivial
 Fix For: 0.96.0

 Attachments: HBASE-7526-v0.patch


 If I issue a create table command - create 'test', 'f1'
 Then from the audit log, there is no way to identify what table was created
 {code}
 request: createTable; context: (user=th30z, scope=GLOBAL, family=, 
 action=CREATE)
 {code}

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

[jira] [Updated] (HBASE-6386) Audit log messages do not include column family / qualifier information consistently


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

Matteo Bertozzi updated HBASE-6386:
---

Fix Version/s: 0.96.0

 Audit log messages do not include column family / qualifier information 
 consistently
 

 Key: HBASE-6386
 URL: https://issues.apache.org/jira/browse/HBASE-6386
 Project: HBase
  Issue Type: Improvement
  Components: security
Affects Versions: 0.96.0
Reporter: Marcelo Vanzin
Assignee: Matteo Bertozzi
 Fix For: 0.96.0

 Attachments: hbase-6386-v1.patch, hbase-6386-v2.patch, 
 HBASE-6386-v3.patch, HBASE-6386-v4.patch


 The code related to this issue is in 
 AccessController.java:permissionGranted().
 When creating audit logs, that method will do one of the following:
 * grant access, create audit log with table name only
 * deny access because of table permission, create audit log with table name 
 only
 * deny access because of column family / qualifier permission, create audit 
 log with specific family / qualifier
 So, in the case where more than one column family and/or qualifier are in the 
 same request, there will be a loss of information. Even in the case where 
 only one column family and/or qualifier is involved, information may be lost.
 It would be better if this behavior consistently included all the information 
 in the request; regardless of access being granted or denied, and regardless 
 which permission caused the denial, the column family and qualifier info 
 should be part of the audit log message.

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

[jira] [Updated] (HBASE-7581) TestAccessController depends on the execution order


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

nkeywal updated HBASE-7581:
---

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

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order


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

Andrew Purtell commented on HBASE-7581:
---

I ran into this yesterday and was trying to figure it out too, the bulk load 
test was the issue. I've been testing a local fix that looks like this one, +1.

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Comment Edited] (HBASE-7581) TestAccessController depends on the execution order


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

Andrew Purtell edited comment on HBASE-7581 at 1/16/13 5:33 PM:


I ran into this yesterday and was trying to figure it out too, the bulk load 
test was the issue. I've been testing a local fix that looks like this part, +1:

{noformat}
diff --git 
a/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
 
b/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
index 9b38eb7..3e14276 100644
--- 
a/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
+++ 
b/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
@@ -675,10 +675,9 @@ public class TestAccessController {
 // action for checkAndPut()
 PrivilegedExceptionAction checkAndPut = new PrivilegedExceptionAction() {
   public Object run() throws Exception {
+HTable t = new HTable(conf, TEST_TABLE);
 Put p = new Put(Bytes.toBytes(random_row));
 p.add(TEST_FAMILY, Bytes.toBytes(Qualifier), Bytes.toBytes(1));
-
-HTable t = new HTable(conf, TEST_TABLE);
 t.checkAndPut(Bytes.toBytes(random_row), TEST_FAMILY, 
Bytes.toBytes(q),
   Bytes.toBytes(test_value), p);
 return null;
@@ -711,6 +710,10 @@ public class TestAccessController {
   }
 };
 verifyWrite(bulkLoadAction);
+
+// Reinit after the bulk upload
+TEST_UTIL.getHBaseAdmin().disableTable(TEST_TABLE);
+TEST_UTIL.getHBaseAdmin().enableTable(TEST_TABLE);
   }
 
   public class BulkLoadHelper {
{noformat}

  was (Author: apurtell):
I ran into this yesterday and was trying to figure it out too, the bulk 
load test was the issue. I've been testing a local fix that looks like this 
one, +1.
  
 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order


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

Hadoop QA commented on HBASE-7581:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12565139/7581.v1.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 findbugs{color}.  The patch appears to introduce 2 new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   org.apache.hadoop.hbase.client.TestMultiParallel
  org.apache.hadoop.hbase.TestLocalHBaseCluster

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s):   
at 
org.apache.hadoop.hbase.util.TestHBaseFsck.testDupeRegion(TestHBaseFsck.java:580)

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/4046//console

This message is automatically generated.

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Created] (HBASE-7582) Unit test execution mode that randomizes test order

Andrew Purtell created HBASE-7582:
-

 Summary: Unit test execution mode that randomizes test order
 Key: HBASE-7582
 URL: https://issues.apache.org/jira/browse/HBASE-7582
 Project: HBase
  Issue Type: Improvement
  Components: test
Reporter: Andrew Purtell
Priority: Minor


I've also come around to agreeing with Jon Hseih that we should have a test 
mode that somehow randomizes test order to catch issues where unit test cases 
are written with the assumption of a certain order. It should not be on by 
default but can be enabled when evaluating patches for commit that include new 
tests.

Case in point is HBASE-7581, which seems to be due to a new test added in 
HBASE-5498. The patch on HBASE-5498 tested out all green in local tests prior 
to commit. 

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

[jira] [Commented] (HBASE-7581) TestAccessController depends on the execution order


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

Andrew Purtell commented on HBASE-7581:
---

See HBASE-7582 for additional followup.

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Commented] (HBASE-7582) Unit test execution mode that randomizes test order


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

Andrew Purtell commented on HBASE-7582:
---

I should say pseudorandomized with the ability to set the seed for 
repeatability. This may be a tall/impossible order. I'm not familiar with 
JUnit/Surefire internals sufficient.y 

 Unit test execution mode that randomizes test order
 ---

 Key: HBASE-7582
 URL: https://issues.apache.org/jira/browse/HBASE-7582
 Project: HBase
  Issue Type: Improvement
  Components: test
Reporter: Andrew Purtell
Priority: Minor

 I've also come around to agreeing with Jon Hseih that we should have a test 
 mode that somehow randomizes test order to catch issues where unit test cases 
 are written with the assumption of a certain order. It should not be on by 
 default but can be enabled when evaluating patches for commit that include 
 new tests.
 Case in point is HBASE-7581, which seems to be due to a new test added in 
 HBASE-5498. The patch on HBASE-5498 tested out all green in local tests prior 
 to commit. 

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

[jira] [Commented] (HBASE-6066) some low hanging read path improvement ideas


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

stack commented on HBASE-6066:
--

Patch looks good.  Are all listed items covered now?  What about the one Lars 
raises in 
https://issues.apache.org/jira/browse/HBASE-6066?focusedCommentId=13465982page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13465982?

Good stuff DD.

 some low hanging read path improvement ideas 
 -

 Key: HBASE-6066
 URL: https://issues.apache.org/jira/browse/HBASE-6066
 Project: HBase
  Issue Type: Sub-task
  Components: Performance
Reporter: Kannan Muthukkaruppan
Assignee: Michal Gregorczyk
Priority: Critical
  Labels: noob
 Fix For: 0.96.0

 Attachments: 
 0001-jira-HBASE-6066-89-fb-Some-read-performance-improvem.patch, 
 6066-rebased-1.patch, 6066-rebased-1.patch, metric-stringbuilder-fix.patch


 I was running some single threaded scan performance tests for a table with 
 small sized rows that is fully cached. Some observations...
 We seem to be doing several wasteful iterations over and/or building of 
 temporary lists.
 1) One such is the following code in HRegionServer.next():
 {code}
boolean moreRows = s.next(values, HRegion.METRIC_NEXTSIZE);
if (!values.isEmpty()) {
  for (KeyValue kv : values) {  --  wasteful in most 
 cases
currentScanResultSize += kv.heapSize();
}
results.add(new Result(values));
 {code}
 By default the maxScannerResultSize is Long.MAX_VALUE. In those cases,
 we can avoid the unnecessary iteration to compute currentScanResultSize.
 2) An example of a wasteful temporary array, is results in
 RegionScanner.next().
 {code}
   results.clear();
   boolean returnResult = nextInternal(limit, metric);
   outResults.addAll(results);
 {code}
 results then gets copied over to outResults via an addAll(). Not sure why we 
 can not directly collect the results in outResults.
 3) Another almost similar exmaple of a wasteful array is results in 
 StoreScanner.next(), which eventually also copies its results into 
 outResults.
 4) Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
   if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.
 5) RegionScanner.next() calls a helper RegionScanner.next() on the same 
 object. Both are synchronized methods. Synchronized methods calling nested 
 synchronized methods on the same object are probably adding some small 
 overhead. The inner next() calls isFilterDone() which is a also a 
 synchronized method. We should factor the code to avoid these nested 
 synchronized methods.

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

[jira] [Commented] (HBASE-6815) [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a single user mode


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

stack commented on HBASE-6815:
--

Nice.  I took a quick look.  Is this how hadoop is going to do its scripts?  
Add release note.  Looks like manual needs a new section on windows that 
includes/subsumes this page http://hbase.apache.org/cygwin.html.  Can be in 
different issue.  

 [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a 
 single user mode
 

 Key: HBASE-6815
 URL: https://issues.apache.org/jira/browse/HBASE-6815
 Project: HBase
  Issue Type: Sub-task
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Slavik Krassovsky
 Attachments: hbase-6815_v1.patch


 Provide .cmd scripts in order to start HBASE on Windows in a single user mode

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

[jira] [Commented] (HBASE-2611) Handle RS that fails while processing the failure of another one

2013-01-16 Thread Lars Hofhansl (JIRA)


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

Lars Hofhansl commented on HBASE-2611:
--

But that is not case (unless I am misunderstanding completely). All RSs race to 
get the lock to take over the dead RS's queues. Once there is a winner, that RS 
will move the queues. So if the winning RS dies after it learn that it is the 
winner but before it move the queues those queues are lost.

What you describe is one way to solve the problem: All RSs simply try to move 
the queues. That would work, but would lead to the herding effect (which I 
think is acceptable).


 Handle RS that fails while processing the failure of another one
 

 Key: HBASE-2611
 URL: https://issues.apache.org/jira/browse/HBASE-2611
 Project: HBase
  Issue Type: Sub-task
  Components: Replication
Reporter: Jean-Daniel Cryans
Assignee: Himanshu Vashishtha
 Fix For: 0.94.5

 Attachments: HBase-2611-upstream-v1.patch, HBASE-2611-v2.patch


 HBASE-2223 doesn't manage region servers that fail while doing the transfer 
 of HLogs queues from other region servers that failed. Devise a reliable way 
 to do it.

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

[jira] [Updated] (HBASE-5640) bulk load runs slowly than before


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

stack updated HBASE-5640:
-

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

Resolving dup of HBASE-6529 (Thanks [~anoopsamjohn] for pointing out the dup).

 bulk load runs slowly than before
 -

 Key: HBASE-5640
 URL: https://issues.apache.org/jira/browse/HBASE-5640
 Project: HBase
  Issue Type: Bug
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
  Labels: bulkloader
 Attachments: bulkLoadFs1.txt, bulkLoadFs2.txt


 I am loading data from an external system into hbase. There are many prints 
 of the form. This is possibly a regression caused by a recent patch.
 on different filesystem than destination store - moving to this filesystem

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

[jira] [Created] (HBASE-7583) Fixes and cleanups

Matteo Bertozzi created HBASE-7583:
--

 Summary: Fixes and cleanups
 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055




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

[jira] [Commented] (HBASE-7545) [replication] Break out TestReplication into manageable classes

2013-01-16 Thread Jean-Daniel Cryans (JIRA)


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

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

bq. I guess the small tests add up to be large ?

The tests are small, but do require 2 full clusters.

 [replication] Break out TestReplication into manageable classes
 ---

 Key: HBASE-7545
 URL: https://issues.apache.org/jira/browse/HBASE-7545
 Project: HBase
  Issue Type: Bug
Reporter: Jean-Daniel Cryans
Assignee: Jean-Daniel Cryans
 Fix For: 0.96.0

 Attachments: HBASE-7545.patch


 This has been discussed before but after trying to debug the last failure on 
 Jenkins where I saw the time go back and forth (if you don't care about your 
 own sanity do checkout 
 https://builds.apache.org/job/HBase-TRUNK/3726/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationWithCompression/testDeleteTypes/)
  I think it is time to break out TestReplication.
 The difficulty is that the setup for the 2 clusters is a lot of code I don't 
 want to duplicate. I'm thinking that we can keep {{setUpBeforeClass}} there 
 and have the other classes extend TestReplication (which should also change 
 name). I'm thinking of the following new classes:
  - TestReplicationSmallTests, contains the easy methods that don't mess 
 around too much.
  - TestReplicationQueueFailover, contains one test of the same name
  - TestReplicationDisableInactivePeer, contains one test of the same name
  - Rename TestReplicationWithCompression 
 TestReplicationQueueFailoverWithCompression and make it extends 
 TestReplicationQueueFailover.

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

[jira] [Commented] (HBASE-7582) Unit test execution mode that randomizes test order

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

nkeywal commented on HBASE-7582:

I don't think it's immediately available.

As far as I know, Surefire has a random order execution, but my understanding
is that it's on a per class basis, so it's not what we need.
Withing JUnit, it's likely possible to do what we want by writing a custom
runner, but it's not available in the core product (it may have been partly
implemented, but I'm not sure the seed would be there, even if it is a good
point).

The closest stuff I have, from what I understood but not tested, is to use
MethodSorters.JVM on a JDK 1.7: it will be random but without seed.

Unit test execution mode that randomizes test order
---

Key: HBASE-7582
URL: https://issues.apache.org/jira/browse/HBASE-7582
Project: HBase
Issue Type: Improvement
Components: test
Reporter: Andrew Purtell
Priority: Minor

I've also come around to agreeing with Jon Hseih that we should have a test
mode that somehow randomizes test order to catch issues where unit test cases
are written with the assumption of a certain order. It should not be on by
default but can be enabled when evaluating patches for commit that include
new tests.
Case in point is HBASE-7581, which seems to be due to a new test added in
HBASE-5498. The patch on HBASE-5498 tested out all green in local tests prior
to commit.

[jira] [Commented] (HBASE-7582) Unit test execution mode that randomizes test order


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

Andrew Purtell commented on HBASE-7582:
---

Thanks [~nkeywal]. I'll play around with this and if I come up with something 
useful will post a patch.

 Unit test execution mode that randomizes test order
 ---

 Key: HBASE-7582
 URL: https://issues.apache.org/jira/browse/HBASE-7582
 Project: HBase
  Issue Type: Improvement
  Components: test
Reporter: Andrew Purtell
Priority: Minor

 I've also come around to agreeing with Jon Hseih that we should have a test 
 mode that somehow randomizes test order to catch issues where unit test cases 
 are written with the assumption of a certain order. It should not be on by 
 default but can be enabled when evaluating patches for commit that include 
 new tests.
 Case in point is HBASE-7581, which seems to be due to a new test added in 
 HBASE-5498. The patch on HBASE-5498 tested out all green in local tests prior 
 to commit. 

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

[jira] [Commented] (HBASE-6815) [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a single user mode

2013-01-16 Thread Slavik Krassovsky (JIRA)


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

Slavik Krassovsky commented on HBASE-6815:
--

Thanks! Yes, the scripts are following of the hadoop's. We also don't need 
Cygwin to run (just need it to compile). Would add release notes.

 [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a 
 single user mode
 

 Key: HBASE-6815
 URL: https://issues.apache.org/jira/browse/HBASE-6815
 Project: HBase
  Issue Type: Sub-task
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Slavik Krassovsky
 Attachments: hbase-6815_v1.patch


 Provide .cmd scripts in order to start HBASE on Windows in a single user mode

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

[jira] [Commented] (HBASE-3890) Scheduled tasks in distributed log splitting not in sync with ZK


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

stack commented on HBASE-3890:
--

[~jeffreyz] Is the patch not for trunk J?

 Scheduled tasks in distributed log splitting not in sync with ZK
 

 Key: HBASE-3890
 URL: https://issues.apache.org/jira/browse/HBASE-3890
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.92.0
Reporter: Lars George
Assignee: Jeffrey Zhong
Priority: Critical
 Fix For: 0.96.0

 Attachments: hbase-3890.patch


 This is in continuation to HBASE-3889:
 Note that there must be more slightly off here. Although the splitlogs znode 
 is now empty the master is still stuck here:
 {noformat}
 Doing distributed log split in 
 hdfs://localhost:8020/hbase/.logs/10.0.0.65,60020,1305406356765
 - Waiting for distributed tasks to finish. scheduled=2 done=1 error=0   4380s
 Master startup
 - Splitting logs after master startup   4388s
 {noformat}
 There seems to be an issue with what is in ZK and what the TaskBatch holds. 
 In my case it could be related to the fact that the task was already in ZK 
 after many faulty restarts because of the NPE. Maybe it was added once (since 
 that is keyed by path, and that is unique on my machine), but the reference 
 count upped twice? Now that the real one is done, the done counter has been 
 increased, but will never match the scheduled.
 The code could also check if ZK is actually depleted, and therefore treat the 
 scheduled task as bogus? This of course only treats the symptom, not the root 
 cause of this condition. 

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

[jira] [Updated] (HBASE-6815) [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a single user mode

2013-01-16 Thread Slavik Krassovsky (JIRA)

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

Slavik Krassovsky updated HBASE-6815:
-

Release Note:
This patch contains windows scripts.

Right now the following is supported within the dev environment:

1. Getting version:
C:\apache_hbasebin\hbase.cmd version
13/01/15 22:28:22 INFO util.VersionInfo: HBase 0.95-SNAPSHOT
13/01/15 22:28:22 INFO util.VersionInfo: Subversion
file:///cygdrive/c/apache_hbase/hbase-server -r Unknown
13/01/15 22:28:22 INFO util.VersionInfo: Compiled by viatk on Tue Jan 15
10:27:11 PST 2013

2. Getting classpath:
C:\apache_hbasebin\hbase.cmd classpath

C:\apache_hbase\bin\..\conf;C:\hw\tools\java\lib\tools.jar;C:\Users\viatk\.m2\repository\asm\asm\3.1\asm-3.1.jar;C:\U...

3. Starting HBASE in standalone mode:
C:\apache_hbasebin\start-hbase.cmd
Would start hbase in a separate console app

4. Running hbase shell:
C:\apache_hbasebin\hbase.cmd shell
Would start hbase shell in a separate window.
One can create tables and put and scan data via shell there.

5. Stopping hbase:
C:\apache_hbasebin\stop-hbase.cmd
Would stop HBase.

You need set JAVA_HOME (either via env. varable or by modifying
conf\hbase-env.cmd)
Ex. C:\apache_hbaseset JAVA_HOME=C:\hw\tools\java

Please let me know if you run into issues!

Status: Patch Available (was: Open)

[WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a
single user mode

Key: HBASE-6815
URL: https://issues.apache.org/jira/browse/HBASE-6815
Project: HBase
Issue Type: Sub-task
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Slavik Krassovsky
Attachments: hbase-6815_v1.patch

Provide .cmd scripts in order to start HBASE on Windows in a single user mode

[jira] [Commented] (HBASE-7583) Fixes and cleanups


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

Matteo Bertozzi commented on HBASE-7583:


HBASE-7583.0
 * Remove an unused conf parameter from archiveRegion
 * Use SnapshotDescriptionUtils.toString() to dump the snapshot info
 * Possible NPE in list.addAll(), restore code


 Fixes and cleanups
 --

 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055

 Attachments: HBASE-7583.0-v0.patch




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

[jira] [Updated] (HBASE-7583) Fixes and cleanups


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

Matteo Bertozzi updated HBASE-7583:
---

Attachment: HBASE-7583.0-v0.patch

 Fixes and cleanups
 --

 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055

 Attachments: HBASE-7583.0-v0.patch




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

[jira] [Commented] (HBASE-3890) Scheduled tasks in distributed log splitting not in sync with ZK

2013-01-16 Thread Jeffrey Zhong (JIRA)

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

Jeffrey Zhong commented on HBASE-3890:
--

Let me recreate one. It may due to my local build isn't up to date.

Scheduled tasks in distributed log splitting not in sync with ZK

Key: HBASE-3890
URL: https://issues.apache.org/jira/browse/HBASE-3890
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.92.0
Reporter: Lars George
Assignee: Jeffrey Zhong
Priority: Critical
Fix For: 0.96.0

Attachments: hbase-3890.patch

This is in continuation to HBASE-3889:
Note that there must be more slightly off here. Although the splitlogs znode
is now empty the master is still stuck here:
{noformat}
Doing distributed log split in
hdfs://localhost:8020/hbase/.logs/10.0.0.65,60020,1305406356765
- Waiting for distributed tasks to finish. scheduled=2 done=1 error=0 4380s
Master startup
- Splitting logs after master startup 4388s
{noformat}
There seems to be an issue with what is in ZK and what the TaskBatch holds.
In my case it could be related to the fact that the task was already in ZK
after many faulty restarts because of the NPE. Maybe it was added once (since
that is keyed by path, and that is unique on my machine), but the reference
count upped twice? Now that the real one is done, the done counter has been
increased, but will never match the scheduled.
The code could also check if ZK is actually depleted, and therefore treat the
scheduled task as bogus? This of course only treats the symptom, not the root
cause of this condition.

[jira] [Created] (HBASE-7584) Improve TestAccessController.testAppend

Andrew Purtell created HBASE-7584:
-

 Summary: Improve TestAccessController.testAppend
 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: HBASE-7584.patch

TestAccessController#testAppend should call through HTable instead of invoking 
the CP hook directly.

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

[jira] [Updated] (HBASE-7584) Improve TestAccessController.testAppend


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

Andrew Purtell updated HBASE-7584:
--

Attachment: HBASE-7584.patch

 Improve TestAccessController.testAppend
 ---

 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: HBASE-7584.patch


 TestAccessController#testAppend should call through HTable instead of 
 invoking the CP hook directly.

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

[jira] [Updated] (HBASE-7584) Improve TestAccessController.testAppend


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

Andrew Purtell updated HBASE-7584:
--

Status: Patch Available  (was: Open)

 Improve TestAccessController.testAppend
 ---

 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: HBASE-7584.patch


 TestAccessController#testAppend should call through HTable instead of 
 invoking the CP hook directly.

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

[jira] [Commented] (HBASE-7584) Improve TestAccessController.testAppend


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

Andrew Purtell commented on HBASE-7584:
---

Test change passes locally.

 Improve TestAccessController.testAppend
 ---

 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: HBASE-7584.patch


 TestAccessController#testAppend should call through HTable instead of 
 invoking the CP hook directly.

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

[jira] [Commented] (HBASE-4246) Cluster with too many regions cannot withstand some master failover scenarios


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

stack commented on HBASE-4246:
--

I added a note to troubleshooting doc in the master startup section.

 Cluster with too many regions cannot withstand some master failover scenarios
 -

 Key: HBASE-4246
 URL: https://issues.apache.org/jira/browse/HBASE-4246
 Project: HBase
  Issue Type: Bug
  Components: master, Zookeeper
Affects Versions: 0.90.4
Reporter: Todd Lipcon
 Fix For: 0.96.0


 We ran into the following sequence of events:
 - master startup failed after only ROOT had been assigned (for another reason)
 - restarted the master without restarting other servers. Since there was at 
 least one region assigned, it went through the failover code path
 - master scanned META and inserted every region into /hbase/unassigned in ZK.
 - then, it called listChildren on the /hbase/unassigned znode, and crashed 
 with Packet len6080218 is out of range! since the IPC response was larger 
 than the default maximum.

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

[jira] [Commented] (HBASE-7584) Improve TestAccessController.testAppend


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

Sergey Shelukhin commented on HBASE-7584:
-

+1

 Improve TestAccessController.testAppend
 ---

 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: HBASE-7584.patch


 TestAccessController#testAppend should call through HTable instead of 
 invoking the CP hook directly.

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

[jira] [Commented] (HBASE-7584) Improve TestAccessController.testAppend


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

stack commented on HBASE-7584:
--

+1

Add table close on end (probably not necessary but...)

 Improve TestAccessController.testAppend
 ---

 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: HBASE-7584.patch


 TestAccessController#testAppend should call through HTable instead of 
 invoking the CP hook directly.

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

[jira] [Commented] (HBASE-6815) [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a single user mode

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

Hadoop QA commented on HBASE-6815:
--

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12565084/hbase-6815_v1.patch
against trunk revision .

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:red}-1 patch{color}. The patch command could not apply the patch.

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

This message is automatically generated.

[WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a
single user mode

Provide .cmd scripts in order to start HBASE on Windows in a single user mode

[jira] [Commented] (HBASE-7583) Fixes and cleanups


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

stack commented on HBASE-7583:
--

+1 if hadoopqa says no new javadoc or findbugs warnings.

 Fixes and cleanups
 --

 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055

 Attachments: HBASE-7583.0-v0.patch




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

[jira] [Created] (HBASE-7585) TestAccessController tests should close HTables

Andrew Purtell created HBASE-7585:
-

 Summary: TestAccessController tests should close HTables
 Key: HBASE-7585
 URL: https://issues.apache.org/jira/browse/HBASE-7585
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Trivial




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

[jira] [Commented] (HBASE-7584) Improve TestAccessController.testAppend


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

Andrew Purtell commented on HBASE-7584:
---

bq. Add table close on end (probably not necessary but...)

I was looking at that. All the cases could use updating with try {} finally { 
t.close() }. 

Will commit this now and follow up on HBASE-7585.

 Improve TestAccessController.testAppend
 ---

 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: HBASE-7584.patch


 TestAccessController#testAppend should call through HTable instead of 
 invoking the CP hook directly.

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

[jira] [Updated] (HBASE-7583) Fixes and cleanups


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

stack updated HBASE-7583:
-

Status: Patch Available  (was: Open)

Submitting patch (might not be what you want Matteo)?

 Fixes and cleanups
 --

 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055

 Attachments: HBASE-7583.0-v0.patch




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

[jira] [Commented] (HBASE-6815) [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a single user mode


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

stack commented on HBASE-6815:
--

Why did the patch fail to apply?  [~enis] Mr Windows Component Captain, would 
you +1 this?

 [WINDOWS] Provide hbase scripts in order to start HBASE on Windows in a 
 single user mode
 

 Key: HBASE-6815
 URL: https://issues.apache.org/jira/browse/HBASE-6815
 Project: HBase
  Issue Type: Sub-task
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Slavik Krassovsky
 Attachments: hbase-6815_v1.patch


 Provide .cmd scripts in order to start HBASE on Windows in a single user mode

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

[jira] [Updated] (HBASE-6752) On region server failure, serve writes and timeranged reads during the log split


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

nkeywal updated HBASE-6752:
---

Priority: Major  (was: Minor)

 On region server failure, serve writes and timeranged reads during the log 
 split
 

 Key: HBASE-6752
 URL: https://issues.apache.org/jira/browse/HBASE-6752
 Project: HBase
  Issue Type: Improvement
  Components: regionserver
Affects Versions: 0.96.0
Reporter: nkeywal

 Opening for write on failure would mean:
 - Assign the region to a new regionserver. It marks the region as recovering
   -- specific exception returned to the client when we cannot server.
   -- allow them to know where they stand. The exception can include some time 
 information (failure stated on: ...)
   -- allow them to go immediately on the right regionserver, instead of 
 retrying or calling the region holding meta to get the new address
  = save network calls, lower the load on meta.
 - Do the split as today. Priority is given to region server holding the new 
 regions
   -- help to share the load balancing code: the split is done by region 
 server considered as available for new regions
   -- help locality (the recovered edits are available on the region server) 
 = lower the network usage
 - When the split is finished, we're done as of today
 - while the split is progressing, the region server can
  -- serve writes
--- that's useful for all application that need to write but not read 
 immediately:
--- whatever logs events to analyze them later
--- opentsdb is a perfect example.   
  -- serve reads if they have a compatible time range. For heavily used 
 tables, it could be an help, because:
--- we can expect to have a few minutes of data only (as it's loaded)
--- the heaviest queries, often accepts a few -or more- minutes delay. 
 Some What if:
 1) the split fails
 = Retry until it works. As today. Just that we serves writes. We need to 
 know (as today) that the region has not recovered if we fail again.
 2) the regionserver fails during the split
 = As 1 and as of today/
 3) the regionserver fails after the split but before the state change to 
 fully available.
 = New assign. More logs to split (the ones already dones and the new ones).
 4) the assignment fails
 = Retry until it works. As today.

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

[jira] [Commented] (HBASE-7583) Fixes and cleanups


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

Matteo Bertozzi commented on HBASE-7583:


I don't think the QA is able to process this patch, since is based on the 
snapshot branch

 Fixes and cleanups
 --

 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055

 Attachments: HBASE-7583.0-v0.patch




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

[jira] [Commented] (HBASE-7563) move CompoundConfiguration to common and add string map support


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

Sergey Shelukhin commented on HBASE-7563:
-

[~enis] Can you please review? Should be relatively simple change (class moved, 
method added)

 move CompoundConfiguration to common and add string map support
 ---

 Key: HBASE-7563
 URL: https://issues.apache.org/jira/browse/HBASE-7563
 Project: HBase
  Issue Type: Sub-task
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
Priority: Minor
 Attachments: HBASE-7563-v0.patch


 Starting to split parts off HBASE-7236. This one should be easy.

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

[jira] [Commented] (HBASE-7583) Fixes and cleanups


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

Hadoop QA commented on HBASE-7583:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12565150/HBASE-7583.0-v0.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  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.

{color:red}-1 patch{color}.  The patch command could not apply the patch.

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

This message is automatically generated.

 Fixes and cleanups
 --

 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055

 Attachments: HBASE-7583.0-v0.patch




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

[jira] [Resolved] (HBASE-6140) Make distributed log splitting faster by changing call site of tmp log renaming

2013-01-16 Thread Devaraj Das (JIRA)


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

Devaraj Das resolved HBASE-6140.


Resolution: Duplicate

Isn't this handled in HBASE-6134. Feel free to reopen if otherwise.

 Make distributed log splitting faster by changing call site of tmp log 
 renaming
 ---

 Key: HBASE-6140
 URL: https://issues.apache.org/jira/browse/HBASE-6140
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu

 For 1 regions, current distributed log splitting took 22 minutes.
 After moving the tmp log renaming, we observed duration of 7 minutes.

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

[jira] [Commented] (HBASE-7382) Port ZK.multi support from HBASE-6775 to 0.96


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

stack commented on HBASE-7382:
--

[~enis] IMO, we cannot require that an hbase deploy force a zk ensemble update. 
 3.4 client will go against 3.3. ensemble except when 3.4 tries to do a multi 
([~gchanan] and crew wrote up in another issue about how we can't ask the 
ensemble if it 3.4 and even then, we want to be guard against case where one 
ensemble member is 3.4 but rest are 3.3 -- its ugly).  Or, you think we should 
add a prereq for 0.96?  That the ensemble be 3.4? (Meantime I added to the 
refguide a todo for explaining 3.4 and multi, etc.)

 Port ZK.multi support from HBASE-6775 to 0.96
 -

 Key: HBASE-7382
 URL: https://issues.apache.org/jira/browse/HBASE-7382
 Project: HBase
  Issue Type: Bug
  Components: Zookeeper
Reporter: Gregory Chanan
 Fix For: 0.96.0


 HBASE-6775 adds support for ZK.multi ZKUtil and uses it for the 0.92/0.94 
 compatibility fix implemented in HBASE-6710.
 ZK.multi support is most likely useful in 0.96, but since HBASE-6710 is not 
 relevant for 0.96, perhaps we should find another use case first before we 
 port.

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

[jira] [Reopened] (HBASE-7581) TestAccessController depends on the execution order


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

Andrew Purtell reopened HBASE-7581:
---


This needs to be applied to 0.94. Reopening to do so.

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0

 Attachments: 7581.v1.patch




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

[jira] [Resolved] (HBASE-7581) TestAccessController depends on the execution order


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

Andrew Purtell resolved HBASE-7581.
---

   Resolution: Fixed
Fix Version/s: 0.94.5

Committed to 0.94. TestAccessController change passes locally.

 TestAccessController depends on the execution order
 ---

 Key: HBASE-7581
 URL: https://issues.apache.org/jira/browse/HBASE-7581
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: nkeywal
 Fix For: 0.96.0, 0.94.5

 Attachments: 7581.v1.patch




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

[jira] [Updated] (HBASE-7584) Improve TestAccessController.testAppend


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

Andrew Purtell updated HBASE-7584:
--

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

Committed to trunk and 0.94 branch. Test change passes locally on both. Thanks 
for the quick review.

 Improve TestAccessController.testAppend
 ---

 Key: HBASE-7584
 URL: https://issues.apache.org/jira/browse/HBASE-7584
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.96.0, 0.94.5
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.96.0, 0.94.5

 Attachments: HBASE-7584.patch


 TestAccessController#testAppend should call through HTable instead of 
 invoking the CP hook directly.

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

[jira] [Commented] (HBASE-7583) Fixes and cleanups


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

stack commented on HBASE-7583:
--

[~mbertozzi] Ok.  +1 on commit.

 Fixes and cleanups
 --

 Key: HBASE-7583
 URL: https://issues.apache.org/jira/browse/HBASE-7583
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Affects Versions: hbase-6055
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Blocker
 Fix For: hbase-6055

 Attachments: HBASE-7583.0-v0.patch




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

[jira] [Commented] (HBASE-6737) NullPointerException at regionserver.wal.SequenceFileLogWriter.append


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

Sergey Shelukhin commented on HBASE-6737:
-

sorry, maybe not, caller still has to handle the IOException

 NullPointerException at regionserver.wal.SequenceFileLogWriter.append
 -

 Key: HBASE-6737
 URL: https://issues.apache.org/jira/browse/HBASE-6737
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 0.96.0
Reporter: nkeywal
Priority: Critical

 Real cluster, scenario in HBASE-5843.
 There are two exceptions, I create a single JIRA with both of them.
 2012-09-04 18:14:49,264 FATAL 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter: WriterThread-1 Got 
 while writing log entry to log
 java.io.IOException: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.append(SequenceFileLogWriter.java:229)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:949)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:919)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:891)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.io.SequenceFile$Writer.checkAndWriteSync(SequenceFile.java:1026)
   at 
 org.apache.hadoop.io.SequenceFile$Writer.append(SequenceFile.java:1068)
   at 
 org.apache.hadoop.io.SequenceFile$Writer.append(SequenceFile.java:1035)
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.append(SequenceFileLogWriter.java:226)
   ... 3 more
 2012-09-04 18:15:52,546 ERROR 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter: Error in log splitting 
 write thread
 java.lang.reflect.UndeclaredThrowableException
   at $Proxy7.getFileInfo(Unknown Source)
   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:875)
   at 
 org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:513)
   at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:768)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getRegionSplitEditsPath(HLogSplitter.java:559)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.createWAP(HLogSplitter.java:974)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.access$800(HLogSplitter.java:82)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$OutputSink.getWriterAndPath(HLogSplitter.java:1309)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:942)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:919)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:891)
 Caused by: java.lang.reflect.InvocationTargetException
   at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.hadoop.hbase.fs.HFileSystem$1.invoke(HFileSystem.java:261)
   ... 11 more
 Caused by: java.io.IOException: Call to BOX1/192.168.15.5:9000 failed on 
 local exception: java.nio.channels.ClosedByInterruptException
   at org.apache.hadoop.ipc.Client.wrapException(Client.java:1107)
   at org.apache.hadoop.ipc.Client.call(Client.java:1075)
   at org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:225)
   at $Proxy7.getFileInfo(Unknown Source)
   at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:82)
   at 
 org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:59)
   at $Proxy7.getFileInfo(Unknown Source)
   ... 15 more
 Caused by: java.nio.channels.ClosedByInterruptException
   at 
 java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:184)
   at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:341)
   at 
 org.apache.hadoop.net.SocketOutputStream$Writer.performIO(SocketOutputStream.java:55)
   at 
 org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:142)
   at 
 org.apache.hadoop.net.SocketOutputStream.write(SocketOutputStream.java:146)
   at

[jira] [Assigned] (HBASE-6737) NullPointerException at regionserver.wal.SequenceFileLogWriter.append


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

Sergey Shelukhin reassigned HBASE-6737:
---

Assignee: Sergey Shelukhin

 NullPointerException at regionserver.wal.SequenceFileLogWriter.append
 -

 Key: HBASE-6737
 URL: https://issues.apache.org/jira/browse/HBASE-6737
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: Sergey Shelukhin
Priority: Critical

 Real cluster, scenario in HBASE-5843.
 There are two exceptions, I create a single JIRA with both of them.
 2012-09-04 18:14:49,264 FATAL 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter: WriterThread-1 Got 
 while writing log entry to log
 java.io.IOException: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.append(SequenceFileLogWriter.java:229)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:949)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:919)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:891)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.io.SequenceFile$Writer.checkAndWriteSync(SequenceFile.java:1026)
   at 
 org.apache.hadoop.io.SequenceFile$Writer.append(SequenceFile.java:1068)
   at 
 org.apache.hadoop.io.SequenceFile$Writer.append(SequenceFile.java:1035)
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.append(SequenceFileLogWriter.java:226)
   ... 3 more
 2012-09-04 18:15:52,546 ERROR 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter: Error in log splitting 
 write thread
 java.lang.reflect.UndeclaredThrowableException
   at $Proxy7.getFileInfo(Unknown Source)
   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:875)
   at 
 org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:513)
   at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:768)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getRegionSplitEditsPath(HLogSplitter.java:559)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.createWAP(HLogSplitter.java:974)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.access$800(HLogSplitter.java:82)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$OutputSink.getWriterAndPath(HLogSplitter.java:1309)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:942)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:919)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:891)
 Caused by: java.lang.reflect.InvocationTargetException
   at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.hadoop.hbase.fs.HFileSystem$1.invoke(HFileSystem.java:261)
   ... 11 more
 Caused by: java.io.IOException: Call to BOX1/192.168.15.5:9000 failed on 
 local exception: java.nio.channels.ClosedByInterruptException
   at org.apache.hadoop.ipc.Client.wrapException(Client.java:1107)
   at org.apache.hadoop.ipc.Client.call(Client.java:1075)
   at org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:225)
   at $Proxy7.getFileInfo(Unknown Source)
   at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:82)
   at 
 org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:59)
   at $Proxy7.getFileInfo(Unknown Source)
   ... 15 more
 Caused by: java.nio.channels.ClosedByInterruptException
   at 
 java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:184)
   at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:341)
   at 
 org.apache.hadoop.net.SocketOutputStream$Writer.performIO(SocketOutputStream.java:55)
   at 
 org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:142)
   at 
 org.apache.hadoop.net.SocketOutputStream.write(SocketOutputStream.java:146)
   at 
 org.apache.hadoop.net.SocketOutputStream.write(SocketOutputStream.java:107)
   at

[jira] [Updated] (HBASE-4451) Improve zk node naming (/hbase/shutdown)


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

stack updated HBASE-4451:
-

  Resolution: Fixed
Release Note: The 'shutdown' znode was renamed 'running'.
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Committed to trunk.  It does not look like this issue responsible for the 
findbugs warning.  Will look into that over in another issue.

 Improve zk node naming (/hbase/shutdown)
 

 Key: HBASE-4451
 URL: https://issues.apache.org/jira/browse/HBASE-4451
 Project: HBase
  Issue Type: Improvement
  Components: master
Affects Versions: 0.94.0
Reporter: Harsh J
Assignee: Devaraj Das
Priority: Critical
  Labels: noob
 Fix For: 0.96.0

 Attachments: 4451-1.patch


 Right now the node {{/hbase/shutdown}} is used to indicate cluster status 
 (cluster up, cluster down).
 However, upon a chat with Lars George today, we feel that having a name 
 {{/hbase/shutdown}} is possibly bad. The {{/hbase/shutdown}} zknode contains 
 a date when the cluster was _started_. Now that is difficult to understand 
 and digest, given that a person may connect to zk and try to look at what it 
 is about (they may think it 'shutdown' at that date.).
 I feel a better name may simply be: {{/hbase/running}}. Thoughts?

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

[jira] [Commented] (HBASE-7575) FSUtils#getTableStoreFilePathMap should all ignore non-table folders


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

Hudson commented on HBASE-7575:
---

Integrated in HBase-0.94 #740 (See 
[https://builds.apache.org/job/HBase-0.94/740/])
HBASE-7575 FSUtils#getTableStoreFilePathMap should all ignore non-table 
folders (Revision 1434021)

 Result = SUCCESS
jxiang : 
Files : 
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/HConstants.java
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java


 FSUtils#getTableStoreFilePathMap should all ignore non-table folders
 

 Key: HBASE-7575
 URL: https://issues.apache.org/jira/browse/HBASE-7575
 Project: HBase
  Issue Type: Bug
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
 Fix For: 0.96.0, 0.94.5

 Attachments: trunk_7575.patch, trunk_7575_v2.patch


 Currently it just ignores .log.  It should ignore all non-table folders.

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

[jira] [Updated] (HBASE-3890) Scheduled tasks in distributed log splitting not in sync with ZK

2013-01-16 Thread Jeffrey Zhong (JIRA)

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

Jeffrey Zhong updated HBASE-3890:
-

Attachment: hbase-3890_1.patch

Recreate the patch after updating my local code.

Thanks,
-Jeffrey

Scheduled tasks in distributed log splitting not in sync with ZK

Attachments: hbase-3890_1.patch, hbase-3890.patch

[jira] [Commented] (HBASE-6066) some low hanging read path improvement ideas

2013-01-16 Thread Devaraj Das (JIRA)


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

Devaraj Das commented on HBASE-6066:


I think I have covered all the listed items. On the one Lars raised (about 
Result's kv field), I haven't. Let me check if i can do that in this issue.

 some low hanging read path improvement ideas 
 -

 Key: HBASE-6066
 URL: https://issues.apache.org/jira/browse/HBASE-6066
 Project: HBase
  Issue Type: Sub-task
  Components: Performance
Reporter: Kannan Muthukkaruppan
Assignee: Michal Gregorczyk
Priority: Critical
  Labels: noob
 Fix For: 0.96.0

 Attachments: 
 0001-jira-HBASE-6066-89-fb-Some-read-performance-improvem.patch, 
 6066-rebased-1.patch, 6066-rebased-1.patch, metric-stringbuilder-fix.patch


 I was running some single threaded scan performance tests for a table with 
 small sized rows that is fully cached. Some observations...
 We seem to be doing several wasteful iterations over and/or building of 
 temporary lists.
 1) One such is the following code in HRegionServer.next():
 {code}
boolean moreRows = s.next(values, HRegion.METRIC_NEXTSIZE);
if (!values.isEmpty()) {
  for (KeyValue kv : values) {  --  wasteful in most 
 cases
currentScanResultSize += kv.heapSize();
}
results.add(new Result(values));
 {code}
 By default the maxScannerResultSize is Long.MAX_VALUE. In those cases,
 we can avoid the unnecessary iteration to compute currentScanResultSize.
 2) An example of a wasteful temporary array, is results in
 RegionScanner.next().
 {code}
   results.clear();
   boolean returnResult = nextInternal(limit, metric);
   outResults.addAll(results);
 {code}
 results then gets copied over to outResults via an addAll(). Not sure why we 
 can not directly collect the results in outResults.
 3) Another almost similar exmaple of a wasteful array is results in 
 StoreScanner.next(), which eventually also copies its results into 
 outResults.
 4) Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
   if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.
 5) RegionScanner.next() calls a helper RegionScanner.next() on the same 
 object. Both are synchronized methods. Synchronized methods calling nested 
 synchronized methods on the same object are probably adding some small 
 overhead. The inner next() calls isFilterDone() which is a also a 
 synchronized method. We should factor the code to avoid these nested 
 synchronized methods.

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

[jira] [Commented] (HBASE-7575) FSUtils#getTableStoreFilePathMap should all ignore non-table folders


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

Hudson commented on HBASE-7575:
---

Integrated in HBase-TRUNK #3758 (See 
[https://builds.apache.org/job/HBase-TRUNK/3758/])
HBASE-7575 FSUtils#getTableStoreFilePathMap should all ignore non-table 
folders (Revision 1434010)

 Result = FAILURE
jxiang : 
Files : 
* 
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java


 FSUtils#getTableStoreFilePathMap should all ignore non-table folders
 

 Key: HBASE-7575
 URL: https://issues.apache.org/jira/browse/HBASE-7575
 Project: HBase
  Issue Type: Bug
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
 Fix For: 0.96.0, 0.94.5

 Attachments: trunk_7575.patch, trunk_7575_v2.patch


 Currently it just ignores .log.  It should ignore all non-table folders.

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

[jira] [Commented] (HBASE-6737) NullPointerException at regionserver.wal.SequenceFileLogWriter.append


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

Sergey Shelukhin commented on HBASE-6737:
-

[~nkeywal] Hi, is it possible to repro the former case, or get more logs? From 
cursory look it appears that the writers are only closed after some attempt to 
stop writer threads in HLogSplitter. Were there errors stopping writer threads?

 NullPointerException at regionserver.wal.SequenceFileLogWriter.append
 -

 Key: HBASE-6737
 URL: https://issues.apache.org/jira/browse/HBASE-6737
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 0.96.0
Reporter: nkeywal
Assignee: Sergey Shelukhin
Priority: Critical

 Real cluster, scenario in HBASE-5843.
 There are two exceptions, I create a single JIRA with both of them.
 2012-09-04 18:14:49,264 FATAL 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter: WriterThread-1 Got 
 while writing log entry to log
 java.io.IOException: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.append(SequenceFileLogWriter.java:229)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:949)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:919)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:891)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.io.SequenceFile$Writer.checkAndWriteSync(SequenceFile.java:1026)
   at 
 org.apache.hadoop.io.SequenceFile$Writer.append(SequenceFile.java:1068)
   at 
 org.apache.hadoop.io.SequenceFile$Writer.append(SequenceFile.java:1035)
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogWriter.append(SequenceFileLogWriter.java:226)
   ... 3 more
 2012-09-04 18:15:52,546 ERROR 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter: Error in log splitting 
 write thread
 java.lang.reflect.UndeclaredThrowableException
   at $Proxy7.getFileInfo(Unknown Source)
   at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:875)
   at 
 org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:513)
   at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:768)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getRegionSplitEditsPath(HLogSplitter.java:559)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.createWAP(HLogSplitter.java:974)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.access$800(HLogSplitter.java:82)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$OutputSink.getWriterAndPath(HLogSplitter.java:1309)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.writeBuffer(HLogSplitter.java:942)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.doRun(HLogSplitter.java:919)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter$WriterThread.run(HLogSplitter.java:891)
 Caused by: java.lang.reflect.InvocationTargetException
   at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.hadoop.hbase.fs.HFileSystem$1.invoke(HFileSystem.java:261)
   ... 11 more
 Caused by: java.io.IOException: Call to BOX1/192.168.15.5:9000 failed on 
 local exception: java.nio.channels.ClosedByInterruptException
   at org.apache.hadoop.ipc.Client.wrapException(Client.java:1107)
   at org.apache.hadoop.ipc.Client.call(Client.java:1075)
   at org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:225)
   at $Proxy7.getFileInfo(Unknown Source)
   at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:82)
   at 
 org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:59)
   at $Proxy7.getFileInfo(Unknown Source)
   ... 15 more
 Caused by: java.nio.channels.ClosedByInterruptException
   at 
 java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:184)
   at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:341)
   at 
 org.apache.hadoop.net.SocketOutputStream$Writer.performIO(SocketOutputStream.java:55)
   at

[jira] [Commented] (HBASE-7560) TestCompactionState failures


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

Hudson commented on HBASE-7560:
---

Integrated in HBase-TRUNK #3758 (See 
[https://builds.apache.org/job/HBase-TRUNK/3758/])
HBASE-7560 TestCompactionState failures (Revision 1434045)

 Result = FAILURE
mbertozzi : 
Files : 
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompactionState.java


 TestCompactionState failures
 

 Key: HBASE-7560
 URL: https://issues.apache.org/jira/browse/HBASE-7560
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0, 0.94.4
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.96.0

 Attachments: HBASE-7560-v0.patch


 The TestCompactionState has a fixed waitTime for the compaction state, and on 
 a busy jenkins those tests fails.
 {code}
 java.lang.AssertionError: expected:NONE but was:MAJOR
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:147)
   at 
 org.apache.hadoop.hbase.regionserver.TestCompactionState.compaction(TestCompactionState.java:180)
   at 
 org.apache.hadoop.hbase.regionserver.TestCompactionState.testMajorCompaction(TestCompactionState.java:63)
 {code}

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

[jira] [Commented] (HBASE-7387) StoreScanner need to be able to be subclassed


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

stack commented on HBASE-7387:
--

[~colorant] I should have made it clear that there were no guarantees 
subclassing StoreScanner, that it could change under you given StoreScanner has 
the Private annotation (as per [~tlipcon] comment).

 StoreScanner need to be able to be subclassed
 -

 Key: HBASE-7387
 URL: https://issues.apache.org/jira/browse/HBASE-7387
 Project: HBase
  Issue Type: Improvement
  Components: regionserver
Affects Versions: 0.96.0
Reporter: Raymond Liu
Assignee: Raymond Liu
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE_7387_v2.patch, StoreScanner.patch


 StoreScanner can be replaced by preStoreScannerOpen hook with CP. In order to 
 reuse most of the logic in current StoreScanner, subclass it might be the 
 best approaching. Thus a lot of private member need to be changed from 
 private to protected.
 At present, in order to to implement a custom storescanner for dot 
 (HBASE-6805), only a few of the private member need to be changed as in the 
 attached storescanner.patch, while should we change all the reasonable field 
 from private to protected as in HBASE-7387-v?.patch

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

[jira] [Updated] (HBASE-7213) Have HLog files for .META. and -ROOT- edits only

2013-01-16 Thread Devaraj Das (JIRA)


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

Devaraj Das updated HBASE-7213:
---

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

 Have HLog files for .META. and -ROOT- edits only
 

 Key: HBASE-7213
 URL: https://issues.apache.org/jira/browse/HBASE-7213
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Reporter: Devaraj Das
Assignee: Devaraj Das
Priority: Critical
 Fix For: 0.96.0

 Attachments: 7213-15.patch, 7213-2.10.patch, 7213-2.11.patch, 
 7213-2.12.patch, 7213-2.14.patch, 7213-2.14.patch, 7213-2.16.patch, 
 7213-2.4.patch, 7213-2.6.patch, 7213-2.8.patch, 7213-2.9.patch, 
 7213-addendum.patch, 7213-in-progress.2.2.patch, 7213-in-progress.2.patch, 
 7213-in-progress.patch, 7213v13.txt, 
 TEST-org.apache.hadoop.hbase.client.TestMultiParallel.xml


 Over on HBASE-6774, there is a discussion on separating out the edits for 
 .META. regions from the other regions' edits w.r.t where the edits are 
 written. This jira is to track an implementation of that.

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

[jira] [Created] (HBASE-7586) Fix two findbugs warnings to get our count down to the tolerated number again

stack created HBASE-7586:


 Summary: Fix two findbugs warnings to get our count down to the 
tolerated number again
 Key: HBASE-7586
 URL: https://issues.apache.org/jira/browse/HBASE-7586
 Project: HBase
  Issue Type: Bug
Reporter: stack
 Attachments: two-findbugs-fixes.txt



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

[jira] [Updated] (HBASE-7503) Add exists(List) in HTableInterface to allow multiple parallel exists at one time


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

Jean-Marc Spaggiari updated HBASE-7503:
---

Status: Open  (was: Patch Available)

 Add exists(List) in HTableInterface to allow multiple parallel exists at one 
 time
 -

 Key: HBASE-7503
 URL: https://issues.apache.org/jira/browse/HBASE-7503
 Project: HBase
  Issue Type: Improvement
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Minor
 Fix For: 0.96.0

 Attachments: HBASE-7503-v0-trunk.patch, HBASE-7503-v1-trunk.patch, 
 HBASE-7503-v2-trunk.patch, HBASE-7503-v2-trunk.patch, 
 HBASE-7503-v3-trunk.patch, HBASE-7503-v4-trunk.patch, 
 HBASE-7503-v5-trunk.patch, HBASE-7503-v7-trunk.patch, 
 HBASE-7503-v8-trunk.patch

   Original Estimate: 5m
  Remaining Estimate: 5m

 We need to have a Boolean[] exists(ListGet gets) throws IOException method 
 implemented in HTableInterface.

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

[jira] [Commented] (HBASE-7584) Improve TestAccessController.testAppend