[jira] [Commented] (HBASE-4710) HBaseRPC$UnknownProtocolException should abort any client retries in HConnectionManager

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-4710:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12501734/HBASE-4710.patch
  against trunk revision .

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

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

-1 javadoc.  The javadoc tool appears to have generated -166 warning 
messages.

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

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

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

 -1 core tests.  The patch failed these unit tests:
   
org.apache.hadoop.hbase.master.TestDistributedLogSplitting
  org.apache.hadoop.hbase.master.TestMasterFailover

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

This message is automatically generated.

> HBaseRPC$UnknownProtocolException should abort any client retries in 
> HConnectionManager
> ---
>
> Key: HBASE-4710
> URL: https://issues.apache.org/jira/browse/HBASE-4710
> Project: HBase
>  Issue Type: Bug
>  Components: coprocessors
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 0.92.0
>
> Attachments: HBASE-4710.patch
>
>
> While {{HBaseRPC$UnknownProtocolException}} currently extends 
> {{DoNotRetryIOException}}, it's still allowing retries of client RPCs when 
> encountered in {{HConnectionManager.getRegionServerWithRetries()}}.  It turns 
> out that {{UnknownProtocolException}} is missing a public constructor taking 
> a single {{String}} argument, which is required when unwrapping an 
> {{IOException}} from a {{RemoteException}} in 
> {{RemoteExceptionHandler.decodeRemoteException()}}.

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

[jira] [Commented] (HBASE-4277) HRS.closeRegion should be able to close regions with only the encoded name

[ramkrishna.s.vasudevan (Commented) (JIRA)]

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

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

Tests passes...
{code}
  
testClockSkewDetection(org.apache.hadoop.hbase.master.TestClockSkewDetection): 
hostname can't be null
  testScanner(org.apache.hadoop.hbase.regionserver.TestScanner): hostname can't 
be null
{code}
This failure is not due to the patch for this JIRA.



> HRS.closeRegion should be able to close regions with only the encoded name
> --
>
> Key: HBASE-4277
> URL: https://issues.apache.org/jira/browse/HBASE-4277
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.4
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.90.5
>
> Attachments: HBASE-4277_0.90.patch
>
>
> As suggested by Stack in HBASE-4217 creating a new issue to provide a patch 
> for 0.90.x version.
> We had some sort of an outage this morning due to a few racks losing power, 
> and some regions were left in the following state:
> ERROR: Region UNKNOWN_REGION on sv4r17s9:60020, 
> key=e32bbe1f48c9b3633c557dc0291b90a3, not on HDFS or in META but deployed on 
> sv4r17s9:60020
> That region was deleted by the master but the region server never got the 
> memo. Right now there's no way to force close it because HRS.closeRegion 
> requires an HRI and the only way to create one is to get it from .META. which 
> in our case doesn't contain a row for that region. Basically we have to wait 
> until that server is dead to get rid of the region and make hbck happy.
> The required change is to have closeRegion accept an encoded name in both HBA 
> (when the RS address is provided) and HRS since it's able to find it anyways 
> from it's list of live regions.
> bq.If a 0.90 version, we maybe should do that in another issue.

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

[jira] [Commented] (HBASE-4711) Remove jsr jar; not needed

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-4711:
--

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

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

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

-1 javadoc.  The javadoc tool appears to have generated -166 warning 
messages.

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

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

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

 -1 core tests.  The patch failed these unit tests:
   
org.apache.hadoop.hbase.master.TestDistributedLogSplitting
  org.apache.hadoop.hbase.replication.TestReplication
  org.apache.hadoop.hbase.master.TestMasterFailover
  org.apache.hadoop.hbase.regionserver.wal.TestLogRolling

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

This message is automatically generated.

> Remove jsr jar; not needed
> --
>
> Key: HBASE-4711
> URL: https://issues.apache.org/jira/browse/HBASE-4711
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 0.92.0
>
> Attachments: jsr.txt
>
>
> From Kan, jsr classes are in the jersey core jar.  I tried a build with it 
> removed and all tests pass.

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

[jira] [Commented] (HBASE-4695) WAL logs get deleted before region server can fully flush

[stack (Commented) (JIRA)]

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

stack commented on HBASE-4695:
--

@Jack Thanks boss for taking it for a spin.

> WAL logs get deleted before region server can fully flush
> -
>
> Key: HBASE-4695
> URL: https://issues.apache.org/jira/browse/HBASE-4695
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.90.4
>Reporter: jack levin
>Assignee: gaojinchao
>Priority: Blocker
> Fix For: 0.92.0, 0.90.5
>
> Attachments: HBASE-4695_Branch90_V2.patch, HBASE-4695_Trunk_V2.patch, 
> HBASE-4695_branch90_trial.patch, hbase-4695-0.92.txt
>
>
> To replicate the problem do the following:
> 1. check /hbase/.logs/ directory to see if you have WAL logs for the 
> region server you are shutting down.
> 2. executing kill  (where pid is a regionserver pid)
> 3. Watch the regionserver log to start flushing, you will see how many 
> regions are left to flush:
> 09:36:54,665 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 489 regions to close
> 09:56:35,779 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 116 regions to close
> 4. Check /hbase/.logs/ -- you will notice that it has dissapeared.
> 5. Check namenode logs:
> 09:26:41,607 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit: 
> ugi=root ip=/10.101.1.5 cmd=delete 
> src=/hbase/.logs/rdaa5.prod.imageshack.com,60020,1319749
> Note that, if you kill -9 the RS now, and it crashes on flush, you won't have 
> any WAL logs to replay.  We need to make sure that logs are deleted or moved 
> out only when RS has fully flushed. Otherwise its possible to lose data.

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

[jira] [Commented] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[stack (Commented) (JIRA)]

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

stack commented on HBASE-4553:
--

Retried upload to rb (Sorry for the no diff LarsH).

> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, 4553-v9.txt, 
> HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Commented] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-4553:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2656/
---

Review request for hbase.


Summary
---

Retry.


This addresses bug hbase-4553.
https://issues.apache.org/jira/browse/hbase-4553


Diffs
-


Diff: https://reviews.apache.org/r/2656/diff


Testing
---


Thanks,

Michael



> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, 4553-v9.txt, 
> HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Commented] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-4553:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2656/
---

(Updated 2011-11-01 05:47:41.332884)


Review request for hbase.


Summary
---

Retry.


This addresses bug hbase-4553.
https://issues.apache.org/jira/browse/hbase-4553


Diffs (updated)
-

  src/main/java/org/apache/hadoop/hbase/HConstants.java 943b774 
  src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java 46ca765 
  src/main/java/org/apache/hadoop/hbase/master/handler/CreateTableHandler.java 
b9d4b90 
  src/main/java/org/apache/hadoop/hbase/util/FSTableDescriptors.java 24570c9 
  src/main/java/org/apache/hadoop/hbase/util/FSUtils.java 36d90c3 
  src/main/java/org/apache/hadoop/hbase/util/HMerge.java a6f6b69 
  src/main/java/org/apache/hadoop/hbase/util/Merge.java 3aa980f 
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java 1cfeea8 
  src/test/java/org/apache/hadoop/hbase/TestFSTableDescriptorForceCreation.java 
8404d1b 
  src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java 49bcf02 
  src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionInfo.java 
b2cb233 
  src/test/java/org/apache/hadoop/hbase/util/TestFSTableDescriptors.java 
8fce6ec 
  src/test/java/org/apache/hadoop/hbase/util/TestFSUtils.java 1ad30e6 
  src/test/java/org/apache/hadoop/hbase/util/TestMergeTable.java ffc8d9d 
  src/test/java/org/apache/hadoop/hbase/util/TestMergeTool.java 88dc9de 

Diff: https://reviews.apache.org/r/2656/diff


Testing
---


Thanks,

Michael



> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, 4553-v9.txt, 
> HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Updated] (HBASE-4703) Improvements in tests

[stack (Updated) (JIRA)]

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

stack updated HBASE-4703:
-

  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Committed branch and trunk.  Thanks for the patch nkeyway.  Want to write a few 
notes in another issue and we can stick your pattern going forward writing 
tests into the manual.  Good stuff.

> Improvements in tests
> -
>
> Key: HBASE-4703
> URL: https://issues.apache.org/jira/browse/HBASE-4703
> Project: HBase
>  Issue Type: Improvement
>  Components: test
>Affects Versions: 0.92.0
> Environment: all
>Reporter: nkeywal
>Assignee: nkeywal
>Priority: Minor
> Fix For: 0.92.0
>
> Attachments: 20111030_4703_all.patch, 20111030_4703_all.v2.patch, 
> 20111030_4703_all.v3.patch, 20111030_4703_all.v4.patch
>
>
> Global:
>  - when possible, make the test using the default cluster configuration for 
> the number of region (1 instead of 2 or 3). This allows a faster stop/start, 
> and is a step toward a shared cluster configuration.
>  - 'sleep': lower or remove the sleep based synchronisation in the tests (in 
> HBaseTestingUtility, TestGlobalMemStoreSize, TestAdmin, 
> TestCoprocessorEndpoint, TestHFileOutputFormat, TestLruBlockCache, 
> TestServerCustomProtocol, TestReplicationSink)
>   - Optimize 'put' by setting setWriteToWAL to false, when the 'put' is big 
> or in a loop. Not done for tests that rely on the WAL.
>  
> Local issues:
> - TestTableInputFormatScan fully deletes the hadoop.tmp.dir directory on 
> tearDown, that makes it impossible to use in // with another test using this 
> directory
> - TestIdLock logs too much (9000 lines per seconds). Test time lowered to 15 
> seconds to make it a part of the small subset
> - TestMemoryBoundedLogMessageBuffer useless System.out.println
> - io.hfile.TestReseekTo useless System.out.println
> - TestTableInputFormat does not shutdown the cluster
> - testGlobalMemStore does not shutdown the cluster
> - rest.client.TestRemoteAdmin: simplified, does not use local admin, single 
> test instead of two.
> - HBaseTestingUtility#ensureSomeRegionServersAvailable starts only one 
> server, should start the number of missing server instead.
> - TestMergeTool should starts/stops the dfs cluster with HBaseTestingUtility

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

[jira] [Updated] (HBASE-3680) Publish more metrics about mslab

[stack (Updated) (JIRA)]

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

stack updated HBASE-3680:
-

Status: Patch Available  (was: Open)

> Publish more metrics about mslab
> 
>
> Key: HBASE-3680
> URL: https://issues.apache.org/jira/browse/HBASE-3680
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 0.90.1
>Reporter: Jean-Daniel Cryans
>Assignee: Todd Lipcon
> Fix For: 0.92.0
>
> Attachments: hbase-3680.txt, hbase-3680.txt
>
>
> We have been using mslab on all our clusters for a while now and it seems it 
> tends to OOME or send us into GC loops of death a lot more than it used to. 
> For example, one RS with mslab enabled and 7GB of heap died out of OOME this 
> afternoon; it had .55GB in the block cache and 2.03GB in the memstores which 
> doesn't account for much... but it could be that because of mslab a lot of 
> space was lost in those incomplete 2MB blocks and without metrics we can't 
> really tell. Compactions were running at the time of the OOME and I see block 
> cache activity. The average load on that cluster is 531.
> We should at least publish the total size of all those blocks and maybe even 
> take actions based on that (like force flushing).

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

[jira] [Updated] (HBASE-3680) Publish more metrics about mslab

[stack (Updated) (JIRA)]

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

stack updated HBASE-3680:
-

Attachment: hbase-3680.txt

Reuploading same patch so can get patch build to work.

> Publish more metrics about mslab
> 
>
> Key: HBASE-3680
> URL: https://issues.apache.org/jira/browse/HBASE-3680
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 0.90.1
>Reporter: Jean-Daniel Cryans
>Assignee: Todd Lipcon
> Fix For: 0.92.0
>
> Attachments: hbase-3680.txt, hbase-3680.txt
>
>
> We have been using mslab on all our clusters for a while now and it seems it 
> tends to OOME or send us into GC loops of death a lot more than it used to. 
> For example, one RS with mslab enabled and 7GB of heap died out of OOME this 
> afternoon; it had .55GB in the block cache and 2.03GB in the memstores which 
> doesn't account for much... but it could be that because of mslab a lot of 
> space was lost in those incomplete 2MB blocks and without metrics we can't 
> really tell. Compactions were running at the time of the OOME and I see block 
> cache activity. The average load on that cluster is 531.
> We should at least publish the total size of all those blocks and maybe even 
> take actions based on that (like force flushing).

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

[jira] [Updated] (HBASE-3680) Publish more metrics about mslab

[stack (Updated) (JIRA)]

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

stack updated HBASE-3680:
-

Status: Open  (was: Patch Available)

> Publish more metrics about mslab
> 
>
> Key: HBASE-3680
> URL: https://issues.apache.org/jira/browse/HBASE-3680
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 0.90.1
>Reporter: Jean-Daniel Cryans
>Assignee: Todd Lipcon
> Fix For: 0.92.0
>
> Attachments: hbase-3680.txt, hbase-3680.txt
>
>
> We have been using mslab on all our clusters for a while now and it seems it 
> tends to OOME or send us into GC loops of death a lot more than it used to. 
> For example, one RS with mslab enabled and 7GB of heap died out of OOME this 
> afternoon; it had .55GB in the block cache and 2.03GB in the memstores which 
> doesn't account for much... but it could be that because of mslab a lot of 
> space was lost in those incomplete 2MB blocks and without metrics we can't 
> really tell. Compactions were running at the time of the OOME and I see block 
> cache activity. The average load on that cluster is 531.
> We should at least publish the total size of all those blocks and maybe even 
> take actions based on that (like force flushing).

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

[jira] [Commented] (HBASE-4710) HBaseRPC$UnknownProtocolException should abort any client retries in HConnectionManager

[stack (Commented) (JIRA)]

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

stack commented on HBASE-4710:
--

+1 on patch.

> HBaseRPC$UnknownProtocolException should abort any client retries in 
> HConnectionManager
> ---
>
> Key: HBASE-4710
> URL: https://issues.apache.org/jira/browse/HBASE-4710
> Project: HBase
>  Issue Type: Bug
>  Components: coprocessors
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 0.92.0
>
> Attachments: HBASE-4710.patch
>
>
> While {{HBaseRPC$UnknownProtocolException}} currently extends 
> {{DoNotRetryIOException}}, it's still allowing retries of client RPCs when 
> encountered in {{HConnectionManager.getRegionServerWithRetries()}}.  It turns 
> out that {{UnknownProtocolException}} is missing a public constructor taking 
> a single {{String}} argument, which is required when unwrapping an 
> {{IOException}} from a {{RemoteException}} in 
> {{RemoteExceptionHandler.decodeRemoteException()}}.

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

[jira] [Updated] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[stack (Updated) (JIRA)]

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

stack updated HBASE-4553:
-

Status: Patch Available  (was: Open)

> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, 4553-v9.txt, 
> HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Updated] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[stack (Updated) (JIRA)]

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

stack updated HBASE-4553:
-

Status: Open  (was: Patch Available)

> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, 4553-v9.txt, 
> HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Updated] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[stack (Updated) (JIRA)]

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

stack updated HBASE-4553:
-

Attachment: 4553-v9.txt

Add back creating of files in .tmp dir so we don't have partials if crash.

> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, 4553-v9.txt, 
> HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Commented] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Marek Sapota (Commented) (JIRA)]

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

Marek Sapota commented on HBASE-4611:
-

It is possible to get context with the web interface, just upload a diff file 
generated with all the context that you need (for example `git diff -U `.  
This is exactly what Arcanist does for you with `arc diff`.

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
>Assignee: Nicolas Spiegelberg
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Assigned] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Nicolas Spiegelberg (Assigned) (JIRA)]

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

Nicolas Spiegelberg reassigned HBASE-4611:
--

Assignee: Nicolas Spiegelberg

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
>Assignee: Nicolas Spiegelberg
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Updated] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-4611:
---

Comment: was deleted

(was: stack has commented on the revision "[jira] [HBASE-4611] Add support for 
Phabricator/Differential as an alternative code review tool".

  I thing this change is really awesome

REVISION DETAIL
  https://reviews.facebook.net/D21
)

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Updated] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-4611:
---

Comment: was deleted

(was: nspiegelberg requested code review of "[jira] [HBASE-4611] Add support 
for Phabricator/Differential as an alternative code review tool".
Reviewers: DUMMY_REVIEWER

  Adding more awesome

  From http://phabricator.org/";>http://phabricator.org/ : 
"Phabricator is a open source collection of web applications which make it 
easier to write, review, and share source code. It is currently available as an 
early release. Phabricator was developed at Facebook."

  It's open source so pretty much anyone could host an instance of this 
software.

  To begin with, there will be a public-facing instance located at http://reviews.facebook.net";>http://reviews.facebook.net (sponsored 
by Facebook and hosted by the OSUOSL http://osuosl.org";>http://osuosl.org).

  We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
support that will allow us to do code reviews with Phabricator for HBase.

TEST PLAN
  EMPTY

REVISION DETAIL
  http://reviews.facebook.net/D21

AFFECTED FILES
  CHANGES.txt

MANAGE HERALD DIFFERENTIAL RULES
  http://reviews.facebook.net/herald/view/differential/

WHY DID I GET THIS EMAIL?
  http://reviews.facebook.net/herald/transcript/51/

Tip: use the X-Herald-Rules header to filter Herald messages in your client.
)

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Commented] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4611:


nspiegelberg has abandoned the revision "[jira] [HBASE-4611] Add support for 
Phabricator/Differential as an alternative code review tool".

REVISION DETAIL
  https://reviews.facebook.net/D21


> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Updated] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-4611:
---

Comment: was deleted

(was: stack has commented on the revision "[jira] [HBASE-4611] Add support for 
Phabricator/Differential as an alternative code review tool".

  I thing this change is really awesome

REVISION DETAIL
  https://reviews.facebook.net/D21
)

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Commented] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4611:


nspiegelberg has abandoned the revision "[jira] [HBASE-4611] Add support for 
Phabricator/Differential as an alternative code review tool".

REVISION DETAIL
  https://reviews.facebook.net/D21


> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Commented] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Nicolas Spiegelberg (Commented) (JIRA)]

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

Nicolas Spiegelberg commented on HBASE-4611:


After we checkin D153, we need to make a help wiki similar to Hive's

https://cwiki.apache.org/confluence/display/Hive/PhabricatorCodeReview

The main difference is that 'ant arc-setup' becomes 'mvn initialize -Darc'.  
Note that arc is not a required tool.  You can create a diff by uploading a raw 
diff file ( https://reviews.facebook.net/differential/diff/create/ ).  'arc' is 
just a command line tool that we use to get stuff done faster.  Currently, only 
'arc diff' will show you the context around your diff, which is super-nice.  
Working with Marek to get feature parity here on patch upload.

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Updated] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Nicolas Spiegelberg (Updated) (JIRA)]

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

Nicolas Spiegelberg updated HBASE-4611:
---

Comment: was deleted

(was: nspiegelberg requested code review of "[jira] [HBASE-4611] Add support 
for Phabricator/Differential as an alternative code review tool".
Reviewers: DUMMY_REVIEWER

  Adding more awesome

  From http://phabricator.org/";>http://phabricator.org/ : 
"Phabricator is a open source collection of web applications which make it 
easier to write, review, and share source code. It is currently available as an 
early release. Phabricator was developed at Facebook."

  It's open source so pretty much anyone could host an instance of this 
software.

  To begin with, there will be a public-facing instance located at http://reviews.facebook.net";>http://reviews.facebook.net (sponsored 
by Facebook and hosted by the OSUOSL http://osuosl.org";>http://osuosl.org).

  We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
support that will allow us to do code reviews with Phabricator for HBase.

TEST PLAN
  EMPTY

REVISION DETAIL
  http://reviews.facebook.net/D21

AFFECTED FILES
  CHANGES.txt

MANAGE HERALD DIFFERENTIAL RULES
  http://reviews.facebook.net/herald/view/differential/

WHY DID I GET THIS EMAIL?
  http://reviews.facebook.net/herald/transcript/51/

Tip: use the X-Herald-Rules header to filter Herald messages in your client.
)

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Updated] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[Phabricator (Updated) (JIRA)]

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

Phabricator updated HBASE-4611:
---

Attachment: D153.1.patch

nspiegelberg requested code review of "[jira] [HBASE-4611] Add support for 
Phabricator/Differential as an alternative code review tool".
Reviewers: stack, JIRA

  Add maven task to setup an arc client & provide a good initial
  default configuration.

TEST PLAN
   - mvn initialize -Darc

REVISION DETAIL
  https://reviews.facebook.net/D153

AFFECTED FILES
  .arcconfig
  .gitignore
  pom.xml


> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D153.1.patch, D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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

[jira] [Commented] (HBASE-4583) Integrate RWCC with Append and Increment operations

[Lars Hofhansl (Commented) (JIRA)]

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

Lars Hofhansl commented on HBASE-4583:
--

TestSplitLogWorker passes locally with patch applied.

> Integrate RWCC with Append and Increment operations
> ---
>
> Key: HBASE-4583
> URL: https://issues.apache.org/jira/browse/HBASE-4583
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 0.94.0
>
> Attachments: 4583-v2.txt, 4583-v3.txt, 4583-v4.txt, 4583.txt
>
>
> Currently Increment and Append operations do not work with RWCC and hence a 
> client could see the results of multiple such operation mixed in the same 
> Get/Scan.
> The semantics might be a bit more interesting here as upsert adds and removes 
> to and from the memstore.

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

[jira] [Commented] (HBASE-4695) WAL logs get deleted before region server can fully flush

[jack levin (Commented) (JIRA)]

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

jack levin commented on HBASE-4695:
---

I confirmed that this fix is working on my cluster, when I shutdown
the region server, the logs are moved to .oldlogs only after the RS
fully shuts down.

-Jack

On Mon, Oct 31, 2011 at 7:20 PM, Hadoop QA (Commented) (JIRA)


> WAL logs get deleted before region server can fully flush
> -
>
> Key: HBASE-4695
> URL: https://issues.apache.org/jira/browse/HBASE-4695
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.90.4
>Reporter: jack levin
>Assignee: gaojinchao
>Priority: Blocker
> Fix For: 0.92.0, 0.90.5
>
> Attachments: HBASE-4695_Branch90_V2.patch, HBASE-4695_Trunk_V2.patch, 
> HBASE-4695_branch90_trial.patch, hbase-4695-0.92.txt
>
>
> To replicate the problem do the following:
> 1. check /hbase/.logs/ directory to see if you have WAL logs for the 
> region server you are shutting down.
> 2. executing kill  (where pid is a regionserver pid)
> 3. Watch the regionserver log to start flushing, you will see how many 
> regions are left to flush:
> 09:36:54,665 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 489 regions to close
> 09:56:35,779 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 116 regions to close
> 4. Check /hbase/.logs/ -- you will notice that it has dissapeared.
> 5. Check namenode logs:
> 09:26:41,607 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit: 
> ugi=root ip=/10.101.1.5 cmd=delete 
> src=/hbase/.logs/rdaa5.prod.imageshack.com,60020,1319749
> Note that, if you kill -9 the RS now, and it crashes on flush, you won't have 
> any WAL logs to replay.  We need to make sure that logs are deleted or moved 
> out only when RS has fully flushed. Otherwise its possible to lose data.

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

[jira] [Commented] (HBASE-4583) Integrate RWCC with Append and Increment operations

[Ted Yu (Commented) (JIRA)]

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

Ted Yu commented on HBASE-4583:
---

I don't see 'Too many open files' in 
https://builds.apache.org/job/PreCommit-HBASE-Build/108//testReport/org.apache.hadoop.hbase.regionserver/TestSplitLogWorker/testAcquireTaskAtStartup/

> Integrate RWCC with Append and Increment operations
> ---
>
> Key: HBASE-4583
> URL: https://issues.apache.org/jira/browse/HBASE-4583
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 0.94.0
>
> Attachments: 4583-v2.txt, 4583-v3.txt, 4583-v4.txt, 4583.txt
>
>
> Currently Increment and Append operations do not work with RWCC and hence a 
> client could see the results of multiple such operation mixed in the same 
> Get/Scan.
> The semantics might be a bit more interesting here as upsert adds and removes 
> to and from the memstore.

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

[jira] [Commented] (HBASE-3025) Coprocessor based simple access control

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-3025:
--



bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
 line 192
bq.  > 
bq.  >
bq.  > Debug logging should go to LOG not AUDITLOG
bq.  
bq.  Gary Helmling wrote:
bq.  The idea was that all authorization decisions should be separated into 
audit log.  Here we're allowing access, so AUDITLOG seemed to make sense.  I 
agree that this still needs to be cleaned up a lot.  Maybe all audit logging 
should be done up in requirePermission() with authorization result?  At the 
very least we need a consistent format and consistent logging levels for 
messages (trace, right?).
bq.  
bq.  Andrew Purtell wrote:
bq.  > Maybe all audit logging should be done up in requirePermission() 
with authorization result?
bq.  
bq.  Sounds good.
bq.  
bq.  > At the very least we need a consistent format and consistent logging 
levels for messages (trace, right?).
bq.  
bq.  I'd argue for TRACE
bq.  
bq.  Gary Helmling wrote:
bq.  Reworked the audit logging to happen in requirePermission(), so we get 
a single log message per auth check indicating success or failure, with a more 
consistent format.  Result is logged to AUDITLOG at trace level.
bq.  
bq.  Michael Stack wrote:
bq.  Is there TRACE level in our commons interface?  I believe it just maps 
to DEBUG?

Commons-logging source for 1.1.1 claims that with log4j >= 1.2.12, trace level 
is supported.  Prior to that it's mapped to debug.


- Gary


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2041/#review2077
---


On 2011-11-01 00:26:37, Gary Helmling wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/2041/
bq.  ---
bq.  
bq.  (Updated 2011-11-01 00:26:37)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  This patch implements access control list based authorization of HBase 
operations.  The patch depends on the currently posted patch for HBASE-2742 
(secure RPC engine).
bq.  
bq.  Key parts of the implementation are:
bq.  
bq.  * AccessControlLists - encapsulates storage of permission grants in a 
metadata table ("_acl_").  This differs from previous implementation where the 
".META." table was used to store permissions.
bq.  
bq.  * AccessController - 
bq.- implements MasterObserver and RegionObserver, performing authorization 
checks in each of the preXXX() hooks.  If authorization fails, an 
AccessDeniedException is thrown.
bq.- implements AccessControllerProtocol as a coprocessor endpoint to 
provide RPC methods for granting, revoking and listing permissions.
bq.  
bq.  * ZKPermissionWatcher (and TableAuthManager) - synchronizes ACL entries 
and updates throughout the cluster nodes using ZK.  ACL entries are stored in 
per-table znodes as /hbase/acl/tablename.
bq.  
bq.  * Additional ruby shell scripts providing the "grant", "revoke" and 
"user_permission" commands
bq.  
bq.  * Support for a new OWNER attribute in HTableDescriptor.  I could separate 
out this change into a new JIRA for discussion, but I don't see it as currently 
useful outside of security.  Alternately, I could handle the OWNER attribute 
completely in AccessController without changing HTD, but that would make 
interaction via hbase shell a bit uglier.
bq.  
bq.  
bq.  This addresses bug HBASE-3025.
bq.  https://issues.apache.org/jira/browse/HBASE-3025
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlFilter.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControllerProtocol.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/Permission.java 
PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/TablePermission.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/UserPermission.java
 PRE-CRE

[jira] [Commented] (HBASE-4710) HBaseRPC$UnknownProtocolException should abort any client retries in HConnectionManager

[Ted Yu (Commented) (JIRA)]

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

Ted Yu commented on HBASE-4710:
---

+1 on patch.

> HBaseRPC$UnknownProtocolException should abort any client retries in 
> HConnectionManager
> ---
>
> Key: HBASE-4710
> URL: https://issues.apache.org/jira/browse/HBASE-4710
> Project: HBase
>  Issue Type: Bug
>  Components: coprocessors
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 0.92.0
>
> Attachments: HBASE-4710.patch
>
>
> While {{HBaseRPC$UnknownProtocolException}} currently extends 
> {{DoNotRetryIOException}}, it's still allowing retries of client RPCs when 
> encountered in {{HConnectionManager.getRegionServerWithRetries()}}.  It turns 
> out that {{UnknownProtocolException}} is missing a public constructor taking 
> a single {{String}} argument, which is required when unwrapping an 
> {{IOException}} from a {{RemoteException}} in 
> {{RemoteExceptionHandler.decodeRemoteException()}}.

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

[jira] [Updated] (HBASE-4710) HBaseRPC$UnknownProtocolException should abort any client retries in HConnectionManager

[Gary Helmling (Updated) (JIRA)]

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

Gary Helmling updated HBASE-4710:
-

Attachment: HBASE-4710.patch

Simple patch adding the requisite constructor.

> HBaseRPC$UnknownProtocolException should abort any client retries in 
> HConnectionManager
> ---
>
> Key: HBASE-4710
> URL: https://issues.apache.org/jira/browse/HBASE-4710
> Project: HBase
>  Issue Type: Bug
>  Components: coprocessors
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Gary Helmling
> Fix For: 0.92.0
>
> Attachments: HBASE-4710.patch
>
>
> While {{HBaseRPC$UnknownProtocolException}} currently extends 
> {{DoNotRetryIOException}}, it's still allowing retries of client RPCs when 
> encountered in {{HConnectionManager.getRegionServerWithRetries()}}.  It turns 
> out that {{UnknownProtocolException}} is missing a public constructor taking 
> a single {{String}} argument, which is required when unwrapping an 
> {{IOException}} from a {{RemoteException}} in 
> {{RemoteExceptionHandler.decodeRemoteException()}}.

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

[jira] [Updated] (HBASE-4710) HBaseRPC$UnknownProtocolException should abort any client retries in HConnectionManager

[Gary Helmling (Updated) (JIRA)]

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

Gary Helmling updated HBASE-4710:
-

Fix Version/s: 0.92.0
 Assignee: Gary Helmling
   Status: Patch Available  (was: Open)

> HBaseRPC$UnknownProtocolException should abort any client retries in 
> HConnectionManager
> ---
>
> Key: HBASE-4710
> URL: https://issues.apache.org/jira/browse/HBASE-4710
> Project: HBase
>  Issue Type: Bug
>  Components: coprocessors
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 0.92.0
>
> Attachments: HBASE-4710.patch
>
>
> While {{HBaseRPC$UnknownProtocolException}} currently extends 
> {{DoNotRetryIOException}}, it's still allowing retries of client RPCs when 
> encountered in {{HConnectionManager.getRegionServerWithRetries()}}.  It turns 
> out that {{UnknownProtocolException}} is missing a public constructor taking 
> a single {{String}} argument, which is required when unwrapping an 
> {{IOException}} from a {{RemoteException}} in 
> {{RemoteExceptionHandler.decodeRemoteException()}}.

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

[jira] [Updated] (HBASE-4711) Remove jsr jar; not needed

[stack (Updated) (JIRA)]

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

stack updated HBASE-4711:
-

Attachment: jsr.txt

> Remove jsr jar; not needed
> --
>
> Key: HBASE-4711
> URL: https://issues.apache.org/jira/browse/HBASE-4711
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 0.92.0
>
> Attachments: jsr.txt
>
>
> From Kan, jsr classes are in the jersey core jar.  I tried a build with it 
> removed and all tests pass.

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

[jira] [Updated] (HBASE-4711) Remove jsr jar; not needed

[stack (Updated) (JIRA)]

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

stack updated HBASE-4711:
-

Status: Patch Available  (was: Open)

> Remove jsr jar; not needed
> --
>
> Key: HBASE-4711
> URL: https://issues.apache.org/jira/browse/HBASE-4711
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 0.92.0
>
> Attachments: jsr.txt
>
>
> From Kan, jsr classes are in the jersey core jar.  I tried a build with it 
> removed and all tests pass.

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

[jira] [Created] (HBASE-4711) Remove jsr jar; not needed

[stack (Created) (JIRA)]

Remove jsr jar; not needed
--

 Key: HBASE-4711
 URL: https://issues.apache.org/jira/browse/HBASE-4711
 Project: HBase
  Issue Type: Task
Reporter: stack
Assignee: stack
 Fix For: 0.92.0


>From Kan, jsr classes are in the jersey core jar.  I tried a build with it 
>removed and all tests pass.

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

[jira] [Commented] (HBASE-3025) Coprocessor based simple access control

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-3025:
--



bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
 line 192
bq.  > 
bq.  >
bq.  > Debug logging should go to LOG not AUDITLOG
bq.  
bq.  Gary Helmling wrote:
bq.  The idea was that all authorization decisions should be separated into 
audit log.  Here we're allowing access, so AUDITLOG seemed to make sense.  I 
agree that this still needs to be cleaned up a lot.  Maybe all audit logging 
should be done up in requirePermission() with authorization result?  At the 
very least we need a consistent format and consistent logging levels for 
messages (trace, right?).
bq.  
bq.  Andrew Purtell wrote:
bq.  > Maybe all audit logging should be done up in requirePermission() 
with authorization result?
bq.  
bq.  Sounds good.
bq.  
bq.  > At the very least we need a consistent format and consistent logging 
levels for messages (trace, right?).
bq.  
bq.  I'd argue for TRACE
bq.  
bq.  Gary Helmling wrote:
bq.  Reworked the audit logging to happen in requirePermission(), so we get 
a single log message per auth check indicating success or failure, with a more 
consistent format.  Result is logged to AUDITLOG at trace level.

Is there TRACE level in our commons interface?  I believe it just maps to DEBUG?


- Michael


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2041/#review2077
---


On 2011-11-01 00:26:37, Gary Helmling wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/2041/
bq.  ---
bq.  
bq.  (Updated 2011-11-01 00:26:37)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  This patch implements access control list based authorization of HBase 
operations.  The patch depends on the currently posted patch for HBASE-2742 
(secure RPC engine).
bq.  
bq.  Key parts of the implementation are:
bq.  
bq.  * AccessControlLists - encapsulates storage of permission grants in a 
metadata table ("_acl_").  This differs from previous implementation where the 
".META." table was used to store permissions.
bq.  
bq.  * AccessController - 
bq.- implements MasterObserver and RegionObserver, performing authorization 
checks in each of the preXXX() hooks.  If authorization fails, an 
AccessDeniedException is thrown.
bq.- implements AccessControllerProtocol as a coprocessor endpoint to 
provide RPC methods for granting, revoking and listing permissions.
bq.  
bq.  * ZKPermissionWatcher (and TableAuthManager) - synchronizes ACL entries 
and updates throughout the cluster nodes using ZK.  ACL entries are stored in 
per-table znodes as /hbase/acl/tablename.
bq.  
bq.  * Additional ruby shell scripts providing the "grant", "revoke" and 
"user_permission" commands
bq.  
bq.  * Support for a new OWNER attribute in HTableDescriptor.  I could separate 
out this change into a new JIRA for discussion, but I don't see it as currently 
useful outside of security.  Alternately, I could handle the OWNER attribute 
completely in AccessController without changing HTD, but that would make 
interaction via hbase shell a bit uglier.
bq.  
bq.  
bq.  This addresses bug HBASE-3025.
bq.  https://issues.apache.org/jira/browse/HBASE-3025
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlFilter.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControllerProtocol.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/Permission.java 
PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/TablePermission.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/UserPermission.java
 PRE-CREATION 
bq.
security/src/main/java/org/apache/hadoop/hbase/security/access/ZKPermissionWatcher.java
 PRE-CREATION 
bq.
security/src/test/java/org/apache/hadoop/hba

[jira] [Commented] (HBASE-4695) WAL logs get deleted before region server can fully flush

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-4695:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12501720/HBASE-4695_Branch90_V2.patch
  against trunk revision .

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

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

-1 patch.  The patch command could not apply the patch.

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

This message is automatically generated.

> WAL logs get deleted before region server can fully flush
> -
>
> Key: HBASE-4695
> URL: https://issues.apache.org/jira/browse/HBASE-4695
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.90.4
>Reporter: jack levin
>Assignee: gaojinchao
>Priority: Blocker
> Fix For: 0.92.0, 0.90.5
>
> Attachments: HBASE-4695_Branch90_V2.patch, HBASE-4695_Trunk_V2.patch, 
> HBASE-4695_branch90_trial.patch, hbase-4695-0.92.txt
>
>
> To replicate the problem do the following:
> 1. check /hbase/.logs/ directory to see if you have WAL logs for the 
> region server you are shutting down.
> 2. executing kill  (where pid is a regionserver pid)
> 3. Watch the regionserver log to start flushing, you will see how many 
> regions are left to flush:
> 09:36:54,665 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 489 regions to close
> 09:56:35,779 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 116 regions to close
> 4. Check /hbase/.logs/ -- you will notice that it has dissapeared.
> 5. Check namenode logs:
> 09:26:41,607 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit: 
> ugi=root ip=/10.101.1.5 cmd=delete 
> src=/hbase/.logs/rdaa5.prod.imageshack.com,60020,1319749
> Note that, if you kill -9 the RS now, and it crashes on flush, you won't have 
> any WAL logs to replay.  We need to make sure that logs are deleted or moved 
> out only when RS has fully flushed. Otherwise its possible to lose data.

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

[jira] [Commented] (HBASE-4695) WAL logs get deleted before region server can fully flush

[gaojinchao (Commented) (JIRA)]

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

gaojinchao commented on HBASE-4695:
---

@jack
I made a patch for branch90. This patch has a little change,you can merge this 
change to your version.
Because our network of laboratories alse failure, so I can't verify this. 
sorry.


> WAL logs get deleted before region server can fully flush
> -
>
> Key: HBASE-4695
> URL: https://issues.apache.org/jira/browse/HBASE-4695
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.90.4
>Reporter: jack levin
>Assignee: gaojinchao
>Priority: Blocker
> Fix For: 0.92.0, 0.90.5
>
> Attachments: HBASE-4695_Branch90_V2.patch, HBASE-4695_Trunk_V2.patch, 
> HBASE-4695_branch90_trial.patch, hbase-4695-0.92.txt
>
>
> To replicate the problem do the following:
> 1. check /hbase/.logs/ directory to see if you have WAL logs for the 
> region server you are shutting down.
> 2. executing kill  (where pid is a regionserver pid)
> 3. Watch the regionserver log to start flushing, you will see how many 
> regions are left to flush:
> 09:36:54,665 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 489 regions to close
> 09:56:35,779 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 116 regions to close
> 4. Check /hbase/.logs/ -- you will notice that it has dissapeared.
> 5. Check namenode logs:
> 09:26:41,607 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit: 
> ugi=root ip=/10.101.1.5 cmd=delete 
> src=/hbase/.logs/rdaa5.prod.imageshack.com,60020,1319749
> Note that, if you kill -9 the RS now, and it crashes on flush, you won't have 
> any WAL logs to replay.  We need to make sure that logs are deleted or moved 
> out only when RS has fully flushed. Otherwise its possible to lose data.

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

[jira] [Updated] (HBASE-4695) WAL logs get deleted before region server can fully flush

[gaojinchao (Updated) (JIRA)]

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

gaojinchao updated HBASE-4695:
--

Attachment: HBASE-4695_Branch90_V2.patch

> WAL logs get deleted before region server can fully flush
> -
>
> Key: HBASE-4695
> URL: https://issues.apache.org/jira/browse/HBASE-4695
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.90.4
>Reporter: jack levin
>Assignee: gaojinchao
>Priority: Blocker
> Fix For: 0.92.0, 0.90.5
>
> Attachments: HBASE-4695_Branch90_V2.patch, HBASE-4695_Trunk_V2.patch, 
> HBASE-4695_branch90_trial.patch, hbase-4695-0.92.txt
>
>
> To replicate the problem do the following:
> 1. check /hbase/.logs/ directory to see if you have WAL logs for the 
> region server you are shutting down.
> 2. executing kill  (where pid is a regionserver pid)
> 3. Watch the regionserver log to start flushing, you will see how many 
> regions are left to flush:
> 09:36:54,665 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 489 regions to close
> 09:56:35,779 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 116 regions to close
> 4. Check /hbase/.logs/ -- you will notice that it has dissapeared.
> 5. Check namenode logs:
> 09:26:41,607 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit: 
> ugi=root ip=/10.101.1.5 cmd=delete 
> src=/hbase/.logs/rdaa5.prod.imageshack.com,60020,1319749
> Note that, if you kill -9 the RS now, and it crashes on flush, you won't have 
> any WAL logs to replay.  We need to make sure that logs are deleted or moved 
> out only when RS has fully flushed. Otherwise its possible to lose data.

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

[jira] [Commented] (HBASE-4304) requestsPerSecond counter stuck at 0

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4304:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4304 requestsPerSecond counter stuck at 0

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/metrics/MetricsRate.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/metrics/TestMetricsMBeanBase.java


> requestsPerSecond counter stuck at 0
> 
>
> Key: HBASE-4304
> URL: https://issues.apache.org/jira/browse/HBASE-4304
> Project: HBase
>  Issue Type: Bug
>  Components: master, regionserver
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Li Pi
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 4304v1.txt, 4304v2.txt, 4304v3.txt, 4304v4.txt
>
>
> Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 
> both in the master UI and in the RS UI. The writeRequestsCount metric is 
> properly updating in the RS UI.

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

[jira] [Commented] (HBASE-4300) Start of new-version master fails if old master's znode is hanging around

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4300:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4692 HBASE-4300 broke the build

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/ServerName.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/ActiveMasterManager.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/util/Addressing.java
* /hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/TestServerName.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/master/TestActiveMasterManager.java


> Start of new-version master fails if old master's znode is hanging around
> -
>
> Key: HBASE-4300
> URL: https://issues.apache.org/jira/browse/HBASE-4300
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 4300-v2.txt, 4300-v3.txt, 4300.txt
>
>
> I shut down an 0.90 cluster, and had to do so uncleanly. I then started a 
> trunk (0.92) cluster before the old master znode had expired. This cased:
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1937)
> at 
> org.apache.hadoop.hbase.ServerName.parseHostname(ServerName.java:81)
> at org.apache.hadoop.hbase.ServerName.(ServerName.java:63)
> at 
> org.apache.hadoop.hbase.master.ActiveMasterManager.blockUntilBecomingActiveMaster(ActiveMasterManager.java:148)
> at 
> org.apache.hadoop.hbase.master.HMaster.becomeActiveMaster(HMaster.java:342)
> at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:297)

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

[jira] [Commented] (HBASE-4699) Cleanup the UIs

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4699:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4699 Cleanup the UIs

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/jamon/org/apache/hbase/tmpl/common/TaskMonitorTmpl.jamon
* 
/hbase/branches/0.92/src/main/jamon/org/apache/hbase/tmpl/master/MasterStatusTmpl.jamon
* 
/hbase/branches/0.92/src/main/jamon/org/apache/hbase/tmpl/regionserver/RSStatusTmpl.jamon
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/HServerLoad.java
* /hbase/branches/0.92/src/main/resources/hbase-webapps/static/hbase.css


> Cleanup the UIs
> ---
>
> Key: HBASE-4699
> URL: https://issues.apache.org/jira/browse/HBASE-4699
> Project: HBase
>  Issue Type: Improvement
>Reporter: stack
>Assignee: stack
> Fix For: 0.92.0
>
> Attachments: 4699.txt, 4699.txt
>
>
> UIs have had a bunch of stuff dumped into them of late.  Its all good stuff 
> its just not sitting nicely in the web page.  Fix.

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

[jira] [Commented] (HBASE-4680) FSUtils.isInSafeMode() checks should operate on HBase root dir, where we have permissions

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4680:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4680 FSUtils.isInSafeMode() checks should operate on HBase root dir, 
where we have permissions; REVERT
HBASE-4680  FSUtils.isInSafeMode() checks should operate on HBase root dir, 
where we have permissions

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java

garyh : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java


> FSUtils.isInSafeMode() checks should operate on HBase root dir, where we have 
> permissions
> -
>
> Key: HBASE-4680
> URL: https://issues.apache.org/jira/browse/HBASE-4680
> Project: HBase
>  Issue Type: Bug
>  Components: util
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 0.92.0
>
> Attachments: HBASE-4680.patch
>
>
> The HDFS safe mode check workaround introduced by HBASE-4510 performs a 
> {{FileSystem.setPermission()}} operation on the root directory ("/") when 
> attempting to trigger a {{SafeModeException}}.  As a result, it requires 
> superuser privileges when running with DFS permission checking enabled.  
> Changing the operations to act on the HBase root directory should be safe, 
> since the master process must have write access to it.

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

[jira] [Commented] (HBASE-4679) Thrift null mutation error

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4679:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4679 Thrift null mutation error

nspiegelberg : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServer.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/thrift/TestThriftServer.java


> Thrift null mutation error
> --
>
> Key: HBASE-4679
> URL: https://issues.apache.org/jira/browse/HBASE-4679
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
> Fix For: 0.92.0, 0.94.0
>
> Attachments: HBASE-4679.patch
>
>
> When using null as a value for a mutation, HBasse thrift client failed and 
> threw an error. We should instad check for a null byte buffer.

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

[jira] [Commented] (HBASE-4694) Some cleanup of log messages in RS and M

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4694:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4694 Addendum, restore non-logging statements in DefaultLoadBalancer
HBASE-4694 Some cleanup of log messages in RS and M

tedyu : 
Files : 
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/DefaultLoadBalancer.java

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlockIndex.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV2.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/DefaultLoadBalancer.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/LogRoller.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/CompactionRequest.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogWriter.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/util/BloomFilterFactory.java


> Some cleanup of log messages in RS and M
> 
>
> Key: HBASE-4694
> URL: https://issues.apache.org/jira/browse/HBASE-4694
> Project: HBase
>  Issue Type: Improvement
>Reporter: stack
>Assignee: stack
> Fix For: 0.92.0
>
> Attachments: 4694.addendum, logging.txt
>
>
> I did a little edit of logging.  We do way too much but am not going to do a 
> big overhaul just yet.  Here's a few small changes saving a few lines, some 
> redundancy, and making others look like surrounding log lines.

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

[jira] [Commented] (HBASE-4687) regionserver may miss zk-heartbeats to master when replaying edits at region open

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4687:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4687 regionserver may miss zk-heartbeats to master when replaying 
edits at region open (prakash via jgray)

jgray : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java


> regionserver may miss zk-heartbeats to master when replaying edits at region 
> open
> -
>
> Key: HBASE-4687
> URL: https://issues.apache.org/jira/browse/HBASE-4687
> Project: HBase
>  Issue Type: Bug
>Reporter: Prakash Khemani
>Assignee: Prakash Khemani
> Fix For: 0.92.0
>
> Attachments: 
> 0001-HBASE-4687-regionserver-may-miss-zk-heartbeats-to-ma.patch
>
>
> replayRecoveredEdits() should do another reporter.progress() before returning.

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

[jira] [Commented] (HBASE-4701) TestMasterObserver fails up on jenkins

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4701:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4701 TestSplitTransactionOnCluster fails on occasion when it tries to 
move a region
HBASE-4701 TestMasterObserver fails up on jenkins

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/ServerName.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java


> TestMasterObserver fails up on jenkins
> --
>
> Key: HBASE-4701
> URL: https://issues.apache.org/jira/browse/HBASE-4701
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 0.92.0
>
> Attachments: 4701.txt
>
>
> This fails for various reasons from not being able to find the region we're 
> to move in master list of regions to fails because of 'too many open files' 
> (I believe Giri has fixed this on some of the hadoop nodes but looks like not 
> all).
> Here is a refactor around the move w/ asserts, more logging, use of updated 
> apis, and with check that what we're moving has a server.

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

[jira] [Commented] (HBASE-4552) multi-CF bulk load is not atomic across column families

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4552:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4552  multi-CF bulk load is not atomic across column families 
(Jonathan Hsieh)

tedyu : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/ipc/HRegionInterface.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
* /hbase/branches/0.92/src/main/resources/hbase-default.xml
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/mapreduce/TestLoadIncrementalHFilesSplitRecovery.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionServerBulkLoad.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java


> multi-CF bulk load is not atomic across column families
> ---
>
> Key: HBASE-4552
> URL: https://issues.apache.org/jira/browse/HBASE-4552
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Jonathan Hsieh
> Fix For: 0.92.0
>
> Attachments: hbase-4552.consolidated.patch, 
> hbase-4552.consolidated.v2.patch, hbase-4552.consolidated.v3.patch, 
> hbase-4552.consolidated.v4.patch
>
>
> Currently the bulk load API simply imports one HFile at a time. With 
> multi-column-family support, this is inappropriate, since different CFs show 
> up separately. Instead, the IPC endpoint should take a of CF -> HFiles, so we 
> can online them all under a single region-wide lock.

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

[jira] [Commented] (HBASE-4436) Remove methods deprecated in 0.90 from TRUNK and 0.92

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4436:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4436 Remove trivial 0.90 deprecated code from 0.92 and trunk.

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/KeyValue.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/Delete.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/Get.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/HConnection.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/HTable.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/Put.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/client/Result.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/HbaseObjectWritable.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/ipc/HRegionInterface.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServer.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/thrift/ThriftUtilities.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/TestSerialization.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/TimestampTestBase.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/util/TestMergeTool.java


> Remove methods deprecated in 0.90 from TRUNK and 0.92
> -
>
> Key: HBASE-4436
> URL: https://issues.apache.org/jira/browse/HBASE-4436
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: Jonathan Hsieh
>  Labels: noob
> Fix For: 0.92.0
>
>
> Remove methods deprecated in 0.90 from codebase.  i took a quick look.  The 
> messy bit is thrift referring to old stuff; will take a little work to do the 
> convertion over to the new methods.

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

[jira] [Commented] (HBASE-4690) Intermittent TestRegionServerCoprocessorExceptionWithAbort#testExceptionFromCoprocessorDuringPut failure

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4690:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4690  Intermittent TestRegionServerCoprocessorExceptionWithAbort 
failure

tedyu : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java


> Intermittent 
> TestRegionServerCoprocessorExceptionWithAbort#testExceptionFromCoprocessorDuringPut
>  failure
> 
>
> Key: HBASE-4690
> URL: https://issues.apache.org/jira/browse/HBASE-4690
> Project: HBase
>  Issue Type: Test
>Affects Versions: 0.92.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.92.0
>
> Attachments: 4690-trunk.txt
>
>
> See 
> https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/83/testReport/junit/org.apache.hadoop.hbase.coprocessor/TestRegionServerCoprocessorExceptionWithAbort/testExceptionFromCoprocessorDuringPut/
> Somehow getRSForFirstRegionInTable() wasn't able to retrieve the region 
> server.
> One fix for this issue is to spin up MiniCluster with 1 region server so that 
> we don't need to search for the region server where first region is hosted.

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

[jira] [Commented] (HBASE-4692) HBASE-4300 broke the build

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4692:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4692 HBASE-4300 broke the build

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/ServerName.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/ActiveMasterManager.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/util/Addressing.java
* /hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/TestServerName.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/master/TestActiveMasterManager.java


> HBASE-4300 broke the build
> --
>
> Key: HBASE-4692
> URL: https://issues.apache.org/jira/browse/HBASE-4692
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 0.92.0
>
> Attachments: 4692-v2.txt, 4692.txt
>
>
> Rebasing my patch I missed encoding of master name up in zk.  Creating a 
> separate issue so can try patch build with my fix rather than run all tests 
> locally.

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

[jira] [Commented] (HBASE-4641) Block cache can be mistakenly instantiated on Master

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4641:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4641  Block cache can be mistakenly instantiated on Master (jgray)

jgray : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/HMaster.java


> Block cache can be mistakenly instantiated on Master
> 
>
> Key: HBASE-4641
> URL: https://issues.apache.org/jira/browse/HBASE-4641
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Jonathan Gray
>Assignee: Jonathan Gray
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 4641-suggestion-v3.txt, 4641-v4.txt, 
> HBASE-4641-v1.patch, HBASE-4641-v2.patch
>
>
> After changes in the block cache instantiation over in HBASE-4422, it looks 
> like the HMaster can now end up with a block cache instantiated.  Not a huge 
> deal but prevents the process from shutting down properly.

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

[jira] [Commented] (HBASE-4603) Uneeded sleep time for tests in hbase.master.ServerManager#waitForRegionServers

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4603:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4603 Uneeded sleep time for tests in 
hbase.master.ServerManager#waitForRegionServers

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/test/resources/hbase-site.xml


> Uneeded sleep time for tests in 
> hbase.master.ServerManager#waitForRegionServers
> ---
>
> Key: HBASE-4603
> URL: https://issues.apache.org/jira/browse/HBASE-4603
> Project: HBase
>  Issue Type: Improvement
>  Components: test
>Affects Versions: 0.92.0
> Environment: all.
>Reporter: nkeywal
>Assignee: nkeywal
>Priority: Minor
> Fix For: 0.92.0
>
> Attachments: 20111017_4603_MiniHBaseCluster.patch, 4603-v2.txt
>
>
> This functions waits for at least 2 times 
> hbase.master.wait.on.regionservers.interval, defaulted at 3 seconds, i.e. 6 
> seconds for every mini hbase cluster starts.
> In the context of a mini cluster, it's not useful, as the regions servers are 
> created locally.
> Changing this to a lower value such as 100ms gives 5.8 second per HBase 
> cluser start. It should lower the build time on the apache server by more 
> than 8%.
> Beeing more aggressive (removing all the wait time) could be possible as 
> well. To be studied later.

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

[jira] [Commented] (HBASE-4613) hbase.util.Threads#threadDumpingIsAlive sleeps 1 second, slowing down the shutdown by 0.5s

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4613:
---

Integrated in HBase-0.92 #90 (See 
[https://builds.apache.org/job/HBase-0.92/90/])
HBASE-4613 hbase.util.Threads#threadDumpingIsAlive sleeps 1 second, slowing 
down the shutdown by 0.5s

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/util/Threads.java


> hbase.util.Threads#threadDumpingIsAlive sleeps 1 second, slowing down the 
> shutdown by 0.5s
> --
>
> Key: HBASE-4613
> URL: https://issues.apache.org/jira/browse/HBASE-4613
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 0.94.0
> Environment: all
>Reporter: nkeywal
>Assignee: nkeywal
>Priority: Minor
> Fix For: 0.92.0
>
> Attachments: 20111020_4613_Threads.patch
>
>
> Current implementation is:
> {noformat} 
>   /**
>* @param t Waits on the passed thread to die dumping a threaddump every
>* minute while its up.
>* @throws InterruptedException
>*/
>   public static void threadDumpingIsAlive(final Thread t)
>   throws InterruptedException {
> if (t == null) {
>   return;
> }
> long startTime = System.currentTimeMillis();
> while (t.isAlive()) {
>   Thread.sleep(1000);
>   if (System.currentTimeMillis() - startTime > 6) {
> startTime = System.currentTimeMillis();
> ReflectionUtils.printThreadInfo(new PrintWriter(System.out),
> "Automatic Stack Trace every 60 seconds waiting on " +
> t.getName());
>   }
> }
>   }
> {noformat} 
> while this one would make more sense considering the documentation, and save 
> around 0,5s when the MiniCluster shutdowns.
> {noformat}
>   public static void threadDumpingIsAlive(final Thread t)
> throws InterruptedException {
> if (t == null) {
>   return;
> }
> while (t.isAlive()) {
>   t.join(60 * 1000);
>   if (t.isAlive()) {
> ReflectionUtils.printThreadInfo(new PrintWriter(System.out),
>   "Automatic Stack Trace every 60 seconds waiting on " +
> t.getName());
>   }
> }
>   }
> {noformat} 
> However, it was replacing a previous implementation with a join without a 
> timeout. So if anyone has a warning here...
> Tests seems to be ok...

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

[jira] [Commented] (HBASE-4677) Remove old single bulkLoadHFile method

[Todd Lipcon (Commented) (JIRA)]

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

Todd Lipcon commented on HBASE-4677:


Ming: at some point we will endeavour to support cross-version IPC. But for now 
the assumption is that between major versions (0.M.* to 0.N.*) we don't support 
wire compatibility. But, you should be able to recompile your app against 0.92 
and it should still work, so long as you weren't using any methods marked 
deprecated in 0.90.0.

> Remove old single bulkLoadHFile method
> --
>
> Key: HBASE-4677
> URL: https://issues.apache.org/jira/browse/HBASE-4677
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 0.92.0
>
> Attachments: hbase-4677.patch
>
>
> In review for HBASE-4649, there is some debate as whether to remove, 
> deprecate, or leave the HRegionServer.bulkLoadHFile method. 
> https://reviews.apache.org/r/2545/ .   This jira will take care of that for 
> the 0.92 and trunk releases, and allow the same patch to remain for an 
> optional 0.90.x patch.

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

[jira] [Commented] (HBASE-4702) Allow override of scan cache value for rowcounter

[Jean-Daniel Cryans (Commented) (JIRA)]

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

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

bq. Trying to set the default cache size but there is no knob to tune it.

Use -Dhbase.client.scanner.caching=x on the command line or set it in your 
hbase-site.xml

> Allow override of scan cache value for rowcounter
> -
>
> Key: HBASE-4702
> URL: https://issues.apache.org/jira/browse/HBASE-4702
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.2
> Environment: Operating System: Linux
>Reporter: Rita M
>Assignee: Ted Yu
> Attachments: 4702.txt
>
>
> Doing a row count for a large table via Mapreduce may take long time.
> Trying to set the default cache size but there is no knob to tune it.
> See here for more details, 
> http://search-hadoop.com/m/ECEs6237AIX&subj=Re+speeding+up+rowcount

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

[jira] [Commented] (HBASE-4677) Remove old single bulkLoadHFile method

[Jonathan Hsieh (Commented) (JIRA)]

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

Jonathan Hsieh commented on HBASE-4677:
---

I think in this case the api was flawed and the only real way to
fix is to extend. If this gets backported to 0.90.5 we'll keep the old
API call to maintain compatibility.

0.90 and 0.92 are different major versions so the apis can change.

> Remove old single bulkLoadHFile method
> --
>
> Key: HBASE-4677
> URL: https://issues.apache.org/jira/browse/HBASE-4677
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 0.92.0
>
> Attachments: hbase-4677.patch
>
>
> In review for HBASE-4649, there is some debate as whether to remove, 
> deprecate, or leave the HRegionServer.bulkLoadHFile method. 
> https://reviews.apache.org/r/2545/ .   This jira will take care of that for 
> the 0.92 and trunk releases, and allow the same patch to remain for an 
> optional 0.90.x patch.

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

[jira] [Created] (HBASE-4710) HBaseRPC$UnknownProtocolException should abort any client retries in HConnectionManager

[Gary Helmling (Created) (JIRA)]

HBaseRPC$UnknownProtocolException should abort any client retries in 
HConnectionManager
---

 Key: HBASE-4710
 URL: https://issues.apache.org/jira/browse/HBASE-4710
 Project: HBase
  Issue Type: Bug
  Components: coprocessors
Affects Versions: 0.92.0, 0.94.0
Reporter: Gary Helmling


While {{HBaseRPC$UnknownProtocolException}} currently extends 
{{DoNotRetryIOException}}, it's still allowing retries of client RPCs when 
encountered in {{HConnectionManager.getRegionServerWithRetries()}}.  It turns 
out that {{UnknownProtocolException}} is missing a public constructor taking a 
single {{String}} argument, which is required when unwrapping an 
{{IOException}} from a {{RemoteException}} in 
{{RemoteExceptionHandler.decodeRemoteException()}}.

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

[jira] [Updated] (HBASE-4698) Let the HFile Pretty Printer print all the key values for a specific row.

[Phabricator (Updated) (JIRA)]

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

Phabricator updated HBASE-4698:
---

Attachment: D111.4.patch

Liyin updated the revision "[jira] [HBASE-4698] Let the HFile Pretty Printer 
print all the key values for a specific row.".
Reviewers: mbautin, Kannan, jgray, gqchen, nspiegelberg, JIRA

  Address Nicolas's and Mikhail's comments.

REVISION DETAIL
  https://reviews.facebook.net/D111

AFFECTED FILES
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java


> Let the HFile Pretty Printer print all the key values for a specific row.
> -
>
> Key: HBASE-4698
> URL: https://issues.apache.org/jira/browse/HBASE-4698
> Project: HBase
>  Issue Type: New Feature
>Reporter: Liyin Tang
>Assignee: Liyin Tang
> Attachments: D111.1.patch, D111.1.patch, D111.1.patch, D111.2.patch, 
> D111.3.patch, D111.4.patch
>
>
> When using HFile Pretty Printer to debug HBase issues, 
> it would very nice to allow the Pretty Printer to seek to a specific row, and 
> only print all the key values for this row.

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

[Differential] [Updated, 55 lines] D111: [jira] [HBASE-4698] Let the HFile Pretty Printer print all the key values for a specific row.

[Liyin (Liyin Tang)]

Liyin updated the revision "[jira] [HBASE-4698] Let the HFile Pretty Printer 
print all the key values for a specific row.".
Reviewers: mbautin, Kannan, jgray, gqchen, nspiegelberg, JIRA

  Address Nicolas's and Mikhail's comments.

REVISION DETAIL
  https://reviews.facebook.net/D111

AFFECTED FILES
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java
Index: src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java
===
--- src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java
+++ src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java
@@ -41,7 +41,6 @@
 import org.apache.hadoop.hbase.HRegionInfo;
 import org.apache.hadoop.hbase.KeyValue;
 import org.apache.hadoop.hbase.io.hfile.HFile.FileInfo;
-import org.apache.hadoop.hbase.io.hfile.HFileBlockIndex.BlockIndexReader;
 import org.apache.hadoop.hbase.regionserver.TimeRangeTracker;
 import org.apache.hadoop.hbase.util.BloomFilter;
 import org.apache.hadoop.hbase.util.BloomFilterFactory;
@@ -68,7 +67,12 @@
   private boolean printBlocks;
   private boolean checkRow;
   private boolean checkFamily;
-
+  private boolean isSeekToRow = false;
+  
+  /**
+   * The row which the user wants to specify and print all the KeyValues for.
+   */
+  private byte[] row = null;
   private Configuration conf;
 
   private List files = new ArrayList();
@@ -92,6 +96,8 @@
 options.addOption("a", "checkfamily", false, "Enable family check");
 options.addOption("f", "file", true,
 "File to scan. Pass full-path; e.g. hdfs://a:9000/hbase/.META./12/34");
+options.addOption("s", "seekToRow", true,
+"Seek to this row and print all the kvs for this row only");
 options.addOption("r", "region", true,
 "Region to scan. Pass region name; e.g. '.META.,,1'");
   }
@@ -125,6 +131,17 @@
   files.add(new Path(cmd.getOptionValue("f")));
 }
 
+if (cmd.hasOption("s")) {
+  String key = cmd.getOptionValue("s");
+  if (key != null && key.length() != 0) {
+row = key.getBytes();
+isSeekToRow = true;
+  } else {
+System.err.println("Invalid row is specified.");
+System.exit(-1);
+  }
+}
+
 if (cmd.hasOption("r")) {
   String regionName = cmd.getOptionValue("r");
   byte[] rn = Bytes.toBytes(regionName);
@@ -203,8 +220,13 @@
 if (printKey || checkRow || checkFamily) {
   // scan over file and read key/value's, performing any requested checks
   HFileScanner scanner = reader.getScanner(false, false, false);
-  scanner.seekTo();
-  scanKeyValues(file, scanner);
+  if (this.isSeekToRow) {
+// seek to the first kv on this row
+scanner.seekTo(KeyValue.createFirstOnRow(this.row).getKey());
+  } else {
+scanner.seekTo();
+  }
+  scanKeyValues(file, scanner, row);
 }
 
 // print meta data
@@ -220,7 +242,22 @@
 reader.close();
   }
 
-  private void scanKeyValues(Path file, HFileScanner scanner)
+  /**
+   * Scan the KeyValues from the file
+   * 
+   * @param file
+   *  The path of the file
+   * @param scanner
+   *  The HFileScanner for the file
+   * @param row
+   *  Seek to the specific row and print all the kvs for this row. If
+   *  row is null, it means no row is specified and it will print all
+   *  the rows in this file.
+   * @throws IOException
+   *  If the scanner throws out IOException or the ObjectMapper throws
+   *  out IOException.
+   */
+  private void scanKeyValues(Path file, HFileScanner scanner, byte[] row)
   throws IOException {
 KeyValue pkv = null;
 boolean first = true;
@@ -230,6 +267,14 @@
   System.out.print("[");
 do {
   KeyValue kv = scanner.getKeyValue();
+  if (row != null && row.length != 0) {
+int result = Bytes.compareTo(kv.getRow(), row);
+if (result > 0) {
+  break;
+} else if (result < 0) {
+  continue;
+}
+  }
   // check if rows are in order
   if (checkRow && pkv != null) {
 if (Bytes.compareTo(pkv.getRow(), kv.getRow()) > 0) {

[jira] [Commented] (HBASE-4677) Remove old single bulkLoadHFile method

[Ming Ma (Commented) (JIRA)]

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

Ming Ma commented on HBASE-4677:


What is the general recommendation to application developer w.r.t HBase major 
upgrade?  We have some application built on 0.90.4 that uses 
LoadIncrementalHFiles on the application machines. In that scenario, the 
application jar that use HBase 0.90.4 jar won't work with 0.92.0 HBase cluster.

In the long term do we want to get to a point where we have HBase_client.jar 
and HBase_server.jar? In that scenario, application can continue to use an old 
version of HBase_client.jar to talk to newer version of HBase_server.jar. The 
old IPC methods will need to be maintained for that scenario. Or perhaps such 
kind of compatibility support should be done on a higher leverl like Thift?

Perhaps it isn't a major issue until we have lots of HBase applications running 
and HBase is used as a service.





> Remove old single bulkLoadHFile method
> --
>
> Key: HBASE-4677
> URL: https://issues.apache.org/jira/browse/HBASE-4677
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 0.92.0
>
> Attachments: hbase-4677.patch
>
>
> In review for HBASE-4649, there is some debate as whether to remove, 
> deprecate, or leave the HRegionServer.bulkLoadHFile method. 
> https://reviews.apache.org/r/2545/ .   This jira will take care of that for 
> the 0.92 and trunk releases, and allow the same patch to remain for an 
> optional 0.90.x patch.

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

[jira] [Commented] (HBASE-3025) Coprocessor based simple access control

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-3025:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2041/
---

(Updated 2011-11-01 00:26:37.040678)


Review request for hbase.


Changes
---

Updated patch addressing review comments:

* cleaned up audit logging of authorization decisions.  Logging now occurs in 
AccessController.requirePermission(), with a single audit log entry per 
authorization decision.
* audit logging uses a more consistent format
* KeeperExceptions in ZKPermissionWatcher now trigger aborts where necessary, 
instead of logging and dropping the exceptions.


Summary
---

This patch implements access control list based authorization of HBase 
operations.  The patch depends on the currently posted patch for HBASE-2742 
(secure RPC engine).

Key parts of the implementation are:

* AccessControlLists - encapsulates storage of permission grants in a metadata 
table ("_acl_").  This differs from previous implementation where the ".META." 
table was used to store permissions.

* AccessController - 
  - implements MasterObserver and RegionObserver, performing authorization 
checks in each of the preXXX() hooks.  If authorization fails, an 
AccessDeniedException is thrown.
  - implements AccessControllerProtocol as a coprocessor endpoint to provide 
RPC methods for granting, revoking and listing permissions.

* ZKPermissionWatcher (and TableAuthManager) - synchronizes ACL entries and 
updates throughout the cluster nodes using ZK.  ACL entries are stored in 
per-table znodes as /hbase/acl/tablename.

* Additional ruby shell scripts providing the "grant", "revoke" and 
"user_permission" commands

* Support for a new OWNER attribute in HTableDescriptor.  I could separate out 
this change into a new JIRA for discussion, but I don't see it as currently 
useful outside of security.  Alternately, I could handle the OWNER attribute 
completely in AccessController without changing HTD, but that would make 
interaction via hbase shell a bit uglier.


This addresses bug HBASE-3025.
https://issues.apache.org/jira/browse/HBASE-3025


Diffs (updated)
-

  
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlFilter.java
 PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java
 PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
 PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControllerProtocol.java
 PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/Permission.java 
PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
 PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/TablePermission.java
 PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/UserPermission.java
 PRE-CREATION 
  
security/src/main/java/org/apache/hadoop/hbase/security/access/ZKPermissionWatcher.java
 PRE-CREATION 
  
security/src/test/java/org/apache/hadoop/hbase/security/access/SecureTestUtil.java
 PRE-CREATION 
  
security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java
 PRE-CREATION 
  
security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
 PRE-CREATION 
  
security/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java
 PRE-CREATION 
  
security/src/test/java/org/apache/hadoop/hbase/security/access/TestZKPermissionsWatcher.java
 PRE-CREATION 
  src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java 99875b8 
  src/main/java/org/apache/hadoop/hbase/coprocessor/BaseRegionObserver.java 
8a40762 
  src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java bb67e53 
  src/main/resources/hbase-default.xml 3785533 
  src/main/ruby/hbase.rb 4d27191 
  src/main/ruby/hbase/admin.rb 61e04d8 
  src/main/ruby/hbase/hbase.rb beb2450 
  src/main/ruby/hbase/security.rb PRE-CREATION 
  src/main/ruby/shell.rb 9a47600 
  src/main/ruby/shell/commands.rb a352c2e 
  src/main/ruby/shell/commands/grant.rb PRE-CREATION 
  src/main/ruby/shell/commands/revoke.rb PRE-CREATION 
  src/main/ruby/shell/commands/user_permission.rb PRE-CREATION 

Diff: https://reviews.apache.org/r/2041/diff


Testing
---


Thanks,

Gary



> Coprocessor based simple access control
> ---
>
> Key: HBASE-3025
> URL: https://issues.apache.org/jira/browse/HBASE-3025
> Project: HBase
>  Issue Type: Su

[jira] [Commented] (HBASE-3025) Coprocessor based simple access control

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-3025:
--



bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/TableAuthManager.java,
 line 84
bq.  > 
bq.  >
bq.  > Isn't this an error?
bq.  
bq.  Gary Helmling wrote:
bq.  Yes, and in this context a pretty bad one, as it probably means region 
server initiated RPCs won't work or will be denied.  We should probably let the 
IOE escape here...
bq.  
bq.  Andrew Purtell wrote:
bq.  Agree.

Letting the IOException from getCurrent() escape and throwing an exception if 
the returned user is null.


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/TableAuthManager.java,
 line 113
bq.  > 
bq.  >
bq.  > Should be at DEBUG level

Done.


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessControlFilter.java,
 line 37
bq.  > 
bq.  >
bq.  > Could be stated better.

Fixed.


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessControlLists.java,
 line 98
bq.  > 
bq.  >
bq.  > Comment needs updating.
bq.  >

Fixed.


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
 line 98
bq.  > 
bq.  >
bq.  > Can we make this 1?
bq.  
bq.  Gary Helmling wrote:
bq.  sure

Done.


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
 line 192
bq.  > 
bq.  >
bq.  > Debug logging should go to LOG not AUDITLOG
bq.  
bq.  Gary Helmling wrote:
bq.  The idea was that all authorization decisions should be separated into 
audit log.  Here we're allowing access, so AUDITLOG seemed to make sense.  I 
agree that this still needs to be cleaned up a lot.  Maybe all audit logging 
should be done up in requirePermission() with authorization result?  At the 
very least we need a consistent format and consistent logging levels for 
messages (trace, right?).
bq.  
bq.  Andrew Purtell wrote:
bq.  > Maybe all audit logging should be done up in requirePermission() 
with authorization result?
bq.  
bq.  Sounds good.
bq.  
bq.  > At the very least we need a consistent format and consistent logging 
levels for messages (trace, right?).
bq.  
bq.  I'd argue for TRACE

Reworked the audit logging to happen in requirePermission(), so we get a single 
log message per auth check indicating success or failure, with a more 
consistent format.  Result is logged to AUDITLOG at trace level.


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
 line 366
bq.  > 
bq.  >
bq.  > Should hasFamilyQualifierPermission log to AUDITLOG? It is used in 
places to make decisions -- an exception is thrown directly or not.
bq.  
bq.  Gary Helmling wrote:
bq.  Yes, agree, we should either log to AUDITLOG at decision points here 
or consistently move the AUDITLOG logging up a level out of permissionGranted() 
and hasFamilyQualifierPermission().

With moving the audit logging up to requirePermission(), logging to AUDITLOG 
here would be redundant.  Removing the existing log message.


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
 line 375
bq.  > 
bq.  >
bq.  > Another one of these was sent to AUDITLOG above. Do the same here? 
Should be INFO or TRACE level? TRACE makes more sense to me.
bq.  
bq.  Gary Helmling wrote:
bq.  Agree, should go to AUDITLOG at trace.

Removing as redundant with the checking in permissionGranted() and AUDITLOG 
logging performed in requirePermission().


bq.  On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq.  > 
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
 line 497
bq.  > 
bq.  >
bq.  > Ultim

[jira] [Commented] (HBASE-4698) Let the HFile Pretty Printer print all the key values for a specific row.

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4698:


nspiegelberg has commented on the revision "[jira] [HBASE-4698] Let the HFile 
Pretty Printer print all the key values for a specific row.".

  Were you going to remove the unnecessary println()s?

REVISION DETAIL
  https://reviews.facebook.net/D111


> Let the HFile Pretty Printer print all the key values for a specific row.
> -
>
> Key: HBASE-4698
> URL: https://issues.apache.org/jira/browse/HBASE-4698
> Project: HBase
>  Issue Type: New Feature
>Reporter: Liyin Tang
>Assignee: Liyin Tang
> Attachments: D111.1.patch, D111.1.patch, D111.1.patch, D111.2.patch, 
> D111.3.patch
>
>
> When using HFile Pretty Printer to debug HBase issues, 
> it would very nice to allow the Pretty Printer to seek to a specific row, and 
> only print all the key values for this row.

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

[Differential] [Commented On] D111: [jira] [HBASE-4698] Let the HFile Pretty Printer print all the key values for a specific row.

[nspiegelberg (Nicolas Spiegelberg)]

nspiegelberg has commented on the revision "[jira] [HBASE-4698] Let the HFile 
Pretty Printer print all the key values for a specific row.".

  Were you going to remove the unnecessary println()s?

REVISION DETAIL
  https://reviews.facebook.net/D111

[jira] [Commented] (HBASE-4695) WAL logs get deleted before region server can fully flush

[jack levin (Commented) (JIRA)]

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

jack levin commented on HBASE-4695:
---

It would be nice to have a patch for 0.90.4 also.


Thanks,

-Jack



> WAL logs get deleted before region server can fully flush
> -
>
> Key: HBASE-4695
> URL: https://issues.apache.org/jira/browse/HBASE-4695
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 0.90.4
>Reporter: jack levin
>Assignee: gaojinchao
>Priority: Blocker
> Fix For: 0.92.0, 0.90.5
>
> Attachments: HBASE-4695_Trunk_V2.patch, 
> HBASE-4695_branch90_trial.patch, hbase-4695-0.92.txt
>
>
> To replicate the problem do the following:
> 1. check /hbase/.logs/ directory to see if you have WAL logs for the 
> region server you are shutting down.
> 2. executing kill  (where pid is a regionserver pid)
> 3. Watch the regionserver log to start flushing, you will see how many 
> regions are left to flush:
> 09:36:54,665 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 489 regions to close
> 09:56:35,779 INFO org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting 
> on 116 regions to close
> 4. Check /hbase/.logs/ -- you will notice that it has dissapeared.
> 5. Check namenode logs:
> 09:26:41,607 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit: 
> ugi=root ip=/10.101.1.5 cmd=delete 
> src=/hbase/.logs/rdaa5.prod.imageshack.com,60020,1319749
> Note that, if you kill -9 the RS now, and it crashes on flush, you won't have 
> any WAL logs to replay.  We need to make sure that logs are deleted or moved 
> out only when RS has fully flushed. Otherwise its possible to lose data.

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

[jira] [Commented] (HBASE-4676) Prefix Compression - Trie data block encoding

[Matt Corgan (Commented) (JIRA)]

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

Matt Corgan commented on HBASE-4676:


Write speed is slower because of cpu usage.  There's still tons of room for 
optimization, but slower write speed will generally be the trade off for higher 
random read speed.  The current encoding algorithms on github throw off a lot 
of garbage which tends to indicate that they're not using the cpu cache very 
well.

Some data sets would be able to disable gzip/lzo compression and just go with 
prefix compression, so you save some cpu there.

I'm working on a benchmark to compare a few more factors, including compression 
ratio and sequential read speed.

> Prefix Compression - Trie data block encoding
> -
>
> Key: HBASE-4676
> URL: https://issues.apache.org/jira/browse/HBASE-4676
> Project: HBase
>  Issue Type: New Feature
>  Components: io
>Affects Versions: 0.94.0
>Reporter: Matt Corgan
> Attachments: SeeksPerSec by blockSize.png
>
>
> The HBase data block format has room for 2 significant improvements for 
> applications that have high block cache hit ratios.  
> First, there is no prefix compression, and the current KeyValue format is 
> somewhat metadata heavy, so there can be tremendous memory bloat for many 
> common data layouts, specifically those with long keys and short values.
> Second, there is no random access to KeyValues inside data blocks.  This 
> means that every time you double the datablock size, average seek time (or 
> average cpu consumption) goes up by a factor of 2.  The standard 64KB block 
> size is ~10x slower for random seeks than a 4KB block size, but block sizes 
> as small as 4KB cause problems elsewhere.  Using block sizes of 256KB or 1MB 
> or more may be more efficient from a disk access and block-cache perspective 
> in many big-data applications, but doing so is infeasible from a random seek 
> perspective.
> The PrefixTrie block encoding format attempts to solve both of these 
> problems.  Some features:
> * trie format for row key encoding completely eliminates duplicate row keys 
> and encodes similar row keys into a standard trie structure which also saves 
> a lot of space
> * the column family is currently stored once at the beginning of each block.  
> this could easily be modified to allow multiple family names per block
> * all qualifiers in the block are stored in their own trie format which 
> caters nicely to wide rows.  duplicate qualifers between rows are eliminated. 
>  the size of this trie determines the width of the block's qualifier 
> fixed-width-int
> * the minimum timestamp is stored at the beginning of the block, and deltas 
> are calculated from that.  the maximum delta determines the width of the 
> block's timestamp fixed-width-int
> The block is structured with metadata at the beginning, then a section for 
> the row trie, then the column trie, then the timestamp deltas, and then then 
> all the values.  Most work is done in the row trie, where every leaf node 
> (corresponding to a row) contains a list of offsets/references corresponding 
> to the cells in that row.  Each cell is fixed-width to enable binary 
> searching and is represented by [1 byte operationType, X bytes qualifier 
> offset, X bytes timestamp delta offset].
> If all operation types are the same for a block, there will be zero per-cell 
> overhead.  Same for timestamps.  Same for qualifiers when i get a chance.  
> So, the compression aspect is very strong, but makes a few small sacrifices 
> on VarInt size to enable faster binary searches in trie fan-out nodes.
> A more compressed but slower version might build on this by also applying 
> further (suffix, etc) compression on the trie nodes at the cost of slower 
> write speed.  Even further compression could be obtained by using all VInts 
> instead of FInts with a sacrifice on random seek speed (though not huge).
> One current drawback is the current write speed.  While programmed with good 
> constructs like TreeMaps, ByteBuffers, binary searches, etc, it's not 
> programmed with the same level of optimization as the read path.  Work will 
> need to be done to optimize the data structures used for encoding and could 
> probably show a 10x increase.  It will still be slower than delta encoding, 
> but with a much higher decode speed.  I have not yet created a thorough 
> benchmark for write speed nor sequential read speed.
> Though the trie is reaching a point where it is internally very efficient 
> (probably within half or a quarter of its max read speed) the way that hbase 
> currently uses it is far from optimal.  The KeyValueScanner and related 
> classes that iterate through the trie will eventually need to be smarter and 
> 

[jira] [Commented] (HBASE-4686) [89-fb] Fix per-store metrics aggregation

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4686:


mbautin has commented on the revision "[jira] [HBASE-4686] [89-fb] Fix 
per-store metrics aggregation
".

  OK, this is now becoming a code style discussion, which is not a bad thing 
once in a while :)

  In general, the style guide for HBase seems to point to Oracle (former Sun)'s 
coding conventions: 
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html, with the part 
pertaining to Javadoc at 
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html. 
I guess it might not be a bad idea to actually read those docs some time...

INLINE COMMENTS
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:386
 Actually I a lot of places around the codebase don't have these empty lines 
inside javadoc comments, and I think it is not necessary here. Java formatter 
adds trailing whitespace to those empty lines, which is annoying. I did not 
find a requirement that these lines have to be there at 
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html 
(although I did not read that entire style guide).

  I will expand the documentation  of tmpMap.
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:554
 Will fix.
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:704
 Agreed.
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1148 I think 
this saves space and is OK for one-line comments. This parses fine by Javadoc.
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1157 This 
empty line separates the bulky function header and the function body.
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1219 I will 
add one between 1218 and 1219.
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:90
 OK.
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:119
 This one is a matter of preference. There is one at the top, so I will keep 
the one at the bottom of the class definition.

REVISION DETAIL
  https://reviews.facebook.net/D87


> [89-fb] Fix per-store metrics aggregation 
> --
>
> Key: HBASE-4686
> URL: https://issues.apache.org/jira/browse/HBASE-4686
> Project: HBase
>  Issue Type: Bug
>Reporter: Mikhail Bautin
>Assignee: Mikhail Bautin
> Attachments: D87.1.patch, D87.2.patch, D87.3.patch, 
> HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch,
>  
> HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch
>
>
> In r1182034 per-Store metrics were broken, because the aggregation of 
> StoreFile metrics over all stores in a region was replaced by overriding them 
> every time. We saw these metrics drop by a factor of numRegions on a 
> production cluster -- thanks to Kannan for noticing this!  We need to fix the 
> metrics and add a unit test to ensure regressions like this don't happen in 
> the future.

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

[Differential] [Commented On] D87: [jira] [HBASE-4686] [89-fb] Fix per-store metrics aggregation

[mbautin (Mikhail Bautin)]

mbautin has commented on the revision "[jira] [HBASE-4686] [89-fb] Fix 
per-store metrics aggregation
".

  OK, this is now becoming a code style discussion, which is not a bad thing 
once in a while :)

  In general, the style guide for HBase seems to point to Oracle (former Sun)'s 
coding conventions: 
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html, with the part 
pertaining to Javadoc at 
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html. 
I guess it might not be a bad idea to actually read those docs some time...

INLINE COMMENTS
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:386
 Actually I a lot of places around the codebase don't have these empty lines 
inside javadoc comments, and I think it is not necessary here. Java formatter 
adds trailing whitespace to those empty lines, which is annoying. I did not 
find a requirement that these lines have to be there at 
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html 
(although I did not read that entire style guide).

  I will expand the documentation  of tmpMap.
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:554
 Will fix.
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:704
 Agreed.
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1148 I think 
this saves space and is OK for one-line comments. This parses fine by Javadoc.
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1157 This 
empty line separates the bulky function header and the function body.
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1219 I will 
add one between 1218 and 1219.
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:90
 OK.
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:119
 This one is a matter of preference. There is one at the top, so I will keep 
the one at the bottom of the class definition.

REVISION DETAIL
  https://reviews.facebook.net/D87

[jira] [Commented] (HBASE-4698) Let the HFile Pretty Printer print all the key values for a specific row.

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4698:


Liyin has commented on the revision "[jira] [HBASE-4698] Let the HFile Pretty 
Printer print all the key values for a specific row.".

  Thanks Mikhail's and Nicolas's review and response the comments inline.
  I will update the diff to address the comments.

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:70 I 
used the Eclipse code formatter to format the code here, which is based on the 
hbase code style mentioned in HBase book.
  http://hbase.apache.org/book.html#eclipse

  However, there is no rule saying I have to add an empty line here.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:251 
Good point:) thanks a lot. I will update this.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:253 I 
don't understand why this line is NOT necessary.
  This function DOES throw out IOException, doesn't it?
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:247 
Why I need to remove this line?
  According to the code format from the HBase book, there is no need to remove 
empty line in the java doc:

  HBase book:
  http://hbase.apache.org/book.html#eclipse

  The setting:
  


REVISION DETAIL
  https://reviews.facebook.net/D111


> Let the HFile Pretty Printer print all the key values for a specific row.
> -
>
> Key: HBASE-4698
> URL: https://issues.apache.org/jira/browse/HBASE-4698
> Project: HBase
>  Issue Type: New Feature
>Reporter: Liyin Tang
>Assignee: Liyin Tang
> Attachments: D111.1.patch, D111.1.patch, D111.1.patch, D111.2.patch, 
> D111.3.patch
>
>
> When using HFile Pretty Printer to debug HBase issues, 
> it would very nice to allow the Pretty Printer to seek to a specific row, and 
> only print all the key values for this row.

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

[Differential] [Commented On] D111: [jira] [HBASE-4698] Let the HFile Pretty Printer print all the key values for a specific row.

[Liyin (Liyin Tang)]

Liyin has commented on the revision "[jira] [HBASE-4698] Let the HFile Pretty 
Printer print all the key values for a specific row.".

  Thanks Mikhail's and Nicolas's review and response the comments inline.
  I will update the diff to address the comments.

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:70 I 
used the Eclipse code formatter to format the code here, which is based on the 
hbase code style mentioned in HBase book.
  http://hbase.apache.org/book.html#eclipse

  However, there is no rule saying I have to add an empty line here.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:251 
Good point:) thanks a lot. I will update this.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:253 I 
don't understand why this line is NOT necessary.
  This function DOES throw out IOException, doesn't it?
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:247 
Why I need to remove this line?
  According to the code format from the HBase book, there is no need to remove 
empty line in the java doc:

  HBase book:
  http://hbase.apache.org/book.html#eclipse

  The setting:
  


REVISION DETAIL
  https://reviews.facebook.net/D111

[jira] [Assigned] (HBASE-3316) Add support for Java Serialization to HbaseObjectWritable

[Ted Yu (Assigned) (JIRA)]

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

Ted Yu reassigned HBASE-3316:
-

Assignee: Ed Kohlwey

> Add support for Java Serialization to HbaseObjectWritable
> -
>
> Key: HBASE-3316
> URL: https://issues.apache.org/jira/browse/HBASE-3316
> Project: HBase
>  Issue Type: New Feature
>  Components: io
>Affects Versions: 0.92.0
>Reporter: Ed Kohlwey
>Assignee: Ed Kohlwey
>Priority: Minor
> Fix For: 0.92.0
>
> Attachments: HBASE-3316.patch
>
>
> It is convenient in some situations to have HbaseObjectWritable write 
> serializable Java objects, for instance when prototyping new code where you 
> don't want to take the time to implement a writable.
> Adding this support requires no overhead compared the current implementation.

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

[jira] [Commented] (HBASE-4669) Add an option of using round-robin assignment for enabling table

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4669:
---

Integrated in HBase-TRUNK #2393 (See 
[https://builds.apache.org/job/HBase-TRUNK/2393/])
HBASE-4669  Add an option of using round-robin assignment for enabling table
   (Jieshan Bean)

tedyu : 
Files : 
* /hbase/trunk/CHANGES.txt
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/BulkAssigner.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/BulkReOpen.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/handler/EnableTableHandler.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java


> Add an option of using round-robin assignment for enabling table
> 
>
> Key: HBASE-4669
> URL: https://issues.apache.org/jira/browse/HBASE-4669
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 0.90.4, 0.94.0
>Reporter: Jieshan Bean
>Assignee: Jieshan Bean
>Priority: Minor
> Fix For: 0.94.0
>
> Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, 
> HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch
>
>
> Under some scenarios, we use the function of disable/enable HTable. But 
> currently, enable HTable uses the random-assignment. We hope all the regions 
> show a better distribution, no matter how many regions and how many 
> regionservers.
> So I suggest to add an option of using round-robin assignment on 
> enable-table. 

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

[jira] [Commented] (HBASE-4686) [89-fb] Fix per-store metrics aggregation

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4686:


Liyin has commented on the revision "[jira] [HBASE-4686] [89-fb] Fix per-store 
metrics aggregation
".

INLINE COMMENTS
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:386
 Can you elaborate what the key and value in this tmpMap is in the javadoc?
  It does no look very clear to me.

REVISION DETAIL
  https://reviews.facebook.net/D87


> [89-fb] Fix per-store metrics aggregation 
> --
>
> Key: HBASE-4686
> URL: https://issues.apache.org/jira/browse/HBASE-4686
> Project: HBase
>  Issue Type: Bug
>Reporter: Mikhail Bautin
>Assignee: Mikhail Bautin
> Attachments: D87.1.patch, D87.2.patch, D87.3.patch, 
> HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch,
>  
> HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch
>
>
> In r1182034 per-Store metrics were broken, because the aggregation of 
> StoreFile metrics over all stores in a region was replaced by overriding them 
> every time. We saw these metrics drop by a factor of numRegions on a 
> production cluster -- thanks to Kannan for noticing this!  We need to fix the 
> metrics and add a unit test to ensure regressions like this don't happen in 
> the future.

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

[Differential] [Commented On] D87: [jira] [HBASE-4686] [89-fb] Fix per-store metrics aggregation

[Liyin (Liyin Tang)]

Liyin has commented on the revision "[jira] [HBASE-4686] [89-fb] Fix per-store 
metrics aggregation
".

INLINE COMMENTS
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:386
 Can you elaborate what the key and value in this tmpMap is in the javadoc?
  It does no look very clear to me.

REVISION DETAIL
  https://reviews.facebook.net/D87

[jira] [Created] (HBASE-4709) Hadoop metrics2 setup in test MiniDFSClusters spewing JMX errors

[Gary Helmling (Created) (JIRA)]

Hadoop metrics2 setup in test MiniDFSClusters spewing JMX errors


 Key: HBASE-4709
 URL: https://issues.apache.org/jira/browse/HBASE-4709
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.92.0, 0.94.0
Reporter: Gary Helmling
Priority: Minor


Since switching over HBase to build with Hadoop 0.20.205.0, we've been getting 
a lot of metrics related errors in the log files for tests:
{noformat}
2011-10-30 22:00:22,858 INFO  [main] log.Slf4jLog(67): jetty-6.1.26
2011-10-30 22:00:22,871 INFO  [main] log.Slf4jLog(67): Extract 
jar:file:/home/jenkins/.m2/repository/org/apache/hadoop/hadoop-core/0.20.205.0/hadoop-core-0.20.205.0.jar!/webapps/datanode
 to /tmp/Jetty_localhost_55751_datanode.kw16hy/webapp
2011-10-30 22:00:23,048 INFO  [main] log.Slf4jLog(67): Started 
SelectChannelConnector@localhost:55751
Starting DataNode 1 with dfs.data.dir: 
/home/jenkins/jenkins-slave/workspace/HBase-TRUNK/trunk/target/test-data/7ba65a16-03ad-4624-b769-57405945ef58/dfscluster_3775fc23-1b51-4966-8133-205564bae762/dfs/data/data3,/home/jenkins/jenkins-slave/workspace/HBase-TRUNK/trunk/target/test-data/7ba65a16-03ad-4624-b769-57405945ef58/dfscluster_3775fc23-1b51-4966-8133-205564bae762/dfs/data/data4
2011-10-30 22:00:23,237 WARN  [main] impl.MetricsSystemImpl(137): Metrics 
system not started: Cannot locate configuration: tried 
hadoop-metrics2-datanode.properties, hadoop-metrics2.properties
2011-10-30 22:00:23,237 WARN  [main] util.MBeans(59): 
Hadoop:service=DataNode,name=MetricsSystem,sub=Control
javax.management.InstanceAlreadyExistsException: MXBean already registered with 
name Hadoop:service=NameNode,name=MetricsSystem,sub=Control
at 
com.sun.jmx.mbeanserver.MXBeanLookup.addReference(MXBeanLookup.java:120)
at 
com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:143)
at 
com.sun.jmx.mbeanserver.MBeanSupport.preRegister2(MBeanSupport.java:183)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:941)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at org.apache.hadoop.metrics2.util.MBeans.register(MBeans.java:56)
at 
org.apache.hadoop.metrics2.impl.MetricsSystemImpl.initSystemMBean(MetricsSystemImpl.java:500)
at 
org.apache.hadoop.metrics2.impl.MetricsSystemImpl.init(MetricsSystemImpl.java:140)
at 
org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.init(DefaultMetricsSystem.java:40)
at 
org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.initialize(DefaultMetricsSystem.java:50)
at 
org.apache.hadoop.hdfs.server.datanode.DataNode.instantiateDataNode(DataNode.java:1483)
at 
org.apache.hadoop.hdfs.server.datanode.DataNode.instantiateDataNode(DataNode.java:1459)
at 
org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes(MiniDFSCluster.java:417)
at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:280)
at 
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniDFSCluster(HBaseTestingUtility.java:349)
at 
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:518)
at 
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:474)
at 
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:461)
{noformat}

This seems to be due to errors initializing the new hadoop metrics2 code by 
default, when running in a mini cluster.  The errors themselves seem to be 
harmless -- they're not breaking any tests -- but we should figure out what 
configuration we need to eliminate them.

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

[jira] [Commented] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[stack (Commented) (JIRA)]

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

stack commented on HBASE-4553:
--

I need to put back the bit where .tableinfo is made in a tmp dir Will make 
a new patch later.  

> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Commented] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Ted Yu (Commented) (JIRA)]

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

Ted Yu commented on HBASE-4377:
---

The failed tests were due to 'Too many open files'.

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Commented] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-4553:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12501695/3446-v8.txt
  against trunk revision .

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

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

-1 patch.  The patch command could not apply the patch.

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

This message is automatically generated.

> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Commented] (HBASE-4686) [89-fb] Fix per-store metrics aggregation

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4686:


Liyin has requested changes to the revision "[jira] [HBASE-4686] [89-fb] Fix 
per-store metrics aggregation
".

  Thanks Mikhail for the patch.
  There are some comments inline.

INLINE COMMENTS
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:386
 [code style] Please add an empty line here
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:554
 Why not move this comments to line 551 ?
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:704
 [code style] please remove this empty line here
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1148 [code 
style] Please write the standard java doc format
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1157 [code 
style] Please remove the empty line here
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1219 [code 
style] Please add an empty line here
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:90
 [code style] Please remove the empty line here
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:119
 [code style] Please remove the empty line here

REVISION DETAIL
  https://reviews.facebook.net/D87


> [89-fb] Fix per-store metrics aggregation 
> --
>
> Key: HBASE-4686
> URL: https://issues.apache.org/jira/browse/HBASE-4686
> Project: HBase
>  Issue Type: Bug
>Reporter: Mikhail Bautin
>Assignee: Mikhail Bautin
> Attachments: D87.1.patch, D87.2.patch, D87.3.patch, 
> HBASE-4686-TestRegionServerMetics-and-Store-metric-a-20111027134023-cc718144.patch,
>  
> HBASE-4686-jira-89-fb-Fix-per-store-metrics-aggregat-20111027152723-05bea421.patch
>
>
> In r1182034 per-Store metrics were broken, because the aggregation of 
> StoreFile metrics over all stores in a region was replaced by overriding them 
> every time. We saw these metrics drop by a factor of numRegions on a 
> production cluster -- thanks to Kannan for noticing this!  We need to fix the 
> metrics and add a unit test to ensure regressions like this don't happen in 
> the future.

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

[jira] [Commented] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-4377:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12501672/hbase-4377.trunk.v6.patch
  against trunk revision .

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

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

-1 javadoc.  The javadoc tool appears to have generated -166 warning 
messages.

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

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

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

 -1 core tests.  The patch failed these unit tests:
   
org.apache.hadoop.hbase.master.TestDistributedLogSplitting
  org.apache.hadoop.hbase.master.TestMasterFailover

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

This message is automatically generated.

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[Differential] [Requested Changes To] D87: [jira] [HBASE-4686] [89-fb] Fix per-store metrics aggregation

[Liyin (Liyin Tang)]

Liyin has requested changes to the revision "[jira] [HBASE-4686] [89-fb] Fix 
per-store metrics aggregation
".

  Thanks Mikhail for the patch.
  There are some comments inline.

INLINE COMMENTS
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:386
 [code style] Please add an empty line here
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:554
 Why not move this comments to line 551 ?
  
src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java:704
 [code style] please remove this empty line here
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1148 [code 
style] Please write the standard java doc format
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1157 [code 
style] Please remove the empty line here
  src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:1219 [code 
style] Please add an empty line here
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:90
 [code style] Please remove the empty line here
  
src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java:119
 [code style] Please remove the empty line here

REVISION DETAIL
  https://reviews.facebook.net/D87

[jira] [Updated] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[stack (Updated) (JIRA)]

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

stack updated HBASE-4553:
-

Attachment: 3446-v8.txt

Change .tableinfo naming so its now .tableinfo.SEQUENCEID.  The sequenceid 
always rolls forward (next seqid is based off the old one).  This removes hole 
where we could have no .tableinfo in case where editors crash at inopportune 
time (TODO: Same for .regioninfo -- should be a single .regioninfo rather than 
one per region).

Bulk of patch is moving TableDescriptor utility out of FSUtils into the 
FSTableDescriptors class.



> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Updated] (HBASE-4553) The update of .tableinfo is not atomic; we remove then rename

[stack (Updated) (JIRA)]

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

stack updated HBASE-4553:
-

Assignee: stack
  Status: Patch Available  (was: Open)

> The update of .tableinfo is not atomic; we remove then rename
> -
>
> Key: HBASE-4553
> URL: https://issues.apache.org/jira/browse/HBASE-4553
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 0.92.0
>
> Attachments: 3446-v8.txt, 4553-v5.txt, HBase-4553-TestAvroServer.patch
>
>
> This comes of HBASE-4547.  The rename in 0.20 hdfs fails if file exists 
> already.  In 0.20+ its better but still 'some' issues if existing reader when 
> file is renamed.  This issue is about fixing this (though we depend on fix 
> first being in hdfs).

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

[jira] [Commented] (HBASE-4698) Let the HFile Pretty Printer print all the key values for a specific row.

[Phabricator (Commented) (JIRA)]

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

Phabricator commented on HBASE-4698:


mbautin has commented on the revision "[jira] [HBASE-4698] Let the HFile Pretty 
Printer print all the key values for a specific row.".

  A few more comments -- coding style only.

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:70 
Code style: add an empty line in here.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:71-73 
Code style: make this one line if it fits in 80 chars, e.g.

/** Your javadoc */
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:247 
Code style: this line is unnecessary
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:253 
This line is unnecessary because it does not say in what case the exception is 
thrown.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:251 if 
Row -> If row (capitalization)

REVISION DETAIL
  https://reviews.facebook.net/D111


> Let the HFile Pretty Printer print all the key values for a specific row.
> -
>
> Key: HBASE-4698
> URL: https://issues.apache.org/jira/browse/HBASE-4698
> Project: HBase
>  Issue Type: New Feature
>Reporter: Liyin Tang
>Assignee: Liyin Tang
> Attachments: D111.1.patch, D111.1.patch, D111.1.patch, D111.2.patch, 
> D111.3.patch
>
>
> When using HFile Pretty Printer to debug HBase issues, 
> it would very nice to allow the Pretty Printer to seek to a specific row, and 
> only print all the key values for this row.

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

[Differential] [Commented On] D111: [jira] [HBASE-4698] Let the HFile Pretty Printer print all the key values for a specific row.

[mbautin (Mikhail Bautin)]

mbautin has commented on the revision "[jira] [HBASE-4698] Let the HFile Pretty 
Printer print all the key values for a specific row.".

  A few more comments -- coding style only.

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:70 
Code style: add an empty line in here.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:71-73 
Code style: make this one line if it fits in 80 chars, e.g.

/** Your javadoc */
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:247 
Code style: this line is unnecessary
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:253 
This line is unnecessary because it does not say in what case the exception is 
thrown.
  src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java:251 if 
Row -> If row (capitalization)

REVISION DETAIL
  https://reviews.facebook.net/D111

[jira] [Commented] (HBASE-4120) isolation and allocation

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-4120:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1421/#review2967
---



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java


Should we return from this method ?
list would be null.



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java


list may be null if IOException was encountered above.



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java


Should read 'Refresh priorities'



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityHBaseServer.java


Should read 'priorities of threads range from'



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


Can you explain the relationship between move and handleFreshInter ?



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


Please add space around =.



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


hbase.schedule.refresh.interval should be a better name for this parameter.

If user specifies a large value, say 100, move would be negative. Is that 
acceptable ?



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


We'd better change lowestThreadPriority to a constant - we're not using 
value for the passed lowestThreadPriority



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


A better name for the method would be refreshPeriodically().



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


This was for debugging purpose.
Can we remove this ?



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


Why don't we respond to runtime exceptions ?



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java


This method isn't called anywhere.


- Ted


On 2011-10-31 05:22:05, Jia Liu wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/1421/
bq.  ---
bq.  
bq.  (Updated 2011-10-31 05:22:05)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Patch used for table priority alone,In this patch, not only tables can 
have different priorities but also the different actions like 
"get","scan","put" and "delete" can have priorities.
bq.  
bq.  
bq.  This addresses bug HBase-4120.
bq.  https://issues.apache.org/jira/browse/HBase-4120
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HBaseRPC.java
 1189169 
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java
 1189169 
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityFunction.java
 PRE-CREATION 
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityHBaseServer.java
 PRE-CREATION 
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/PriorityJobQueue.java
 PRE-CREATION 
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
 1189169 
bq.
http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/allocation/test/TestForActionPriority.java
 PRE-CREATION 
bq.
http://svn.apache.org/repos/asf/hbase/trunk/sr

[jira] [Commented] (HBASE-4680) FSUtils.isInSafeMode() checks should operate on HBase root dir, where we have permissions

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4680:
---

Integrated in HBase-TRUNK #2392 (See 
[https://builds.apache.org/job/HBase-TRUNK/2392/])
HBASE-4680 FSUtils.isInSafeMode() checks should operate on HBase root dir, 
where we have permissions; REVERT

stack : 
Files : 
* /hbase/trunk/CHANGES.txt
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java


> FSUtils.isInSafeMode() checks should operate on HBase root dir, where we have 
> permissions
> -
>
> Key: HBASE-4680
> URL: https://issues.apache.org/jira/browse/HBASE-4680
> Project: HBase
>  Issue Type: Bug
>  Components: util
>Affects Versions: 0.92.0, 0.94.0
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 0.92.0
>
> Attachments: HBASE-4680.patch
>
>
> The HDFS safe mode check workaround introduced by HBASE-4510 performs a 
> {{FileSystem.setPermission()}} operation on the root directory ("/") when 
> attempting to trigger a {{SafeModeException}}.  As a result, it requires 
> superuser privileges when running with DFS permission checking enabled.  
> Changing the operations to act on the HBase root directory should be safe, 
> since the master process must have write access to it.

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

[jira] [Commented] (HBASE-4552) multi-CF bulk load is not atomic across column families

[Hudson (Commented) (JIRA)]

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

Hudson commented on HBASE-4552:
---

Integrated in HBase-TRUNK #2392 (See 
[https://builds.apache.org/job/HBase-TRUNK/2392/])
HBASE-4552  multi-CF bulk load is not atomic across column families 
(Jonathan Hsieh)

tedyu : 
Files : 
* /hbase/trunk/CHANGES.txt
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/ipc/HRegionInterface.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
* /hbase/trunk/src/main/resources/hbase-default.xml
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestLoadIncrementalHFilesSplitRecovery.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionServerBulkLoad.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java


> multi-CF bulk load is not atomic across column families
> ---
>
> Key: HBASE-4552
> URL: https://issues.apache.org/jira/browse/HBASE-4552
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Jonathan Hsieh
> Fix For: 0.92.0
>
> Attachments: hbase-4552.consolidated.patch, 
> hbase-4552.consolidated.v2.patch, hbase-4552.consolidated.v3.patch, 
> hbase-4552.consolidated.v4.patch
>
>
> Currently the bulk load API simply imports one HFile at a time. With 
> multi-column-family support, this is inappropriate, since different CFs show 
> up separately. Instead, the IPC endpoint should take a of CF -> HFiles, so we 
> can online them all under a single region-wide lock.

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

[jira] [Updated] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-4377:
--

Attachment: (was: hbase-4377.trunk.v6.patch)

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Updated] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-4377:
--

Attachment: hbase-4377.trunk.v6.patch
hbase-4377.0.90.v6.patch

Generated new patches using --no-prefix so robot can test.

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Updated] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-4377:
--

Attachment: (was: hbase-4377.0.90.v6.patch)

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Commented] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Hadoop QA (Commented) (JIRA)]

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

Hadoop QA commented on HBASE-4377:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12501666/hbase-4377.trunk.v6.patch
  against trunk revision .

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

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

-1 patch.  The patch command could not apply the patch.

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

This message is automatically generated.

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Updated] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-4377:
--

Status: Open  (was: Patch Available)

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Updated] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-4377:
--

Status: Patch Available  (was: Open)

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Updated] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[Jonathan Hsieh (Updated) (JIRA)]

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

Jonathan Hsieh updated HBASE-4377:
--

Attachment: hbase-4377.trunk.v6.patch
hbase-4377.0.90.v6.patch

Updated patches addressing most of Stack's comments.

> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Commented] (HBASE-4377) [hbck] Offline rebuild .META. from fs data only.

[jirapos...@reviews.apache.org (Commented) (JIRA)]

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

jirapos...@reviews.apache.org commented on HBASE-4377:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2287/
---

(Updated 2011-10-31 21:03:52.791775)


Review request for hbase and Ted Yu.


Changes
---

Updated to address stacks comments.  I believe Seb's patch wasn't necessary in 
0.90 since that code came in on HBASE-451 which isn't on the 0.90 branch.


Summary
---

Backport to 0.90

commit 89862b73c6358e27220b87b0362599d86ab0fe4a
Author: Jonathan Hsieh 
Date:   Wed Sep 28 10:18:11 2011 -0700

HBASE-4377 [hbck] Offline rebuild .META. from fs data only



This addresses bug HBASE-4377.
https://issues.apache.org/jira/browse/HBASE-4377


Diffs (updated)
-

  src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java ef246c3 
  src/main/java/org/apache/hadoop/hbase/util/Bytes.java 13ad026 
  src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java e0bd77e 
  src/main/java/org/apache/hadoop/hbase/util/HBaseFsckRepair.java a981f72 
  src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java 
PRE-CREATION 
  src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java bd3b2f3 
  src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java 
PRE-CREATION 
  
src/test/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRebuildTestCore.java 
PRE-CREATION 
  
src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildBase.java 
PRE-CREATION 
  
src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildHole.java 
PRE-CREATION 
  
src/test/java/org/apache/hadoop/hbase/util/hbck/TestOfflineMetaRebuildOverlap.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/2287/diff


Testing
---

Note, the assertion test result is different in the failure cases due to 
HBASE-451 changes. (0.90 returns 0 tables since it does a meta scan on empty 
meta, trunk branch looks at hdfs dirs, and returns 1).

This version passes after HBASE-4508 (backport HBASE-3777 to 0.90 branch) is 
applied. 

I believe if that patch is not applied, I could modify the test code to force 
some explicit HConnection deletions.


Thanks,

jmhsieh



> [hbck] Offline rebuild .META. from fs data only.
> 
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.92.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch, 
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch, 
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo, 
> hbase-4377-trunk.v2.patch, hbase-4377.0.90.v6.patch, hbase-4377.trunk.v3.txt, 
> hbase-4377.trunk.v4.txt, hbase-4377.trunk.v5.txt, hbase-4377.trunk.v6.patch
>
>
> In a worst case situation, it may be helpful to have an offline .META. 
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta 
> from scratch.  Users could move bad regions out until there is a clean 
> rebuild.  
> It would likely fill in region split holes.  Follow on work could given 
> options to merge or select regions that overlap, or do online rebuilds.

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

[jira] [Updated] (HBASE-4669) Add an option of using round-robin assignment for enabling table

[Ted Yu (Updated) (JIRA)]

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

Ted Yu updated HBASE-4669:
--

  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

> Add an option of using round-robin assignment for enabling table
> 
>
> Key: HBASE-4669
> URL: https://issues.apache.org/jira/browse/HBASE-4669
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 0.90.4, 0.94.0
>Reporter: Jieshan Bean
>Assignee: Jieshan Bean
>Priority: Minor
> Fix For: 0.94.0
>
> Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, 
> HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch
>
>
> Under some scenarios, we use the function of disable/enable HTable. But 
> currently, enable HTable uses the random-assignment. We hope all the regions 
> show a better distribution, no matter how many regions and how many 
> regionservers.
> So I suggest to add an option of using round-robin assignment on 
> enable-table. 

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

[jira] [Commented] (HBASE-4669) Add an option of using round-robin assignment for enabling table

[Ted Yu (Commented) (JIRA)]

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

Ted Yu commented on HBASE-4669:
---

Integrated to TRUNK.

Thanks for the patch Jieshan.

Thanks for the review Ramkrishna.

> Add an option of using round-robin assignment for enabling table
> 
>
> Key: HBASE-4669
> URL: https://issues.apache.org/jira/browse/HBASE-4669
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 0.90.4, 0.94.0
>Reporter: Jieshan Bean
>Assignee: Jieshan Bean
>Priority: Minor
> Fix For: 0.94.0
>
> Attachments: HBASE-4669-90-V2.patch, HBASE-4669-90.patch, 
> HBASE-4669-Trunk-V2.patch, HBASE-4669-Trunk.patch
>
>
> Under some scenarios, we use the function of disable/enable HTable. But 
> currently, enable HTable uses the random-assignment. We hope all the regions 
> show a better distribution, no matter how many regions and how many 
> regionservers.
> So I suggest to add an option of using round-robin assignment on 
> enable-table. 

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

[jira] [Commented] (HBASE-4611) Add support for Phabricator/Differential as an alternative code review tool

[John Sichi (Commented) (JIRA)]

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

John Sichi commented on HBASE-4611:
---

Marek has just checked in support for svn workflows as well.

> Add support for Phabricator/Differential as an alternative code review tool
> ---
>
> Key: HBASE-4611
> URL: https://issues.apache.org/jira/browse/HBASE-4611
> Project: HBase
>  Issue Type: Task
>Reporter: Jonathan Gray
> Attachments: D21.1.patch, D21.1.patch
>
>
> From http://phabricator.org/ : "Phabricator is a open source collection of 
> web applications which make it easier to write, review, and share source 
> code. It is currently available as an early release. Phabricator was 
> developed at Facebook."
> It's open source so pretty much anyone could host an instance of this 
> software.
> To begin with, there will be a public-facing instance located at 
> http://reviews.facebook.net (sponsored by Facebook and hosted by the OSUOSL 
> http://osuosl.org).
> We will use this JIRA to deal with adding (and ensuring) Apache-friendly 
> support that will allow us to do code reviews with Phabricator for HBase.

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