[jira] [Resolved] (HBASE-5833) 0.92 build has been failing pretty consistently on TestMasterFailover....
[ https://issues.apache.org/jira/browse/HBASE-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5833. -- Resolution: Fixed Fix Version/s: 0.92.2 Assignee: stack Applied to 0.92 branch. 0.92 build has been failing pretty consistently on TestMasterFailover - Key: HBASE-5833 URL: https://issues.apache.org/jira/browse/HBASE-5833 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.92.2 Attachments: 5833.txt Trunk seems fine but 0.92 fails on this test pretty regularly. Running it local it seems to hang for me. -- 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] [Resolved] (HBASE-5823) Hbck should be able to print help
[ https://issues.apache.org/jira/browse/HBASE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5823. -- Resolution: Fixed Fix Version/s: 0.94.0 0.92.2 Hadoop Flags: Reviewed Committed to 0.92, and 0.94 branches. Also to Trunk. Thanks for the patch Enis. Hbck should be able to print help - Key: HBASE-5823 URL: https://issues.apache.org/jira/browse/HBASE-5823 Project: HBase Issue Type: Improvement Affects Versions: 0.92.1, 0.96.0, 0.94.1 Reporter: Enis Soztutar Assignee: Enis Soztutar Priority: Minor Fix For: 0.92.2, 0.94.0 Attachments: hbase-hbck.patch bin/hbase hbck -h and -help should print the help message. It used to print help when unrecognized options are passed. We can backport this to 0.92/0.94 branches as well. -- 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] [Resolved] (HBASE-5825) TestHLog not running any tests; fix
[ https://issues.apache.org/jira/browse/HBASE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5825. -- Resolution: Fixed Fix Version/s: 0.94.0 Assignee: stack Committed to 0.94 branch and trunk. TestHLog not running any tests; fix --- Key: HBASE-5825 URL: https://issues.apache.org/jira/browse/HBASE-5825 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.94.0 Attachments: fixtesthlog.txt -- 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] [Resolved] (HBASE-5791) Apache project branding requirements: DOAP file [PATCH]
[ https://issues.apache.org/jira/browse/HBASE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5791. -- Resolution: Fixed Fix Version/s: 0.96.0 I committed the file to src/site/resources so it will show up at top level of the hbase site, http://hbase.apache.org/doap_Hbase.rdf. I then edited https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml and added the above URL. Thanks Shane for pointing out our oversight. Apache project branding requirements: DOAP file [PATCH] --- Key: HBASE-5791 URL: https://issues.apache.org/jira/browse/HBASE-5791 Project: HBase Issue Type: Improvement Reporter: Shane Curcuru Labels: branding Fix For: 0.96.0 Attachments: doap_Hbase.rdf Attached. Re: http://www.apache.org/foundation/marks/pmcs See Also: http://projects.apache.org/create.html -- 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] [Resolved] (HBASE-5751) hbase master stop does not bring down backup masters
[ https://issues.apache.org/jira/browse/HBASE-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5751. -- Resolution: Fixed Applied to 0.90 branch. Opened HBASE-5828 for the TestLogRolling issue. Thanks for the patch Gregory. hbase master stop does not bring down backup masters -- Key: HBASE-5751 URL: https://issues.apache.org/jira/browse/HBASE-5751 Project: HBase Issue Type: Sub-task Reporter: Lars Hofhansl Assignee: Gregory Chanan Fix For: 0.90.7 Attachments: HBASE-5213-v2-90.patch Carry forward the discussion from parent for 0.90 -- 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] [Resolved] (HBASE-5808) Remove TestHLogBench, HLogPerformanceEvaluation is more comprehensive
[ https://issues.apache.org/jira/browse/HBASE-5808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5808. -- Resolution: Fixed Fix Version/s: 0.96.0 Assignee: stack Committed to trunk Remove TestHLogBench, HLogPerformanceEvaluation is more comprehensive - Key: HBASE-5808 URL: https://issues.apache.org/jira/browse/HBASE-5808 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.96.0 Attachments: rm.txt We added HLogPerformanceEvaluation recently though we had TestHLogBench which does much the same thing (Didn't notice). Remove TestHLogBench rather than HLogPerformanceEvaluation because the latter does more (has a verify step and can take more options; also TestHLogBench does not actually write a log) -- 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] [Resolved] (HBASE-5812) Add log rolling to HLogPerformanceEvaluation
[ https://issues.apache.org/jira/browse/HBASE-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5812. -- Resolution: Fixed Fix Version/s: 0.96.0 Assignee: stack Tried it w/ Lars's patch (You have to have a patch else verify won't complete... with three threads only we write out of order) Add log rolling to HLogPerformanceEvaluation Key: HBASE-5812 URL: https://issues.apache.org/jira/browse/HBASE-5812 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.96.0 Attachments: 5812.txt Add being able to ask that HLogPerformanceEvaluation rolls logs when its running. -- 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] [Resolved] (HBASE-5814) Make HLogPerformanceEvaluation work on top of hdfs
[ https://issues.apache.org/jira/browse/HBASE-5814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5814. -- Resolution: Fixed Fix Version/s: 0.96.0 Assignee: stack Committed to trunk. Make HLogPerformanceEvaluation work on top of hdfs -- Key: HBASE-5814 URL: https://issues.apache.org/jira/browse/HBASE-5814 Project: HBase Issue Type: Improvement Reporter: stack Assignee: stack Fix For: 0.96.0 Attachments: 5814.txt, diff.txt -- 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] [Resolved] (HBASE-5800) Birds of a feather link on web page doesn't work.
[ https://issues.apache.org/jira/browse/HBASE-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5800. -- Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Committed to trunk and deployed (should see it in an hour or so). Thanks for the patch Elliott. Birds of a feather link on web page doesn't work. - Key: HBASE-5800 URL: https://issues.apache.org/jira/browse/HBASE-5800 Project: HBase Issue Type: Bug Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.96.0 Attachments: HBASE-5800-0.patch just missing the http:// -- 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] [Resolved] (HBASE-5804) Add more to verification step in HLogPerformanceEvaluation
[ https://issues.apache.org/jira/browse/HBASE-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5804. -- Resolution: Fixed Fix Version/s: 0.96.0 Assignee: stack Committed to trunk. Add more to verification step in HLogPerformanceEvaluation -- Key: HBASE-5804 URL: https://issues.apache.org/jira/browse/HBASE-5804 Project: HBase Issue Type: Improvement Reporter: stack Assignee: stack Fix For: 0.96.0 Attachments: 5804.txt Verify the wal has expected count of edits. -- 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] [Resolved] (HBASE-5772) Unable to open the few links in http://hbase.apache.org/
[ https://issues.apache.org/jira/browse/HBASE-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5772. -- Resolution: Fixed Fix Version/s: 0.96.0 Assignee: stack I just committed this and published the generated site. Should show up in an hour or two. Unable to open the few links in http://hbase.apache.org/ Key: HBASE-5772 URL: https://issues.apache.org/jira/browse/HBASE-5772 Project: HBase Issue Type: Bug Components: documentation Affects Versions: 0.94.0 Reporter: Kiran BC Assignee: stack Fix For: 0.96.0 Attachments: 5772.txt Few links in http://hbase.apache.org/ is not working. For example, Ref Guide (multi-page) will actually link to http://hbase.apache.org/book/book.html and if I try to open this, Page not found error is coming. If I add /book in the url, like http://hbase.apache.org/book/book/book.html, it is taking me to the Apache HBase Reference Guide I think the folder structure has been changed. -- 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] [Resolved] (HBASE-5784) Enable mvn deploy of website
[ https://issues.apache.org/jira/browse/HBASE-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5784. -- Resolution: Fixed Fix Version/s: 0.96.0 Assignee: stack Release Note: Build and deploy the site with the below command $ ~/bin/apache-maven-3.0.4/bin/mvn -X clean site:site site:deploy You must use mvn3. You will probably also need a settings.xml file under your ~/.m2/ directory as described here: http://www.apache.org/dev/publishing-maven-artifacts.html All site deploys should go via this path going forward because it ensures permissions up in apache making it so other members of hbase group can deploy w/o permission conflicts. Enable mvn deploy of website Key: HBASE-5784 URL: https://issues.apache.org/jira/browse/HBASE-5784 Project: HBase Issue Type: Improvement Reporter: stack Assignee: stack Fix For: 0.96.0 Attachments: 5784.txt Up to this, deploy of website has been build local and then copy up to apache and put it into place under /www/hbase.apache.org. Change it so can have maven deploy the site. The good thing about having the latter do it is that its regular; permissions will always be the same so Doug and I won't be fighting each other when we stick stuff up there. Also, its a one step process rather than multiple. -- 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] [Resolved] (HBASE-4094) improve hbck tool to fix more hbase problem
[ https://issues.apache.org/jira/browse/HBASE-4094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4094. -- Resolution: Fixed Resolving at Anoop's suggestion as dup of hbase-5128 improve hbck tool to fix more hbase problem --- Key: HBASE-4094 URL: https://issues.apache.org/jira/browse/HBASE-4094 Project: HBase Issue Type: New Feature Components: master Affects Versions: 0.90.3 Reporter: feng xu Fix For: 0.90.7 Attachments: HbaseFsck_TableChain.patch Original Estimate: 12h Remaining Estimate: 12h -- 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] [Resolved] (HBASE-5771) unable to start regionservers on slave machines in hbase
[ https://issues.apache.org/jira/browse/HBASE-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5771. -- Resolution: Invalid Closing as invalid. This is an incomplete question better suited for mailing list unable to start regionservers on slave machines in hbase Key: HBASE-5771 URL: https://issues.apache.org/jira/browse/HBASE-5771 Project: HBase Issue Type: Task Reporter: amsal Priority: Critical have a problem starting regionservers on slave pc,s. when i enlist only master pc in conf/regionservers every thing works fine but when i add two more slaves to it the hbase does not start . if i delete all hbase folders in the tmp folder from all pc,s and then start regionserver (with 3 regionservers enlisted)the hbase gets started but when i try to create a table it again fails(gets stuck) pls anyone help i am using hadoop 0.20.0 which is working fine and hbase 0.92.0 i have 3 pc's in cluster one master and two slaves all running windows xp also tell that is DNS (both forward and backward lookup working)necessary for hbase in my case is there any way to replicate hbase table to all region servers i.e. i want to have a copy of table at each pc and want to access them locally(when i execute map task they should use their local copy of hbase table) plz help..!! thanx in advance -- 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] [Resolved] (HBASE-5300) Research website symolic links for renaming of HBase book to HBase Reference Guide
[ https://issues.apache.org/jira/browse/HBASE-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5300. -- Resolution: Fixed Fix Version/s: 0.96.0 I committed attached patch. Everywhere else seems to talk about Reference Guide. Closing this. Good on you Doug. Research website symolic links for renaming of HBase book to HBase Reference Guide -- Key: HBASE-5300 URL: https://issues.apache.org/jira/browse/HBASE-5300 Project: HBase Issue Type: Task Reporter: Doug Meil Assignee: stack Fix For: 0.96.0 Attachments: 5300.txt Creating this task per a conversation I had with stack last week. -- 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] [Resolved] (HBASE-5725) HBaseClient throws NPE while in Connection#receiveResponse call.
[ https://issues.apache.org/jira/browse/HBASE-5725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5725. -- Resolution: Duplicate Closing as dup of hbase-5759 (Thanks Uma for noticing) HBaseClient throws NPE while in Connection#receiveResponse call. Key: HBASE-5725 URL: https://issues.apache.org/jira/browse/HBASE-5725 Project: HBase Issue Type: Bug Reporter: Uma Maheswara Rao G When i am running TestSplitTransactionOnCluster, it is throwing NPE from HBaseClient HBaseClient: RpcResponse response = RpcResponse.parseDelimitedFrom(in); int id = response.getCallId(); The above code throws NPE. -- 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] [Resolved] (HBASE-5471) Upgrade hadoop to 1.0.2
[ https://issues.apache.org/jira/browse/HBASE-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5471. -- Resolution: Duplicate Resolving as duplicate of hbase-5721 (though this was created first -- I should have used this one) Upgrade hadoop to 1.0.2 --- Key: HBASE-5471 URL: https://issues.apache.org/jira/browse/HBASE-5471 Project: HBase Issue Type: Task Reporter: Zhihong Yu Now that MAPREDUCE-3583 has been integrated, we should be prepared to upgrade hadoop to 1.0.2 Unit tests which fail on Apache QA machines due to NumberFormatException should pass after upgrade. -- 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] [Resolved] (HBASE-5704) HBASE-4398 mistakenly rolled back on trunk
[ https://issues.apache.org/jira/browse/HBASE-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5704. -- Resolution: Fixed Fix Version/s: 0.96.0 Assignee: stack Committed to trunk. HBASE-4398 mistakenly rolled back on trunk -- Key: HBASE-5704 URL: https://issues.apache.org/jira/browse/HBASE-5704 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.96.0 Attachments: 5704.txt -- 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] [Resolved] (HBASE-5695) Use Hadoop's DataOutputOutputStream instead of have a copy local
[ https://issues.apache.org/jira/browse/HBASE-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5695. -- Resolution: Duplicate hbase-5696 (Thanks Ram) Use Hadoop's DataOutputOutputStream instead of have a copy local Key: HBASE-5695 URL: https://issues.apache.org/jira/browse/HBASE-5695 Project: HBase Issue Type: Improvement Reporter: stack -- 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] [Resolved] (HBASE-5694) getRowsWithColumnsTs() in Thrift service handles timestamps incorrectly
[ https://issues.apache.org/jira/browse/HBASE-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5694. -- Resolution: Fixed Fix Version/s: (was: 0.92.2) 0.94.0 Hadoop Flags: Reviewed Applied to 0.94 and to trunk. Thanks for the patch Wouter (I ran testthriftserver local and it passed). Doesn't look like thrift2 has similar code so passed on trying to apply the patch there. getRowsWithColumnsTs() in Thrift service handles timestamps incorrectly --- Key: HBASE-5694 URL: https://issues.apache.org/jira/browse/HBASE-5694 Project: HBase Issue Type: Bug Components: thrift Affects Versions: 0.92.1 Reporter: Wouter Bolsterlee Fix For: 0.94.0 Attachments: HBASE-5694-trunk-20120402.patch, HBASE-5694.patch The getRowsWithColumnsTs() method in the Thrift interface only applies the timestamp if columns are explicitly specified. However, this method also allows for columns to be unspecified (this is even used internally to implement e.g. getRows()). The cause of the bug is a minor scoping issue: the time range is set inside a wrong if statement. -- 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] [Resolved] (HBASE-2186) hbase master should publish more stats
[ https://issues.apache.org/jira/browse/HBASE-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2186. -- Resolution: Duplicate Resolving at Otis's suggestion. Master has more stats now. Could do w/ more but let this be enough to close this issue. hbase master should publish more stats -- Key: HBASE-2186 URL: https://issues.apache.org/jira/browse/HBASE-2186 Project: HBase Issue Type: Bug Components: metrics Reporter: ryan rawson Attachments: screenshot-1.jpg, screenshot-2.jpg hbase master only publishes cluster.requests to ganglia. we should also publish regionserver count and other interesting metrics. -- 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] [Resolved] (HBASE-5671) hbase.metrics.showTableName should be true by default
[ https://issues.apache.org/jira/browse/HBASE-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5671. -- Resolution: Fixed Hadoop Flags: Reviewed I committed to the 0.94 branch too... will be in 0.94.1 or in the next RC. hbase.metrics.showTableName should be true by default - Key: HBASE-5671 URL: https://issues.apache.org/jira/browse/HBASE-5671 Project: HBase Issue Type: Improvement Components: metrics Reporter: Enis Soztutar Assignee: Enis Soztutar Priority: Critical Fix For: 0.94.1 Attachments: HBASE-5671_v1.patch HBASE-4768 added per-cf metrics and a new configuration option hbase.metrics.showTableName. We should switch the conf option to true by default, since it is not intuitive (at least to me) to aggregate per-cf across tables by default, and it seems confusing to report on cf's without table names. -- 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] [Resolved] (HBASE-4398) If HRegionPartitioner is used in MapReduce, client side configurations are overwritten by hbase-site.xml.
[
https://issues.apache.org/jira/browse/HBASE-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4398.
--
Resolution: Fixed
Fix Version/s: 0.94.1
0.92.2
Assignee: Takuya Ueshin
Hadoop Flags: Reviewed
If HRegionPartitioner is used in MapReduce, client side configurations are
overwritten by hbase-site.xml.
-
Key: HBASE-4398
URL: https://issues.apache.org/jira/browse/HBASE-4398
Project: HBase
Issue Type: Bug
Components: mapreduce
Affects Versions: 0.90.4
Reporter: Takuya Ueshin
Assignee: Takuya Ueshin
Fix For: 0.92.2, 0.94.1
Attachments: HBASE-4398.patch
If HRegionPartitioner is used in MapReduce, client side configurations are
overwritten by hbase-site.xml.
We can reproduce the problem by the following instructions:
{noformat}
- Add HRegionPartitioner.class to the 4th argument of
TableMapReduceUtil#initTableReducerJob()
at line around 133
in src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableMapReduce.java
- Change or remove hbase.zookeeper.property.clientPort property
in hbase-site.xml ( for example, changed to 12345 ).
- run testMultiRegionTable()
{noformat}
Then I got error messages as following:
{noformat}
2011-09-12 22:28:51,020 DEBUG [Thread-832] zookeeper.ZKUtil(93): hconnection
opening connection to ZooKeeper with ensemble (localhost:12345)
2011-09-12 22:28:51,022 INFO [Thread-832]
zookeeper.RecoverableZooKeeper(89): The identifier of this process is
43200@imac.local
2011-09-12 22:28:51,123 WARN [Thread-832]
zookeeper.RecoverableZooKeeper(161): Possibly transient ZooKeeper exception:
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
= ConnectionLoss for /hbase/master
2011-09-12 22:28:51,123 INFO [Thread-832]
zookeeper.RecoverableZooKeeper(173): The 1 times to retry ZooKeeper after
sleeping 1000 ms
=
2011-09-12 22:29:02,418 ERROR [Thread-832] mapreduce.HRegionPartitioner(125):
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@2e54e48d
closed
2011-09-12 22:29:02,422 WARN [Thread-832] mapred.LocalJobRunner$Job(256):
job_local_0001
java.lang.NullPointerException
at
org.apache.hadoop.hbase.mapreduce.HRegionPartitioner.setConf(HRegionPartitioner.java:128)
at
org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:62)
at
org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:117)
at
org.apache.hadoop.mapred.MapTask$NewOutputCollector.init(MapTask.java:527)
at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:613)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:305)
at
org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:177)
{noformat}
I think HTable should connect to ZooKeeper at port 21818 configured at client
side instead of 12345 in hbase-site.xml
and It might be caused by HBaseConfiguration.addHbaseResources(conf); in
HRegionPartitioner#setConf(Configuration).
And this might mean that all of client side configurations, also configured
in hbase-site.xml, are overwritten caused by this problem.
--
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] [Resolved] (HBASE-5673) The OOM problem of IPC client call cause all handle block
[ https://issues.apache.org/jira/browse/HBASE-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5673. -- Resolution: Fixed Fix Version/s: 0.94.1 0.92.2 0.90.7 Hadoop Flags: Reviewed Committed to 0.90, 0.92, 0.94 and trunk. Thanks for the patch Xufeng The OOM problem of IPC client call cause all handle block -- Key: HBASE-5673 URL: https://issues.apache.org/jira/browse/HBASE-5673 Project: HBase Issue Type: Bug Affects Versions: 0.90.6 Environment: 0.90.6 Reporter: xufeng Assignee: xufeng Fix For: 0.90.7, 0.92.2, 0.94.1 Attachments: HBASE-5673-90.patch if HBaseClient meet unable to create new native thread exception, the call will never complete because it be lost in calls queue. -- 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] [Resolved] (HBASE-5610) Add GA to hbase.apache.org
[ https://issues.apache.org/jira/browse/HBASE-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5610. -- Resolution: Fixed Fix Version/s: 0.96.0 Release Note: Adds GA hooks to our website. Committed to trunk. Add GA to hbase.apache.org -- Key: HBASE-5610 URL: https://issues.apache.org/jira/browse/HBASE-5610 Project: HBase Issue Type: Task Reporter: stack Fix For: 0.96.0 Attachments: ga.txt Lets add the bit of script necessary tracking hbase.apache.org in google analytics. I was going to get it going first then open it to the PMC for viewing. -- 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] [Resolved] (HBASE-2462) Review compaction heuristic and move compaction code out so standalone and independently testable
[ https://issues.apache.org/jira/browse/HBASE-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2462. -- Resolution: Won't Fix Closing. Superceeded by other work in compaction. I opened HBASE-5627 for the outstanding simulator work. Review compaction heuristic and move compaction code out so standalone and independently testable - Key: HBASE-2462 URL: https://issues.apache.org/jira/browse/HBASE-2462 Project: HBase Issue Type: Improvement Components: performance Reporter: stack Assignee: Jonathan Gray Priority: Critical Labels: moved_from_0_20_5 Attachments: 2462v2.txt, standalone.txt Anything that improves our i/o profile makes hbase run smoother. Over in HBASE-2457, good work has been done already describing the tension between minimizing compactions versus minimizing count of store files. This issue is about following on from what has been done in 2457 but also, breaking the hard-to-read compaction code out of Store.java out to a standalone class that can be the easier tested (and easily analyzed for its performance characteristics). If possible, in the refactor, we'd allow specification of alternate merge sort implementations. -- 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] [Resolved] (HBASE-5627) Compactions simulator tool for proofing algorithms
[ https://issues.apache.org/jira/browse/HBASE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5627. -- Resolution: Duplicate Dup of hbase-5626 Compactions simulator tool for proofing algorithms -- Key: HBASE-5627 URL: https://issues.apache.org/jira/browse/HBASE-5627 Project: HBase Issue Type: Task Reporter: stack Priority: Minor Labels: noob A tool to run compaction simulations would be a nice to have. We could use it to see how well an algo ran under different circumstances loaded w/ different value types with different rates of flushes and splits, etc. HBASE-2462 had one (see in patch). Or we could try doing it using something like this: http://en.wikipedia.org/wiki/Discrete_event_simulation -- 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] [Resolved] (HBASE-4058) Extend TestHBaseFsck with a complete .META. recovery scenario
[ https://issues.apache.org/jira/browse/HBASE-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4058. -- Resolution: Won't Fix This issue subsumed by Jon's work on uber-hbck. Extend TestHBaseFsck with a complete .META. recovery scenario - Key: HBASE-4058 URL: https://issues.apache.org/jira/browse/HBASE-4058 Project: HBase Issue Type: Improvement Components: hbck Reporter: Andrew Purtell Assignee: stack Fix For: 0.94.0 We should have a unit test that launches a minicluster and constructs a few tables, then deletes META files on disk, then bounces the master, then recovers the result with HBCK. Perhaps it is possible to extend TestHBaseFsck to do this. -- 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] [Resolved] (HBASE-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5560. -- Resolution: Fixed Fix Version/s: (was: 0.96.0) 0.92.2 Hadoop Flags: Reviewed Applied trunk, 0.92 and 0.94 branches. Thanks for patch Dhruba. Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.92.2, 0.94.0 Attachments: D2241.1.patch, D2241.2.patch, D2241.3.patch, D2241.4.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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] [Resolved] (HBASE-5270) Handle potential data loss due to concurrent processing of processFaileOver and ServerShutdownHandler
[ https://issues.apache.org/jira/browse/HBASE-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5270. -- Resolution: Fixed Hadoop Flags: Reviewed Committed to 0.92 branch. Thanks for the patch Chunhui. Handle potential data loss due to concurrent processing of processFaileOver and ServerShutdownHandler - Key: HBASE-5270 URL: https://issues.apache.org/jira/browse/HBASE-5270 Project: HBase Issue Type: Sub-task Components: master Reporter: Zhihong Yu Assignee: chunhui shen Fix For: 0.92.2 Attachments: 5270-90-testcase.patch, 5270-90-testcasev2.patch, 5270-90.patch, 5270-90v2.patch, 5270-90v3.patch, 5270-testcase.patch, 5270-testcasev2.patch, HBASE-5270-92v11.patch, HBASE-5270v11.patch, hbase-5270.patch, hbase-5270v10.patch, hbase-5270v2.patch, hbase-5270v4.patch, hbase-5270v5.patch, hbase-5270v6.patch, hbase-5270v7.patch, hbase-5270v8.patch, hbase-5270v9.patch, sampletest.txt This JIRA continues the effort from HBASE-5179. Starting with Stack's comments about patches for 0.92 and TRUNK: Reviewing 0.92v17 isDeadServerInProgress is a new public method in ServerManager but it does not seem to be used anywhere. Does isDeadRootServerInProgress need to be public? Ditto for meta version. This method param names are not right 'definitiveRootServer'; what is meant by definitive? Do they need this qualifier? Is there anything in place to stop us expiring a server twice if its carrying root and meta? What is difference between asking assignment manager isCarryingRoot and this variable that is passed in? Should be doc'd at least. Ditto for meta. I think I've asked for this a few times - onlineServers needs to be explained... either in javadoc or in comment. This is the param passed into joinCluster. How does it arise? I think I know but am unsure. God love the poor noob that comes awandering this code trying to make sense of it all. It looks like we get the list by trawling zk for regionserver znodes that have not checked in. Don't we do this operation earlier in master setup? Are we doing it again here? Though distributed split log is configured, we will do in master single process splitting under some conditions with this patch. Its not explained in code why we would do this. Why do we think master log splitting 'high priority' when it could very well be slower. Should we only go this route if distributed splitting is not going on. Do we know if concurrent distributed log splitting and master splitting works? Why would we have dead servers in progress here in master startup? Because a servershutdownhandler fired? This patch is different to the patch for 0.90. Should go into trunk first with tests, then 0.92. Should it be in this issue? This issue is really hard to follow now. Maybe this issue is for 0.90.x and new issue for more work on this trunk patch? This patch needs to have the v18 differences applied. -- 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] [Resolved] (HBASE-3830) MemStoreFlusher deadlock detected by JVM
[ https://issues.apache.org/jira/browse/HBASE-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-3830. -- Resolution: Duplicate Marking dup of hbase-4367. Thanks Chris. MemStoreFlusher deadlock detected by JVM Key: HBASE-3830 URL: https://issues.apache.org/jira/browse/HBASE-3830 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.90.1 Reporter: zhoushuaifeng Priority: Trivial Found one Java-level deadlock: = IPC Server handler 9 on 60020: waiting to lock monitor 0x409f3908 (object 0x7fe7cbacbd48, a org.apache.hadoop.hbase.regionserver.MemStoreFlusher), which is held by IPC Server handler 7 on 60020 IPC Server handler 7 on 60020: waiting for ownable synchronizer 0x7fe7cbb06228, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by regionserver60020.cacheFlusher regionserver60020.cacheFlusher: waiting to lock monitor 0x409f3908 (object 0x7fe7cbacbd48, a org.apache.hadoop.hbase.regionserver.MemStoreFlusher), which is held by IPC Server handler 7 on 60020 Java stack information for the threads listed above: === IPC Server handler 9 on 60020: at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.reclaimMemStoreMemory(MemStoreFlusher.java) - waiting to lock 0x7fe7cbacbd48 (a org.apache.hadoop.hbase.regionserver.MemStoreFlusher) at org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:2558) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039) IPC Server handler 7 on 60020: at sun.misc.Unsafe.$$YJP$$park(Native Method) - parking to wait for 0x7fe7cbb06228 (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at sun.misc.Unsafe.park(Unsafe.java) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.reclaimMemStoreMemory(MemStoreFlusher.java:429) - locked 0x7fe7cbacbd48 (a org.apache.hadoop.hbase.regionserver.MemStoreFlusher) at org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:2558) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039) regionserver60020.cacheFlusher: at java.util.ResourceBundle.endLoading(ResourceBundle.java:1506) - waiting to lock 0x7fe7cbacbd48 (a org.apache.hadoop.hbase.regionserver.MemStoreFlusher) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1379) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234) at java.util.ResourceBundle.getBundle(ResourceBundle.java:832) at sun.util.resources.LocaleData$1.run(LocaleData.java:127) at java.security.AccessController.$$YJP$$doPrivileged(Native Method) at java.security.AccessController.doPrivileged(AccessController.java) at sun.util.resources.LocaleData.getBundle(LocaleData.java:125) at sun.util.resources.LocaleData.getTimeZoneNames(LocaleData.java:97) at
[jira] [Resolved] (HBASE-5581) Creating a table with invalid syntax does not give an error message when it fails
[
https://issues.apache.org/jira/browse/HBASE-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5581.
--
Resolution: Fixed
Hadoop Flags: Reviewed
Thanks for the patch Binu. Committed trunk and 0.94.
Creating a table with invalid syntax does not give an error message when it
fails
-
Key: HBASE-5581
URL: https://issues.apache.org/jira/browse/HBASE-5581
Project: HBase
Issue Type: Bug
Components: shell
Reporter: Binu John
Priority: Minor
Fix For: 0.94.0, 0.96.0
Attachments: 5581trunk.patch, D2343.1.patch
Creating a table with invalid syntax does not give an error message when it
fails. In this case, it doesn't actually create the CF requested, but doesn't
give any indication to the user that it failed.
create 'test', {NAME = 'test', VERSIONS = 1, BLOCKCACHE = true, NUMREGIONS
= 20, SPLITALGO = HexStringSplit, COMPRESSION = 'LZO', BLOOMFILTER =
'ROW'}
0 row(s) in 3.0930 seconds
hbase(main):002:0 describe 'test'
DESCRIPTION
ENABLED
{NAME = 'test', FAMILIES = []}
true
1 row(s) in 0.1430 seconds
Putting {NUMREGIONS = 20, SPLITALGO = HexStringSplit} into a separate
stanza works fine, so the feature is fine.
create 'test', {NAME = 'test', VERSIONS = 1, BLOCKCACHE = true,
COMPRESSION = 'LZO', BLOOMFILTER = 'ROW'}, {NUMREGIONS = 20, SPLITALGO =
HexStringSplit}
0 row(s) in 2.7860 seconds
hbase(main):002:0 describe 'test'
DESCRIPTION
ENABLED
{NAME = 'test', FAMILIES = [{NAME = 'test', DATA_BLOCK_ENCODING =
'NONE', true
BLOOMFILTER = 'ROW', REPLICATION_SCOPE = '0', COMPRESSION = 'LZO',
VERSIONS
= '1', TTL = '2147483647', BLOCKSIZE = '65536', BLOOMFILTER_ERRORRATE =
'
0.01', ENCODE_ON_DISK = 'true', IN_MEMORY = 'false', BLOCKCACHE =
'true'}]}
We should throw an error if we can't create the CF so it's clear to the user.
--
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] [Resolved] (HBASE-5592) Make it easier to get a table from shell
[
https://issues.apache.org/jira/browse/HBASE-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5592.
--
Resolution: Fixed
Fix Version/s: 0.92.2
Hadoop Flags: Reviewed
Committed trunk, 0.94, and 0.92 branches. Thanks for the patch Ben.
Make it easier to get a table from shell
Key: HBASE-5592
URL: https://issues.apache.org/jira/browse/HBASE-5592
Project: HBase
Issue Type: Improvement
Components: shell
Affects Versions: 0.94.0
Reporter: Ben West
Assignee: Ben West
Priority: Trivial
Labels: shell
Fix For: 0.92.2, 0.94.0
Attachments: publicTable.patch
The one argument constructor to HTable was removed at some point, which means
that you now have to pass in a Configuration to instantiate an HTable. This
is annoying for me when I create quick scripts.
This JIRA is a tiny patch which lets you get an HTable instance in the shell
by doing
{code}foo_table = @shell.hbase_table('foo').table{code}
Basically, it is changing table to be a public member rather than a private
one.
--
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] [Resolved] (HBASE-5314) Gracefully rolling restart region servers in rolling-restart.sh
[ https://issues.apache.org/jira/browse/HBASE-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5314. -- Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Committed to trunk. Thanks for the patch Yifeng. Gracefully rolling restart region servers in rolling-restart.sh --- Key: HBASE-5314 URL: https://issues.apache.org/jira/browse/HBASE-5314 Project: HBase Issue Type: Improvement Components: scripts Reporter: Yifeng Jiang Priority: Minor Fix For: 0.96.0 Attachments: HBASE-5314.patch, HBASE-5314.patch.2 The rolling-restart.sh has a --rs-only option which simply restarts all region servers in the cluster. Consider improve it to gracefully restart region servers to avoid the offline time of the regions deployed on that server, and keep the region distributions same as what it was before the restarting. -- 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] [Resolved] (HBASE-5574) DEFAULT_MAX_FILE_SIZE defaults to a negative value
[ https://issues.apache.org/jira/browse/HBASE-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5574. -- Resolution: Fixed Fix Version/s: 0.94.0 Hadoop Flags: Reviewed Applied trunk and 0.94 branch. DEFAULT_MAX_FILE_SIZE defaults to a negative value -- Key: HBASE-5574 URL: https://issues.apache.org/jira/browse/HBASE-5574 Project: HBase Issue Type: Bug Affects Versions: 0.94.0 Reporter: Michael Drzal Assignee: Michael Drzal Fix For: 0.94.0 Attachments: HBASE-5574.patch HBASE-4365 changed the value of DEFAULT_MAX_FILE_SIZE from 256MB to 10G. Here is the line of code: public static final long DEFAULT_MAX_FILE_SIZE = 10 * 1024 * 1024 * 1024; The problem is that java evaluates the constant as an int which wraps and gets assigned to a long. I verified this with a test. The quick fix is to change the end to 1024L; -- 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] [Resolved] (HBASE-3772) Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS
[ https://issues.apache.org/jira/browse/HBASE-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-3772. -- Resolution: Cannot Reproduce Resolving 'cannot reproduce'. I don't think we have this issue anymore. We can open new issue if we run into it again. Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS --- Key: HBASE-3772 URL: https://issues.apache.org/jira/browse/HBASE-3772 Project: HBase Issue Type: Bug Reporter: Gary Helmling I ran across this issue on a 0.20 based branch, so I'm not sure if this is still an issue for 0.90+. However, 0.90 and current trunk do still make use of DNS.getDefaultHost(), so I wanted to open this for discussion. In 0.20, the problem was: 1. configure hbase-site.xml with hbase.regionserver.dns.interface=xxx 2. IP bound on interface xxx has reverse DNS correctly configured 3. DNS.getDefaultHost() calls DNS.reverseDns() for this IP, which does a JNDI bind to the DNS provider, returning the *absolute* hostname: host1.my.domain. 4. RS reports startup to master as host1.my.domain.,60020,1234... 5. BaseScanner when scanning .META. sees region assignments as not valid because the resolved hostname from IP goes through InetSocketAddress.getHostName() which returns the canonicalized form (host1.my.domain != host1.my.domain. though they are equivalent) I know the master - RS negotiated hostname has completely changed for 0.90. So hopefully this is no longer an issue and we can close as invalid and go have a beer. But given the underlying problem in DNS.getDefaultHost(), I wanted to confirm this. -- 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] [Resolved] (HBASE-5552) Clean up our jmx view; its a bit of a mess
[ https://issues.apache.org/jira/browse/HBASE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5552. -- Resolution: Fixed Fix Version/s: 0.94.0 0.92.1 Assignee: stack Committed small patch to 0.92, 0.94 and trunk. Only person I'm messing up is Benoit I believe (he amended tsdb to read beans in new location... will talk to him) Clean up our jmx view; its a bit of a mess -- Key: HBASE-5552 URL: https://issues.apache.org/jira/browse/HBASE-5552 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.92.1, 0.94.0 Attachments: 0.92.0jmx.png, 5552.txt, currentjmxview.png, patchedjmxview.png Fix before we release 0.92.1 -- 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] [Resolved] (HBASE-5518) Incorrect warning in splitlogmanager
[ https://issues.apache.org/jira/browse/HBASE-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5518. -- Resolution: Duplicate Dup of hbase-5519 Incorrect warning in splitlogmanager Key: HBASE-5518 URL: https://issues.apache.org/jira/browse/HBASE-5518 Project: HBase Issue Type: Improvement Reporter: Prakash Khemani because of recently added behavior - where the splitlogmanager timeout thread get's data from zk node just to check that the zk node is there ... we might have multiple watches firing without the task znode expiring. remove the poor warning message. (internally, there was an assert that failed in Mikhail's tests) -- 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] [Resolved] (HBASE-5540) Update apache jenkins to include 0.94 and builds against Hadoop 0.23
[ https://issues.apache.org/jira/browse/HBASE-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5540. -- Resolution: Fixed Assignee: stack I grouped the 0.94 builds under the hbase area up on jenkins and reenabled the 0.23 builds. In all of these jobs, I've removed the lock on hbase. I did it originally in desperation to see if it was responsible for hbase builds hanging jenkins servers a while back. Since I did it, we've not had a hang. Hopefully this is it (though when I read the builds setup prescription, it suggests that long builds like ours should use a lock). Update apache jenkins to include 0.94 and builds against Hadoop 0.23 Key: HBASE-5540 URL: https://issues.apache.org/jira/browse/HBASE-5540 Project: HBase Issue Type: Task Components: build, test Reporter: Jonathan Hsieh Assignee: stack Labels: jenkins Currently there is no hbase 0.94 apache jenkins build and the trunk on hadoop 0.23 builds are disabled. Ideally we should add the former and re-enable the latter. -- 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] [Resolved] (HBASE-5537) MXBean shouldn't have a dependence on InterfaceStability until 0.96
[ https://issues.apache.org/jira/browse/HBASE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5537. -- Resolution: Fixed Hadoop Flags: Reviewed Committed to 0.92 and 0.94 branches. MXBean shouldn't have a dependence on InterfaceStability until 0.96 --- Key: HBASE-5537 URL: https://issues.apache.org/jira/browse/HBASE-5537 Project: HBase Issue Type: Bug Reporter: Jean-Daniel Cryans Assignee: stack Fix For: 0.92.1, 0.94.0 Attachments: 5537.txt HBASE-5325 has a dependence on InterfaceStability.Evolving in 0.92 and it shouldn't have it until 0.96. One problem it currently causes is that 0.92 can't be compiled against CDH3u3. Assigning to Stack. -- 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] [Resolved] (HBASE-5373) Table level lock to prevent the race of multiple table level operation
[ https://issues.apache.org/jira/browse/HBASE-5373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5373. -- Resolution: Duplicate Resolving as duplicate. Liyin, you did it first so I should be resolving HBASE-5494 as a duplicate of this but HBASE-5494 has a little bit more going on. Hope you don't mind. Are you working on this? Table level lock to prevent the race of multiple table level operation -- Key: HBASE-5373 URL: https://issues.apache.org/jira/browse/HBASE-5373 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang A table level lock can guarantee that only one table operation would happen at one time for each table. The master should require and release these table locks correctly during the failover time. One proposal is to keep track of the lock and its corresponding operation in the zookeeper. If there is a master failover, the secondary should have a way to check whether these operations are succeeded nor not before releasing the 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] [Resolved] (HBASE-5522) hbase 0.92 test artifacts are missing from Maven central
[ https://issues.apache.org/jira/browse/HBASE-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5522. -- Resolution: Fixed Fix Version/s: 0.94.0 0.92.1 Assignee: stack Confirmed that test.jar shows in repo. A sighting happened out on the mailing list. Committed this patch to 0.92, 0.94, and trunk. hbase 0.92 test artifacts are missing from Maven central Key: HBASE-5522 URL: https://issues.apache.org/jira/browse/HBASE-5522 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.92.0 Reporter: Roman Shaposhnik Assignee: stack Fix For: 0.92.1, 0.94.0 Attachments: 5522.txt Could someone with enough karma, please, publish the test artifacts for 0.92.0? -- 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] [Resolved] (HBASE-5519) Incorrect warning in splitlogmanager
[ https://issues.apache.org/jira/browse/HBASE-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5519. -- Resolution: Fixed Assignee: Prakash Khemani Hadoop Flags: Reviewed Committed to 0.92, 0.94 and to trunk. This is a usability thing. Incorrect warning in splitlogmanager Key: HBASE-5519 URL: https://issues.apache.org/jira/browse/HBASE-5519 Project: HBase Issue Type: Improvement Reporter: Prakash Khemani Assignee: Prakash Khemani Attachments: 0001-HBASE-5519-Incorrect-warning-in-splitlogmanager.patch, 5519.92.txt because of recently added behavior - where the splitlogmanager timeout thread get's data from zk node just to check that the zk node is there ... we might have multiple watches firing without the task znode expiring. remove the poor warning message. (internally, there was an assert that failed in Mikhail's tests) -- 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] [Resolved] (HBASE-5524) Add a couple of more filters to our rat exclusion set
[ https://issues.apache.org/jira/browse/HBASE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5524. -- Resolution: Fixed Assignee: stack Committed to 0.92, 0.94, and trunk Add a couple of more filters to our rat exclusion set - Key: HBASE-5524 URL: https://issues.apache.org/jira/browse/HBASE-5524 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.92.1, 0.94.0 Attachments: rat.txt Build up on jenkins is failing because I just enabled the rat/license check as part of our build. We're failing because CP is writing test data into top-level at ./test. -- 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] [Resolved] (HBASE-5286) bin/hbase's logic of adding Hadoop jar files to the classpath is fragile when presented with split packaged Hadoop 0.23 installation
[
https://issues.apache.org/jira/browse/HBASE-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5286.
--
Resolution: Fixed
Fix Version/s: 0.94.0
0.92.1
Hadoop Flags: Reviewed
I tried it. Works. Default codepath unaffected. Committed to 0.94, 0.92, and
trunk. Thanks for the patch Roman.
bin/hbase's logic of adding Hadoop jar files to the classpath is fragile when
presented with split packaged Hadoop 0.23 installation
Key: HBASE-5286
URL: https://issues.apache.org/jira/browse/HBASE-5286
Project: HBase
Issue Type: Bug
Components: scripts
Affects Versions: 0.92.0
Reporter: Roman Shaposhnik
Assignee: Roman Shaposhnik
Fix For: 0.92.1, 0.94.0
Attachments: HBASE-5286.patch.txt
Here's the bit from bin/hbase that might need TLC now that Hadoop can be
spotted in the wild in split-package configuration:
{noformat}
#If avail, add Hadoop to the CLASSPATH and to the JAVA_LIBRARY_PATH
if [ ! -z $HADOOP_HOME ]; then
HADOOPCPPATH=
if [ -z $HADOOP_CONF_DIR ]; then
HADOOPCPPATH=$(append_path ${HADOOPCPPATH} ${HADOOP_HOME}/conf)
else
HADOOPCPPATH=$(append_path ${HADOOPCPPATH} ${HADOOP_CONF_DIR})
fi
if [ `echo ${HADOOP_HOME}/hadoop-core*.jar` !=
${HADOOP_HOME}/hadoop-core*.jar ] ; then
HADOOPCPPATH=$(append_path ${HADOOPCPPATH} `ls
${HADOOP_HOME}/hadoop-core*.jar | head -1`)
else
HADOOPCPPATH=$(append_path ${HADOOPCPPATH} `ls
${HADOOP_HOME}/hadoop-common*.jar | head -1`)
HADOOPCPPATH=$(append_path ${HADOOPCPPATH} `ls
${HADOOP_HOME}/hadoop-hdfs*.jar | head -1`)
HADOOPCPPATH=$(append_path ${HADOOPCPPATH} `ls
${HADOOP_HOME}/hadoop-mapred*.jar | head -1`)
fi
{noformat}
There's a couple of issues with the above code:
0. HADOOP_HOME is now deprecated in Hadoop 0.23
1. the list of jar files added to the class-path should be revised
2. we need to figure out a more robust way to get the jar files that are
needed to the classpath (things like hadoop-mapred*.jar tend to match
src/test jars as well)
Better yet, it would be useful to look into whether we can transition HBase's
bin/hbase onto using bin/hadoop as a launcher script instead of direct JAVA
invocations (Pig, Hive, Sqoop and Mahout already do that)
--
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] [Resolved] (HBASE-5511) More doc on maven release process
[ https://issues.apache.org/jira/browse/HBASE-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5511. -- Resolution: Fixed Fix Version/s: 0.94.0 0.92.1 Assignee: stack Committed to trunk and then I committed the pom patch that disables the running of tests on mvn release to 0.92 and 0.94. This addition may be responsible for our not uploading a hbase-test.jar; tbd. More doc on maven release process - Key: HBASE-5511 URL: https://issues.apache.org/jira/browse/HBASE-5511 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.92.1, 0.94.0 Attachments: doc.txt -- 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] [Resolved] (HBASE-5430) Fix licenses in 0.92.1 -- RAT plugin won't pass
[ https://issues.apache.org/jira/browse/HBASE-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5430. -- Resolution: Fixed Assignee: stack Applied to 0.92, 0.94 and trunk. Fix licenses in 0.92.1 -- RAT plugin won't pass --- Key: HBASE-5430 URL: https://issues.apache.org/jira/browse/HBASE-5430 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.92.1 Attachments: 5430.txt Use the -Drelease profile to see we are missing 30 or so license. 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] [Resolved] (HBASE-5486) Warn message in HTable: Stringify the byte[]
[
https://issues.apache.org/jira/browse/HBASE-5486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5486.
--
Resolution: Fixed
Fix Version/s: 0.96.0
Hadoop Flags: Reviewed
Committed to trunk. Thanks for the patch Himanshu.
Warn message in HTable: Stringify the byte[]
Key: HBASE-5486
URL: https://issues.apache.org/jira/browse/HBASE-5486
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.92.0
Reporter: Himanshu Vashishtha
Assignee: Himanshu Vashishtha
Priority: Trivial
Labels: noob
Fix For: 0.96.0
Attachments: 5486-v2.patch, 5486.patch
The warn message in the method getStartEndKeys() in HTable can be improved by
stringifying the byte array for Regions.Qualifier
Currently, a sample message is like :
12/01/17 16:36:34 WARN client.HTable: Null [B@552c8fa8 cell in
keyvalues={test5,\xC9\xA2\x00\x00\x00\x00\x00\x00/00_0,1326642537734.dbc62b2765529a9ad2ddcf8eb58cb2dc./info:server/1326750341579/Put/vlen=28,
test5,\xC9\xA2\x00\x00\x00\x00\x00\x00/00_0,1326642537734.dbc62b2765529a9ad2ddcf8eb58cb2dc./info:serverstartcode/1326750341579/Put/vlen=8}
--
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] [Resolved] (HBASE-5501) Handle potential data loss due to concurrent processing of processFaileOver and ServerShutdownHandler
[ https://issues.apache.org/jira/browse/HBASE-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5501. -- Resolution: Invalid Being fixed over in HBASE-5270 Handle potential data loss due to concurrent processing of processFaileOver and ServerShutdownHandler - Key: HBASE-5501 URL: https://issues.apache.org/jira/browse/HBASE-5501 Project: HBase Issue Type: Bug Reporter: chunhui shen Assignee: chunhui shen Attachments: hbase-5501.patch In a live cluster, we do the following step 1.kill the master; 1.start the master, and master is initializingï¼› 3.master complete splitLog 4.kill the META server 5.master start assigning ROOT and META 6.Now meta region data will loss since we may assign meta region before SSH finish split log for dead META 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] [Resolved] (HBASE-5454) Refuse operations from Admin before master is initialized
[ https://issues.apache.org/jira/browse/HBASE-5454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5454. -- Resolution: Fixed Committed to trunk. Thanks for the patch Chunhui. Refuse operations from Admin before master is initialized - Key: HBASE-5454 URL: https://issues.apache.org/jira/browse/HBASE-5454 Project: HBase Issue Type: Improvement Reporter: chunhui shen Assignee: chunhui shen Fix For: 0.96.0 Attachments: hbase-5454.patch, hbase-5454v2.patch In our testing environment, When master is initializing, we found conflict problems between master#assignAllUserRegions and EnableTable event, causing assigning region throw exception so that master abort itself. We think we'd better refuse operations from Admin, such as CreateTable, EnableTable,etc, It could reduce error. -- 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] [Resolved] (HBASE-5483) Allow configurable host to bind to for starting REST server from commandline
[ https://issues.apache.org/jira/browse/HBASE-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5483. -- Resolution: Fixed Fix Version/s: (was: 0.92.0) 0.94.0 0.92.1 Hadoop Flags: Reviewed Committed branch and trunk. Thanks for the patch Dan (FYI, next time, base patch inside HBASE_HOME rather than above it). Good stuff. Allow configurable host to bind to for starting REST server from commandline Key: HBASE-5483 URL: https://issues.apache.org/jira/browse/HBASE-5483 Project: HBase Issue Type: Improvement Components: rest Affects Versions: 0.92.0 Reporter: Dan Rosher Priority: Minor Fix For: 0.92.1, 0.94.0 Attachments: HBASE-5483 Current implementation binds to all interfaces, use config to store hbase.rest.host and hbase.rest.port -- 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] [Resolved] (HBASE-5477) Cannot build RPM for hbase-0.92.0
[
https://issues.apache.org/jira/browse/HBASE-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5477.
--
Resolution: Fixed
Fix Version/s: 0.94.0
0.92.1
Hadoop Flags: Reviewed
Committed 0.92 branch and trunk. Thanks for the patch Benjamin.
Cannot build RPM for hbase-0.92.0
-
Key: HBASE-5477
URL: https://issues.apache.org/jira/browse/HBASE-5477
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Environment: Operating system: CentOS 6.2
{code}
$ java -version
java version 1.6.0_22
OpenJDK Runtime Environment (IcedTea6 1.10.6) (rhel-1.43.1.10.6.el6_2-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
{code}
{code}
$ mvn -v
Warning: JAVA_HOME environment variable is not set.
Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_22
Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.32-220.el6.x86_64 arch: amd64 Family: unix
{code}
Reporter: Benjamin Lee
Fix For: 0.92.1, 0.94.0
Attachments: build.log, hbase-0.92.0.patch
Steps to reproduce:
{code}
tar xzvf hbase-0.92.0.tar.gz
cd hbase-0.92.0
mvn -Dmaven.test.skip.exec=true -P rpm install
{code}
Failure output and patch will be attached.
--
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] [Resolved] (HBASE-59) Where hbase/mapreduce have analogous configuration parameters, they should be named similarly
[ https://issues.apache.org/jira/browse/HBASE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-59. Resolution: Won't Fix We are not going to change this now I'd say (This issue is 4+ years old) Where hbase/mapreduce have analogous configuration parameters, they should be named similarly - Key: HBASE-59 URL: https://issues.apache.org/jira/browse/HBASE-59 Project: HBase Issue Type: Improvement Components: mapred Reporter: Michael Bieniosek Priority: Trivial mapreduce has a configuration property called mapred.system.dir which determines where in the DFS a jobtracker stores its data. Similarly, hbase has a configuration property called hbase.rootdir which does something very similar. These should have the same name, eg. hbase.system.dir and mapred.system.dir -- 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] [Resolved] (HBASE-587) Add auto-primary-key feature
[ https://issues.apache.org/jira/browse/HBASE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-587. - Resolution: Won't Fix Doing as Harsh suggests. Hard to do this feature in a scalable way. If wanted, we could do something like cassandra's time-based UUID to mint UUIDs that go in a chronological direction if that'd help. Add auto-primary-key feature Key: HBASE-587 URL: https://issues.apache.org/jira/browse/HBASE-587 Project: HBase Issue Type: New Feature Reporter: Bryan Duxbury Priority: Trivial Some folks seem to be interested in having their row keys automatically generated in a unique fashion. Maybe we could do something like allow the user to specify they want an automatic key, and then we'll generate a GUID that's unique for that table and return it as part of the commit. Not sure what the mechanics would look like exactly, but seems doable and it's going to be a more prevalent use case as people start to put data into HBase first without touching another system or pushing data without a natural unique primary key. -- 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] [Resolved] (HBASE-765) Adding basic Spring DI support to IndexConfiguration class.
[ https://issues.apache.org/jira/browse/HBASE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-765. - Resolution: Won't Fix We don't have IndexConfiguration anymore in our code base. Won't fix. Adding basic Spring DI support to IndexConfiguration class. --- Key: HBASE-765 URL: https://issues.apache.org/jira/browse/HBASE-765 Project: HBase Issue Type: Improvement Components: mapred Affects Versions: 0.16.0, 0.1.0, 0.1.1, 0.1.2, 0.1.3 Environment: n/a Reporter: Ryan Smith Priority: Minor Original Estimate: 20m Remaining Estimate: 20m Spring can configure classes/object graphs via xml. I am pretty much able to configure the entire MR object graph to launch MR jobs via spring except class IndexConfiguration.java. So instead of only using addFromXML() to configure IndexConfiguration, it would be nice to add support so Spring could set all class variables needed for initialization in IndexConfiguration without invoking addFromXML(). Since the class IndexConfiguration already has setters and getters for almost all its members, it's almost compliant for a spring configuration bean except one issue: no ability to configure columnMap outside of calling addFromXML(). The easiest way i can figure is to allow a setter for the column map and put any logic for checking the map integrity there. By adding a few methods to IndexConfiguration.java , it should solve the 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] [Resolved] (HBASE-1012) [performance] Try doctoring a dfsclient so it shortcircuits hdfs when blocks are local
[ https://issues.apache.org/jira/browse/HBASE-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-1012. -- Resolution: Duplicate This is done, available in hdfs. [performance] Try doctoring a dfsclient so it shortcircuits hdfs when blocks are local -- Key: HBASE-1012 URL: https://issues.apache.org/jira/browse/HBASE-1012 Project: HBase Issue Type: Task Components: performance Reporter: stack Ning Li up on list has stated that getting blocks using hdfs though the block is local takes almost the same amount of time as accesing the block over the network. See if can do something smarter when the data is known to be local short-circuiting hdfs if we can in a subclass of DFSClient (George Porter suggestion). -- 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] [Resolved] (HBASE-1339) NPE in HCM.procesRow called from master.jsp
[
https://issues.apache.org/jira/browse/HBASE-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-1339.
--
Resolution: Won't Fix
No longer pertinent. We don't see this any more.
NPE in HCM.procesRow called from master.jsp
---
Key: HBASE-1339
URL: https://issues.apache.org/jira/browse/HBASE-1339
Project: HBase
Issue Type: Bug
Reporter: stack
{code}
2009-04-22 02:10:34,710 WARN /: /master.jsp:
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.HConnectionManager$TableServers$1.processRow(HConnectionManager.java:344)
at
org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:64)
at
org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:29)
at
org.apache.hadoop.hbase.client.HConnectionManager$TableServers.listTables(HConnectionManager.java:351)
at
org.apache.hadoop.hbase.client.HBaseAdmin.listTables(HBaseAdmin.java:121)
at
org.apache.hadoop.hbase.generated.master.master_jsp._jspService(master_jsp.java:121)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:475)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
at org.mortbay.http.HttpServer.service(HttpServer.java:954)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
{code}
--
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] [Resolved] (HBASE-1748) ClusterStatus needs to print out who has master role
[ https://issues.apache.org/jira/browse/HBASE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-1748. -- Resolution: Duplicate Fixed by 'HBASE-5209 HConnection/HMasterInterface should allow for way to get hostname of currently active master in multi-master HBase setup' ClusterStatus needs to print out who has master role Key: HBASE-1748 URL: https://issues.apache.org/jira/browse/HBASE-1748 Project: HBase Issue Type: Bug Components: master Reporter: stack Priority: Trivial Attachments: HBASE-1748.patch Is in zk_dump but not in clusterstatus. You need it when you have 5 masters and you are trying to find the 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] [Resolved] (HBASE-1559) IllegalThreadStateException during LocalHBaseCluster shutdown if more than one regionserver is started
[
https://issues.apache.org/jira/browse/HBASE-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-1559.
--
Resolution: Won't Fix
We don't see this anymore. Reopen if it happens again.
IllegalThreadStateException during LocalHBaseCluster shutdown if more than
one regionserver is started
--
Key: HBASE-1559
URL: https://issues.apache.org/jira/browse/HBASE-1559
Project: HBase
Issue Type: Bug
Reporter: Andrew Purtell
Priority: Minor
IllegalThreadStateException during LocalHBaseCluster shutdown if more than
one regionserver is started:
{noformat}
Thread [RegionServer:1] (Suspended (exception IllegalThreadStateException))
FileSystem$ClientFinalizer(Thread).start() line: 595
HRegionServer.runThread(Thread,long) line: 691
HRegionServer.run() line: 675
LocalHBaseCluster$RegionServerThread(Thread).run() line: 691
{noformat}
If started with only one region server, shut down is clean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-1109) Explore the possibility of storing the configuration files in Zookeeper
[ https://issues.apache.org/jira/browse/HBASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-1109. -- Resolution: Won't Fix This is duplicate of HBASE-3909 I'd say; also its an axiom of ours that we not put permanent data into zk which this issue would seem to imply Explore the possibility of storing the configuration files in Zookeeper --- Key: HBASE-1109 URL: https://issues.apache.org/jira/browse/HBASE-1109 Project: HBase Issue Type: New Feature Reporter: Jean-Daniel Cryans Priority: Minor Someone on IRC was saying that Google uses Chubby to store their configuration files. We should explore that solution with ZK. It has big benefits IMO. -- 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] [Resolved] (HBASE-1213) [performance] Investigate Locking Contention in the Write Path
[ https://issues.apache.org/jira/browse/HBASE-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-1213. -- Resolution: Duplicate Resolving as duplicate of the WAL batching work that has been done of late; this issue talks about batching going into WAL [performance] Investigate Locking Contention in the Write Path Key: HBASE-1213 URL: https://issues.apache.org/jira/browse/HBASE-1213 Project: HBase Issue Type: Improvement Components: performance Affects Versions: 0.19.0 Reporter: Ben Maurer Assignee: stack When doing a large number of bulk updates from different clients, I noticed that there was a high level of lock contention for stuff like locking the HLog. It seems that each thread acquires the lock for a single BatchUpdate, releases the lock then another thread owns the lock before the initial writer gets to the next update. Having the threads bounce around may lead to suboptimal performance. Should be benchmarked maybe changed to have less context switching. -- 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] [Resolved] (HBASE-2073) IllegalArgumentException causing regionserver failure
[ https://issues.apache.org/jira/browse/HBASE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2073. -- Resolution: Won't Fix Not enough detail and I don't think we've seen this lately IllegalArgumentException causing regionserver failure - Key: HBASE-2073 URL: https://issues.apache.org/jira/browse/HBASE-2073 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.20.2 Environment: Ubuntu 8.10, Java 1.6.0_10, HBase 0.20.2 Reporter: Greg Lu Priority: Minor Attachments: hbase-hadoop-regionserver-factory05.lab.mtl.log After a regionserver went down last night, I checked its logs and found the following exception: 2009-12-29 00:17:27,663 INFO org.apache.hadoop.hbase.regionserver.HLog: Roll /hbase/amsterdam_factory/.logs/factory05.lab.mtl,60020,1262042255724/hlog.dat.1262060247637, entries=1830, calcsize=22946017, filesize=22758899. New hlog /hbase/amsterdam_factory/.logs/factory05.lab.mtl,60020,1262042255724/hlog.dat.1262063847659 2009-12-29 00:34:36,210 ERROR org.apache.hadoop.hbase.regionserver.HRegionServer: java.lang.IllegalArgumentException at java.nio.Buffer.position(Buffer.java:218) at org.apache.hadoop.hbase.io.hfile.HFile$Reader$Scanner.next(HFile.java:1114) at org.apache.hadoop.hbase.regionserver.StoreFileScanner.next(StoreFileScanner.java:58) at org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:79) at org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:189) at org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:106) at org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.nextInternal(HRegion.java:1776) at org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.next(HRegion.java:1719) at org.apache.hadoop.hbase.regionserver.HRegionServer.next(HRegionServer.java:1944) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:648) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:915) 2009-12-29 00:34:36,214 INFO org.apache.hadoop.ipc.HBaseServer: IPC Server handler 0 on 60020, call next(4170645244799815171, 1) from 192.168.1.108:53401: error: java.io.IOException: java.lang.IllegalArgumentException java.io.IOException: java.lang.IllegalArgumentException at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:869) at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:859) at org.apache.hadoop.hbase.regionserver.HRegionServer.next(HRegionServer.java:1965) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:648) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:915) Caused by: java.lang.IllegalArgumentException at java.nio.Buffer.position(Buffer.java:218) at org.apache.hadoop.hbase.io.hfile.HFile$Reader$Scanner.next(HFile.java:1114) at org.apache.hadoop.hbase.regionserver.StoreFileScanner.next(StoreFileScanner.java:58) at org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:79) at org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:189) at org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:106) at org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.nextInternal(HRegion.java:1776) at org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.next(HRegion.java:1719) at org.apache.hadoop.hbase.regionserver.HRegionServer.next(HRegionServer.java:1944) ... 5 more Looks like this bug was encountered before at https://issues.apache.org/jira/browse/HBASE-1495 and spanned a few JIRAs. It's supposed to be resolved as of 0.20.0, but we're running 0.20.2 and it took down one of our regionservers. I'm also attaching more of the log. -- 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] [Resolved] (HBASE-2142) Add number of RegionServers (live/dead) to JMX metrics in HMaster
[
https://issues.apache.org/jira/browse/HBASE-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-2142.
--
Resolution: Duplicate
Marking duplicate of hbase-5325 which does better than this region asks for
giving you actual names of live and dead servers:
{code}
+ /**
+ * Get the live region servers
+ * @return Live region servers
+ */
+ public MapString, HServerLoad getRegionServers();
+
+ /**
+ * Get the dead region servers
+ * @return Dead region Servers
+ */
+ public String[] getDeadRegionServers();
{code}
Add number of RegionServers (live/dead) to JMX metrics in HMaster
-
Key: HBASE-2142
URL: https://issues.apache.org/jira/browse/HBASE-2142
Project: HBase
Issue Type: Improvement
Components: metrics
Affects Versions: 0.20.2
Reporter: Lars George
Priority: Minor
While commenting on HBASE-2117 I noticed that Hadoop's NameNode has that and
it makes sense to expose it too in HBase's HMaster metrics.
--
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] [Resolved] (HBASE-2310) Review how hbase does addresses throughout including in logs, ui and in code
[ https://issues.apache.org/jira/browse/HBASE-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2310. -- Resolution: Later Resolving as later. Its a silly general task that just won't get done. Review how hbase does addresses throughout including in logs, ui and in code Key: HBASE-2310 URL: https://issues.apache.org/jira/browse/HBASE-2310 Project: HBase Issue Type: Task Reporter: stack HBASE-2174 fixed the issue where we were doing dns lookup on each heartbeat and it adds into .META. table hostname rather than IP. This issue takes over from hbase-2174 to make it so we run through all of hbase making sure we are consistent in our use of hostname rather than IP everywhere. See HBASE-2174 for other background that'll help with this 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] [Resolved] (HBASE-2351) publish hadoop + patch artifacts under org.apache.hbase groupId
[ https://issues.apache.org/jira/browse/HBASE-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2351. -- Resolution: Won't Fix This issue no longer applicable now we run against published hadoops w/o need of patches. publish hadoop + patch artifacts under org.apache.hbase groupId Key: HBASE-2351 URL: https://issues.apache.org/jira/browse/HBASE-2351 Project: HBase Issue Type: Sub-task Components: build Reporter: Karthik K Similarly, the trunk of hbase , currently depends on a couple of patches on top of hadoop 0.20.2 release, that is being actively worked on at HBASE-2255 . Once that experience succeeds , before the 0.21.0 release, the artifacts need to be published under groupId - org.apache.hbase and artifactId - hadoop-p1-p2-p3' , say. ( where p1,p2 and p3 are patch numbers, say). The final pom.xml of hbase should be devoid of external references for better maintainability. -- 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] [Resolved] (HBASE-2675) Quick smoke tests testsuite
[ https://issues.apache.org/jira/browse/HBASE-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2675. -- Resolution: Fixed Resolving as fixed by the default run of small tests (reopen if not sufficient in your estimation B) Quick smoke tests testsuite - Key: HBASE-2675 URL: https://issues.apache.org/jira/browse/HBASE-2675 Project: HBase Issue Type: Test Reporter: Benoit Sigoure Assignee: nkeywal Priority: Minor It would be nice if there was a known subset of the tests that run fast (e.g. not more than a few seconds) and quickly help us check whether the code isn't horribly broken. This way one could run those tests at a frequent interval when iterating and only run the entire testsuite at the end, when they think they're done, since doing so is very time consuming. Someone would need to identify which tests really focus on the core functionality and add a target in the build system to just run those tests. As a bonus, it would be awesome++ if the core tests ran, say, 10x faster than they currently do. There's a lot of sleep-based synchronization in the tests and it would be nice to remove some of that where possible to make the tests run as fast as the machine can handle 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] [Resolved] (HBASE-5463) Why is my upload to mvn spread across multiple repositories?
[
https://issues.apache.org/jira/browse/HBASE-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5463.
--
Resolution: Won't Fix
Resolving. Meant to file this against infra:
https://issues.apache.org/jira/browse/INFRA-4482
Why is my upload to mvn spread across multiple repositories?
Key: HBASE-5463
URL: https://issues.apache.org/jira/browse/HBASE-5463
Project: HBase
Issue Type: Task
Reporter: stack
I'm been struggling publishing a release to repository.apache.org. Its
worked for me in the past. If you look at
https://repository.apache.org/index.html#stagingRepositories (you need to be
logged in), you will see that I somehow made twelve repositories when I did
my mvn release:perform, each artifact element to its own repo. Any idea how
that happens? (I'll attach a png that shows similar). How do I prevent it?
I have another issue where the upload to apache will fail with a 400 Bad
Request very frequently uploading one of my artifact items -- usually
maven-metadata.xml -- but then, just now, it went through fine. Pointers
appreciated on this little nugget too.
I'm using mvn 3.0.4 and 2.2.2 of the maven:release plugin. Otherwise, my
settings.xml is one that has worked for me in the past:
{code}
servers
!-- To publish a snapshot of some part of Maven --
server
idapache.snapshots.https/id
usernamestack
/username
password
/password
/server
!-- To publish a website using Maven --
!-- To stage a release of some part of Maven --
server
idapache.releases.https/id
usernamestack
/username
password
/password
/server
/servers
profiles
profile
idapache-release/id
properties
gpg.keyname00A5F21E/gpg.keyname
gpg.passphrase
/gpg.passphrase
/properties
/profile
/profiles
/settings
{code}
My pom is here:
http://svn.apache.org/viewvc/hbase/tags/0.92.0mvn/pom.xml?view=markup
Thanks for any pointers.
--
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] [Resolved] (HBASE-5470) Make DataBlockEncodingTool work correctly with no native compression codecs loaded
[ https://issues.apache.org/jira/browse/HBASE-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5470. -- Resolution: Fixed Fix Version/s: 0.94.0 Resolving as Mikhail committed the issue. Make DataBlockEncodingTool work correctly with no native compression codecs loaded -- Key: HBASE-5470 URL: https://issues.apache.org/jira/browse/HBASE-5470 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Priority: Minor Fix For: 0.94.0 Attachments: D1917.1.patch DataBlockEncodingTool was fixed as part of porting data block encoding (HBASE-4218) to 89-fb (https://reviews.facebook.net/rHBASEEIGHTNINEFBBRANCH1245291, https://reviews.facebook.net/D1659). The bug appeared when using GZ as baseline compression codec but not loading native Hadoop libraries, in which case the compressor instance would be null. The purpose of this JIRA is to bring the trunk version of DataBlockEncodingTool to parity with the 89-fb version, and further improvements to the tool will be made separately. -- 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] [Resolved] (HBASE-5423) Regionserver may block forever on waitOnAllRegionsToClose when aborting
[ https://issues.apache.org/jira/browse/HBASE-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5423. -- Resolution: Fixed Fix Version/s: 0.94.0 Hadoop Flags: Reviewed Committed to TRUNK. Thanks for the patch Chunhui. Regionserver may block forever on waitOnAllRegionsToClose when aborting --- Key: HBASE-5423 URL: https://issues.apache.org/jira/browse/HBASE-5423 Project: HBase Issue Type: Bug Components: regionserver Reporter: chunhui shen Assignee: chunhui shen Fix For: 0.94.0 Attachments: hbase-5423.patch, hbase-5423v2.patch If closeRegion throws any exception (It would be caused by FS ) when RS is aborting, RS will block forever on waitOnAllRegionsToClose(). -- 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] [Resolved] (HBASE-5432) Hunk missed applying 'hbase-5255 Use singletons for OperationStatus to save memory'
[ https://issues.apache.org/jira/browse/HBASE-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5432. -- Resolution: Fixed Assignee: stack Applied to 0.92. Doesn't make sense for trunk (its different there) Hunk missed applying 'hbase-5255 Use singletons for OperationStatus to save memory' --- Key: HBASE-5432 URL: https://issues.apache.org/jira/browse/HBASE-5432 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.92.1 Attachments: 5432.txt -- 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] [Resolved] (HBASE-5427) Upgrade our zk to 3.4.3
[ https://issues.apache.org/jira/browse/HBASE-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5427. -- Resolution: Fixed Assignee: stack Committed 0.92 branch and trunk. Upgrade our zk to 3.4.3 --- Key: HBASE-5427 URL: https://issues.apache.org/jira/browse/HBASE-5427 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.94.0, 0.92.1 Attachments: 5427.txt -- 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] [Resolved] (HBASE-5195) [Coprocessors] preGet hook does not allow overriding or wrapping filter on incoming Get
[ https://issues.apache.org/jira/browse/HBASE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5195. -- Resolution: Fixed Committed to 0.92. Already in trunk. [Coprocessors] preGet hook does not allow overriding or wrapping filter on incoming Get --- Key: HBASE-5195 URL: https://issues.apache.org/jira/browse/HBASE-5195 Project: HBase Issue Type: Bug Affects Versions: 0.94.0, 0.92.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 0.94.0, 0.92.1 Attachments: HBASE-5195.patch Without the ability to wrap the internal Scan on the Get, we can't override (or protect, in the case of access control) Gets as we can Scans. The result is inconsistent behavior. -- 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] [Resolved] (HBASE-2425) Crossport HADOOP-1849 rpc fix
[ https://issues.apache.org/jira/browse/HBASE-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-2425. -- Resolution: Fixed Hadoop Flags: Reviewed Bulk of this looks to have been committed. Resolving. Crossport HADOOP-1849 rpc fix - Key: HBASE-2425 URL: https://issues.apache.org/jira/browse/HBASE-2425 Project: HBase Issue Type: Task Reporter: stack Labels: moved_from_0_20_5 Suggested over in HBASE-2360. -- 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] [Resolved] (HBASE-2628) HTable#getRowOrBefore stackoverflows
[
https://issues.apache.org/jira/browse/HBASE-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-2628.
--
Resolution: Invalid
Haven't seen this one in years. Resolving as no longer valid.
HTable#getRowOrBefore stackoverflows
Key: HBASE-2628
URL: https://issues.apache.org/jira/browse/HBASE-2628
Project: HBase
Issue Type: Bug
Reporter: stack
getRowOrBefore, if I point it a table other than .META., does the below
{code}
java.io.IOException: java.io.IOException: java.lang.StackOverflowError
at
org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:887)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:877)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.getClosestRowBefore(HRegionServer.java:1734)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:657)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:915)
Caused by: java.lang.StackOverflowError
at
org.apache.hadoop.hbase.KeyValue$KeyComparator.compare(KeyValue.java:1776)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:148)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
at
org.apache.hadoop.hbase.io.HalfHFileReader$1.seekBefore(HalfHFileReader.java:150)
{code}
Here is some code to do it:
{code}
hbase(main):018:0 t = HTable.new(@configuration, TestTable)
hbase(main):018:0 r = t.getRowOrBefore(Bytes.toString(''),
Bytes.toString('info'))
... spew
{code}
--
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] [Resolved] (HBASE-5307) Unable to gracefully decommission a node because of script error
[
https://issues.apache.org/jira/browse/HBASE-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5307.
--
Resolution: Fixed
Fix Version/s: 0.92.1
Thanks for the fix YiFeng. I committed to 0.92 and trunk.
Unable to gracefully decommission a node because of script error
Key: HBASE-5307
URL: https://issues.apache.org/jira/browse/HBASE-5307
Project: HBase
Issue Type: Bug
Components: scripts
Affects Versions: 0.92.0
Reporter: YiFeng Jiang
Fix For: 0.92.1
Attachments: region_mover_HBASE-5307-0.92.patch
Unable to gracefully decommission a node because NameError occurred in
region_mover.rb
{code}
$ bin/graceful_stop.sh ip-10-160-226-84.us-west-1.compute.internal
...
NameError: no constructorfor arguments (org.jruby.RubyString) on
Java::OrgApacheHadoopHbase::HServerAddress
available overloads:
(org.apache.hadoop.hbase.HServerAddress)
(java.net.InetSocketAddress)
getRegions at /usr/local/hbase/current/bin/region_mover.rb:254
unloadRegions at /usr/local/hbase/current/bin/region_mover.rb:314
(root) at /usr/local/hbase/current/bin/region_mover.rb:430
Unloaded ip-10-160-226-84.us-west-1.compute.internal region(s)
ip-10-160-226-84.us-west-1.compute.internal: stopping regionserver..
{code}
The reason is the region_mover.rb calls wrong HBase APIs to try to establish
a connection to the region 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] [Resolved] (HBASE-5171) Potential NullPointerException while obtaining row lock
[ https://issues.apache.org/jira/browse/HBASE-5171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5171. -- Resolution: Duplicate This patch was opened first but will mark as duplicate of hbase-5249 because thats where the action is. Potential NullPointerException while obtaining row lock Key: HBASE-5171 URL: https://issues.apache.org/jira/browse/HBASE-5171 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.90.5 Reporter: Yves Langisch We have a table which is concurrently accessed (read/write) from many threads and we make use of row locks. Under heavy load we regularly get NPE while obtaining row locks. An example stack trace looks as follows: java.lang.NullPointerException at org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:986) at org.apache.hadoop.hbase.regionserver.HRegionServer.lockRow(HRegionServer.java:2008) at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570) at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039) Caused by: java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881) at org.apache.hadoop.hbase.regionserver.HRegionServer.addRowLock(HRegionServer.java:2018) at org.apache.hadoop.hbase.regionserver.HRegionServer.lockRow(HRegionServer.java:2004) ... 5 more After checking the source code I've noticed that the value which is going to be put into the HashMap can be null in the case where the waitForLock flag is true or the rowLockWaitDuration is expired (HRegion#internalObtainRowLock, line 2111ff). The latter I think happens in our case as we have heavy load hitting the server. IMHO this case should be handled somehow and must not lead to a NPE. - Yves -- 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] [Resolved] (HBASE-5264) Add 0.92.0 upgrade guide
[ https://issues.apache.org/jira/browse/HBASE-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5264. -- Resolution: Fixed Fix Version/s: 0.94.0 Committed TRUNK Add 0.92.0 upgrade guide Key: HBASE-5264 URL: https://issues.apache.org/jira/browse/HBASE-5264 Project: HBase Issue Type: Task Reporter: stack Fix For: 0.94.0 Attachments: 5264.txt Add an upgrade guide for going from 0.90 to 0.92. -- 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] [Resolved] (HBASE-5193) Use TBoundedThreadPoolServer in HRegionThriftServer
[ https://issues.apache.org/jira/browse/HBASE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5193. -- Resolution: Fixed Committed to TRUNK. Thanks for patch Scott (Thanks for pointing out needed class in trunk Zhihong) Use TBoundedThreadPoolServer in HRegionThriftServer --- Key: HBASE-5193 URL: https://issues.apache.org/jira/browse/HBASE-5193 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Scott Chen Assignee: Scott Chen Priority: Minor Fix For: 0.94.0 Attachments: HBASE-5193.txt TBoundedThreadPoolServer provides more control than TThreadPoolServer. We should also use it for HRegionThriftServer. -- 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] [Resolved] (HBASE-5173) Commit hbase-4480 findHangingTest.sh script under dev-support
[ https://issues.apache.org/jira/browse/HBASE-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5173. -- Resolution: Fixed Fix Version/s: 0.94.0 Committed to trunk. Commit hbase-4480 findHangingTest.sh script under dev-support - Key: HBASE-5173 URL: https://issues.apache.org/jira/browse/HBASE-5173 Project: HBase Issue Type: Task Reporter: stack Fix For: 0.94.0 Attachments: 5173.txt See hbase-4480 for the script from Ted -- 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] [Resolved] (HBASE-5091) [replication] Update replication doc to reflect current znode structure
[
https://issues.apache.org/jira/browse/HBASE-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5091.
--
Resolution: Fixed
Fix Version/s: 0.94.0
Hadoop Flags: Reviewed
Committed to trunk. Thanks for patch Chris.
[replication] Update replication doc to reflect current znode structure
---
Key: HBASE-5091
URL: https://issues.apache.org/jira/browse/HBASE-5091
Project: HBase
Issue Type: Bug
Components: documentation, replication
Reporter: Chris Trezzo
Assignee: Chris Trezzo
Priority: Trivial
Fix For: 0.94.0
Attachments: HBASE-5091.patch
A small nit: The zookeeper node structure in the region server fail over
section of the replication document is slightly different than the actual
structure.
The doc shows this:
{noformat}
/hbase/replication/rs/
1.1.1.1,60020,123456780/
peers/
2/
1.1.1.1,60020.1234 (Contains a position)
1.1.1.1,60020.1265
{noformat}
When in actuality it should be this:
{noformat}
/hbase/replication/rs/
1.1.1.1,60020,123456780/
2/
1.1.1.1,60020.1234 (Contains a position)
1.1.1.1,60020.1265
{noformat}
Not a big deal, but it gets confusing when you are going through the code and
using the doc as a reference.
--
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] [Resolved] (HBASE-5087) Up the 0.92RC zk to 3.4.1RC0
[ https://issues.apache.org/jira/browse/HBASE-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5087. -- Resolution: Fixed Assignee: stack Hadoop Flags: Incompatible change Committed as incompatible change to 0.92 and trunk (though 3.4.1 runs against 3.3.x... marking it so to give people pause) Up the 0.92RC zk to 3.4.1RC0 Key: HBASE-5087 URL: https://issues.apache.org/jira/browse/HBASE-5087 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.92.0 Attachments: 5087.txt ZK just found bad bug in 3.4.1 zookeeper-1333. They put up a fix and new rc, 3.4.1 (Andrew, you saw Todds query asking if it'd possible to hold to zk 3.3.4 and just have 3.4.1 for secure installs?) -- 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] [Resolved] (HBASE-5066) Upgrade to zk 3.4.1
[ https://issues.apache.org/jira/browse/HBASE-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5066. -- Resolution: Fixed Fix Version/s: 0.92.0 Assignee: stack Hadoop Flags: Reviewed Committed to 0.92 and trunk. Upgrade to zk 3.4.1 --- Key: HBASE-5066 URL: https://issues.apache.org/jira/browse/HBASE-5066 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.92.0 Attachments: 5066.txt Currently we are shipping 0.92 with 3.4.1rc2 which is what became the release but change the pom to get the release; it looks better. -- 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] [Resolved] (HBASE-4935) hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop
[ https://issues.apache.org/jira/browse/HBASE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4935. -- Resolution: Fixed Fix Version/s: 0.92.1 Assignee: Mikhail Bautin Hadoop Flags: Reviewed Committed to 0.92 branch. Marking fixed in 0.92.1 for now in case current RC passes. Assigning Mikhail since it his work. hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop --- Key: HBASE-4935 URL: https://issues.apache.org/jira/browse/HBASE-4935 Project: HBase Issue Type: Bug Reporter: stack Assignee: Mikhail Bautin Fix For: 0.92.1 Attachments: 4935.txt See this Mikhail thread up on the list: http://search-hadoop.com/m/WMUZR24EAJ1/%2522SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures%2522subj=Re+SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures Dig into 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] [Resolved] (HBASE-5029) TestDistributedLogSplitting fails on occasion
[ https://issues.apache.org/jira/browse/HBASE-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5029. -- Resolution: Fixed Fix Version/s: 0.92.0 Hadoop Flags: Reviewed Committed 0.92 branch and trunk. Thanks for the patch Prakash. TestDistributedLogSplitting fails on occasion - Key: HBASE-5029 URL: https://issues.apache.org/jira/browse/HBASE-5029 Project: HBase Issue Type: Bug Reporter: stack Assignee: Prakash Khemani Fix For: 0.92.0 Attachments: 0001-HBASE-5029-jira-TestDistributedLogSplitting-fails-on.patch, HBASE-5029.D891.1.patch, HBASE-5029.D891.2.patch This is how it usually fails: https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testWorkerAbort/ Assigning mighty Prakash since he offered to take a looksee. -- 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] [Resolved] (HBASE-5020) MetaReader#fullScan doesn't stop scanning when vistor returns false in 0.90 version
[
https://issues.apache.org/jira/browse/HBASE-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-5020.
--
Resolution: Fixed
Fix Version/s: 0.90.6
Assignee: chunhui shen
Hadoop Flags: Reviewed
Committed to 0.90 branch. Thanks for patch Chunhui.
MetaReader#fullScan doesn't stop scanning when vistor returns false in 0.90
version
Key: HBASE-5020
URL: https://issues.apache.org/jira/browse/HBASE-5020
Project: HBase
Issue Type: Bug
Reporter: chunhui shen
Assignee: chunhui shen
Fix For: 0.90.6
Attachments: hbase-5020.patch
In current 0.90 code,
{code}
public static void fullScan(CatalogTracker catalogTracker,
final Visitor visitor, final byte [] startrow)
throws IOException {
HRegionInterface metaServer =
catalogTracker.waitForMetaServerConnectionDefault();
Scan scan = new Scan();
if (startrow != null) scan.setStartRow(startrow);
scan.addFamily(HConstants.CATALOG_FAMILY);
long scannerid = metaServer.openScanner(
HRegionInfo.FIRST_META_REGIONINFO.getRegionName(), scan);
try {
Result data;
while((data = metaServer.next(scannerid)) != null) {
if (!data.isEmpty()) visitor.visit(data);
}
} finally {
metaServer.close(scannerid);
}
return;
}
{code}
If visitor.visit(data) return false, the scan will not stop;
However, it is not the same as the description of Visitor
{code}
public interface Visitor {
/**
* Visit the catalog table row.
* @param r A row from catalog table
* @return True if we are to proceed scanning the table, else false if
* we are to stop now.
*/
public boolean visit(final Result r) throws IOException;
}
{code}
I think it is a miss, and trunk doesn't exist this hole.
--
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] [Resolved] (HBASE-5008) The clusters can't provide services because Region can't flush.
[ https://issues.apache.org/jira/browse/HBASE-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5008. -- Resolution: Fixed Fix Version/s: 0.92.0 Assignee: gaojinchao Hadoop Flags: Reviewed Thanks for the patch Jinchao. Applied trunk and two branches. The clusters can't provide services because Region can't flush. Key: HBASE-5008 URL: https://issues.apache.org/jira/browse/HBASE-5008 Project: HBase Issue Type: Bug Components: regionserver Reporter: gaojinchao Assignee: gaojinchao Priority: Blocker Fix For: 0.92.0, 0.90.6 Attachments: HBASE-5008_Branch90.patch Hbase version 0.90.4 + patches My analysis is as follows: //Started splitting region b24d8ccb852ff742f2a27d01b7f5853e and closed region. 2011-12-10 17:32:48,653 INFO org.apache.hadoop.hbase.regionserver.SplitTransaction: Starting split of region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e. 2011-12-10 17:32:49,759 DEBUG org.apache.hadoop.hbase.regionserver.HRegion: Closing Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: disabling compactions flushes 2011-12-10 17:32:49,759 INFO org.apache.hadoop.hbase.regionserver.HRegion: Running close preflush of Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e. //Processed a flush request and skipped , But flushRequested had set to true 2011-12-10 17:33:06,963 DEBUG org.apache.hadoop.hbase.regionserver.HRegion: Started memstore flush for Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e., current region memstore size 12.6m 2011-12-10 17:33:17,277 DEBUG org.apache.hadoop.hbase.regionserver.HRegion: Skipping flush on Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e. because closing //split region b24d8ccb852ff742f2a27d01b7f5853 failed and rolled back, flushRequested flag was true, So all handle was blocked 2011-12-10 17:34:01,293 INFO org.apache.hadoop.hbase.regionserver.SplitTransaction: Cleaned up old failed split transaction detritus: hdfs://193.195.18.121:9000/hbase/Htable_UFDR_004/b24d8ccb852ff742f2a27d01b7f5853e/splits 2011-12-10 17:34:01,294 INFO org.apache.hadoop.hbase.regionserver.HRegion: Onlined Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.; next sequenceid=15494173 2011-12-10 17:34:01,295 INFO org.apache.hadoop.hbase.regionserver.CompactSplitThread: Successful rollback of failed split of Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e. 2011-12-10 17:43:10,147 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 19 on 20020' on region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: memstore size 384.0m is = than blocking 384.0m size // All handles had been blocked. The clusters could not provide services 2011-12-10 17:34:01,295 INFO org.apache.hadoop.hbase.regionserver.CompactSplitThread: Successful rollback of failed split of Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e. 2011-12-10 17:43:10,147 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 19 on 20020' on region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: memstore size 384.0m is = than blocking 384.0m size 2011-12-10 17:43:10,192 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 34 on 20020' on region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: memstore size 384.0m is = than blocking 384.0m size 2011-12-10 17:43:10,193 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 51 on 20020' on region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: memstore size 384.0m is = than blocking 384.0m size 2011-12-10 17:43:10,196 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 85 on 20020' on region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: memstore size 384.0m is = than blocking 384.0m size 2011-12-10 17:43:10,199 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 88 on 20020' on region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: memstore size 384.0m is = than blocking 384.0m size 2011-12-10 17:43:10,202 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 44 on 20020' on region Htable_UFDR_004,09781,1323508582833.b24d8ccb852ff742f2a27d01b7f5853e.: memstore size 384.0m is = than blocking 384.0m size 2011-12-10 17:43:11,663 INFO
[jira] [Resolved] (HBASE-4881) Unhealthy region is on service caused by rollback of region splitting
[
https://issues.apache.org/jira/browse/HBASE-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4881.
--
Resolution: Fixed
Fix Version/s: 0.92.0
Assignee: chunhui shen
Hadoop Flags: Reviewed
Committed trunk and 0.92 branch. Thank you for the patch Chunhui.
Unhealthy region is on service caused by rollback of region splitting
-
Key: HBASE-4881
URL: https://issues.apache.org/jira/browse/HBASE-4881
Project: HBase
Issue Type: Bug
Reporter: chunhui shen
Assignee: chunhui shen
Fix For: 0.92.0
Attachments: 4881-v2.txt, hbase-4881.patch
If region splitting is failed in the state of
JournalEntry.CLOSED_PARENT_REGION
It will be rollback as the following steps:
{code}
1.case CLOSED_PARENT_REGION:
this.parent.initialize();
break;
2.case CREATE_SPLIT_DIR:
this.parent.writestate.writesEnabled = true;
cleanupSplitDir(fs, this.splitdir);
break;
3.case SET_SPLITTING_IN_ZK:
if (server != null server.getZooKeeper() != null) {
cleanZK(server, this.parent.getRegionInfo());
}
break;
{code}
If this.parent.initialize() throws IOException in step 1,
If check filesystem is ok. it will do nothing.
However, the parent region is on service now.
--
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] [Resolved] (HBASE-4922) [packaging] Assembly tars up hbase in a subdir; i.e. after untar hbase-0.92.0 has a subdir named 0.92.0
[ https://issues.apache.org/jira/browse/HBASE-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4922. -- Resolution: Fixed I commmitted v2. Haunt me if I got it wrong again Roman. Thanks boss. Applied branch and trunk. [packaging] Assembly tars up hbase in a subdir; i.e. after untar hbase-0.92.0 has a subdir named 0.92.0 --- Key: HBASE-4922 URL: https://issues.apache.org/jira/browse/HBASE-4922 Project: HBase Issue Type: Bug Reporter: stack Assignee: Roman Shaposhnik Priority: Blocker Fix For: 0.92.0 Attachments: 4922-v2.txt, HBASE-4922.patch.txt Reported by Roman. -- 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] [Resolved] (HBASE-5011) Move test-util.sh from src/test/bin to dev-tools
[ https://issues.apache.org/jira/browse/HBASE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-5011. -- Resolution: Fixed Fix Version/s: 0.94.0 Applied to trunk. Move test-util.sh from src/test/bin to dev-tools Key: HBASE-5011 URL: https://issues.apache.org/jira/browse/HBASE-5011 Project: HBase Issue Type: Task Reporter: stack Fix For: 0.94.0 Attachments: 5011.txt -- 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] [Resolved] (HBASE-4997) SplitLogManager can have a race on batch.installed
[ https://issues.apache.org/jira/browse/HBASE-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4997. -- Resolution: Fixed Fix Version/s: 0.92.0 Hadoop Flags: Reviewed Applied trunk and branch. Thanks for patch Prakash. SplitLogManager can have a race on batch.installed -- Key: HBASE-4997 URL: https://issues.apache.org/jira/browse/HBASE-4997 Project: HBase Issue Type: Bug Reporter: Prakash Khemani Assignee: Prakash Khemani Fix For: 0.92.0 Attachments: 0001-HBASE-4997-jira-SplitLogManager-can-have-a-race-on-b.patch This is a continuation of HBASE-4987. Will put up a patch shortly. -- 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] [Resolved] (HBASE-4982) graceful_stop.sh does not pass on the --config its passed to its internal invocations of other hbase scripts
[ https://issues.apache.org/jira/browse/HBASE-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4982. -- Resolution: Fixed Fix Version/s: 0.90.5 Assignee: stack Committed to TRUNK and the two branches. graceful_stop.sh does not pass on the --config its passed to its internal invocations of other hbase scripts Key: HBASE-4982 URL: https://issues.apache.org/jira/browse/HBASE-4982 Project: HBase Issue Type: Bug Components: scripts Reporter: stack Assignee: stack Fix For: 0.90.5 Attachments: 4982.txt Means, unless conf is in default location, we mess up asking zk for state (we'll be pointed at wrong ensemble), etc. -- 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] [Resolved] (HBASE-4969) tautology in HRegionInfo.readFields
[
https://issues.apache.org/jira/browse/HBASE-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4969.
--
Resolution: Fixed
Fix Version/s: 0.92.0
Hadoop Flags: Reviewed
Committed branch and trunk. Thanks for patch Prakash.
tautology in HRegionInfo.readFields
---
Key: HBASE-4969
URL: https://issues.apache.org/jira/browse/HBASE-4969
Project: HBase
Issue Type: Bug
Reporter: Prakash Khemani
Assignee: Prakash Khemani
Fix For: 0.92.0
Attachments: HBASE-4969.D669.1.patch
In HRegionInfo.readFields() the following looks wrong to me
} else if (getVersion() == VERSION) {
it is always true.
Should it have been
} else if (getVersion() == version) {
version is a local variable where the deserialized-version is stored.
(I am struggling with another issue where after applying some patches -
including HBASE-4388 Second start after migration from 90 to trunk crashes
my version of hbase-92 HRegionInfo.readFields() tries to find HTD in
HRegionInfo and fails)
--
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] [Resolved] (HBASE-4976) Add compaction/flush queue size metrics mistakenly removed by HFile v2
[ https://issues.apache.org/jira/browse/HBASE-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4976. -- Resolution: Fixed Hadoop Flags: Reviewed Committed branch and trunk. Thanks for the patch Mikhail. Add compaction/flush queue size metrics mistakenly removed by HFile v2 -- Key: HBASE-4976 URL: https://issues.apache.org/jira/browse/HBASE-4976 Project: HBase Issue Type: Bug Reporter: Mikhail Bautin Assignee: Mikhail Bautin Priority: Blocker Fix For: 0.92.0 Attachments: D645.1.patch Upping priority, and putting it against 0.92 since J-D fingered it as blocker. Which metrics in particular are missing? Hard to 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] [Resolved] (HBASE-4712) Document rules for writing tests
[ https://issues.apache.org/jira/browse/HBASE-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4712. -- Resolution: Fixed Fix Version/s: 0.94.0 Hadoop Flags: Reviewed Committed to trunk. Thanks for the doc. N. Document rules for writing tests Key: HBASE-4712 URL: https://issues.apache.org/jira/browse/HBASE-4712 Project: HBase Issue Type: Task Components: test Affects Versions: 0.92.0 Reporter: nkeywal Assignee: nkeywal Priority: Minor Fix For: 0.94.0 Attachments: 4712.txt We saw that some tests could be improved. Documenting the general rules could help. Proposal: HBase tests are divided in three categories: small, medium and large, with corresponding JUnit categories: SmallTest, MediumTest, LargeTest Small tests are executed in parallel in a shared JVM. They must last less than 15 seconds. They must NOT use a cluster. Medium tests are executed in separate JVM. They must last less than 50 seconds. They can use a cluster. They must not fail occasionally. Small and medium tests must not need more than 30 minutes to run altogether. Small and medium tests should be executed by the developers before submitting a patch. Large tests are everything else. They are typically integration tests, non-regression tests for specific bugs, timeout tests, performance tests. Tests rules hints are: - As most as possible, tests should be written as small tests. - All tests should be written to support parallel execution on the same machine, hence should not use shared resources as fixed ports or fixed file names. - All tests should be written to be as fast as possible. - Tests should not overlog. More than 100 lines/second makes the logs complex to read and use i/o that are hence not available for the other tests. - Tests can be written with HBaseTestingUtility . This class offers helper function to create a temp directory and do the cleanup, or to start a cluster. - Sleeps: - Tests should not do a 'Thread.sleep' without testing an ending condition. This allows understanding what the test is waiting for. Moreover, the test will work whatever the machine performances. - Sleep should be minimal to be as fast as possible. Waiting for a variable should be done in a 40ms sleep loop. Waiting for a socket operation should be done in a 200 ms sleep loop. - Tests using cluster: - Tests using a HRegion do not have to start a cluster: A region can use the local file system. - Start/stopping a cluster cost around 10 seconds. They should not be started per test method but per class. - Started cluster must be shutdown using HBaseTestingUtility#shutdownMiniCluster, which cleans the directories. - As most as possible, tests should use the default settings for the cluster. When they don't, they should document it. This will allow to share the cluster 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] [Resolved] (HBASE-4937) Error in Quick Start Shell Exercises
[
https://issues.apache.org/jira/browse/HBASE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4937.
--
Resolution: Fixed
Fix Version/s: 0.94.0
Assignee: stack
Committed to trunk. Thanks for the doc bug report Ryan.
Error in Quick Start Shell Exercises
Key: HBASE-4937
URL: https://issues.apache.org/jira/browse/HBASE-4937
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Ryan Berdeen
Assignee: stack
Fix For: 0.94.0
Attachments: 4937.txt
The shell exercises in the Quick Start
(http://hbase.apache.org/book/quickstart.html) starts
{code}
hbase(main):003:0 create 'test', 'cf'
0 row(s) in 1.2200 seconds
hbase(main):003:0 list 'table'
test
1 row(s) in 0.0550 seconds
{code}
It looks like the second command is wrong. Running it, the actual output is
{code}
hbase(main):001:0 create 'test', 'cf'
0 row(s) in 0.3630 seconds
hbase(main):002:0 list 'table'
TABLE
0 row(s) in 0.0100 seconds
{code}
The argument to list should be 'test', not 'table', and the output in the
example is missing the {{TABLE}} line.
--
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] [Resolved] (HBASE-4968) Add to troubleshooting workaround for direct buffer oome's.
[ https://issues.apache.org/jira/browse/HBASE-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4968. -- Resolution: Fixed Fix Version/s: 0.94.0 Assignee: stack Committed to TRUNK. Add to troubleshooting workaround for direct buffer oome's. --- Key: HBASE-4968 URL: https://issues.apache.org/jira/browse/HBASE-4968 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.94.0 Attachments: client.oome.txt Put into book workaround arrived at up on list discussing client oome. -- 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] [Resolved] (HBASE-4964) Add builddate, make less sections in toc, and add header and footer customizations
[ https://issues.apache.org/jira/browse/HBASE-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4964. -- Resolution: Fixed Fix Version/s: 0.94.0 Committed to trunk Add builddate, make less sections in toc, and add header and footer customizations -- Key: HBASE-4964 URL: https://issues.apache.org/jira/browse/HBASE-4964 Project: HBase Issue Type: Improvement Reporter: stack Fix For: 0.94.0 Attachments: 4964.txt The customizations are for adding facebook comments. I tried it but not working for me immediately; need some xsl jujitsu so I can get name of current page into the current footer. Added a buildDate define in iso-8601 to the pom used in 'reference guide' -- 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] [Resolved] (HBASE-4904) Fix overcommit to 0.90 (hbase-4352+hbase-4900)
[ https://issues.apache.org/jira/browse/HBASE-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4904. -- Resolution: Fixed Fix Version/s: 0.90.5 Assignee: stack Fix overcommit to 0.90 (hbase-4352+hbase-4900) -- Key: HBASE-4904 URL: https://issues.apache.org/jira/browse/HBASE-4904 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.90.5 Last night I made two commits. The first was an overcommit (my tree was dirty). This issue is about fixup. -- 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] [Resolved] (HBASE-4894) Remove sbin from tgz made building 0.92.
[ https://issues.apache.org/jira/browse/HBASE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4894. -- Resolution: Fixed Fix Version/s: 0.92.0 Assignee: stack Applied to branch 0.92 Remove sbin from tgz made building 0.92. Key: HBASE-4894 URL: https://issues.apache.org/jira/browse/HBASE-4894 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.92.0 Attachments: 4894.txt When I undo the tgz, I see we have an sbin dir with update-hbase-env.sh in it. Lets do this messing in 0.94. Its incomplete story in 0.92. Removing sbin dir from tgz. -- 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] [Resolved] (HBASE-4352) Apply version of hbase-4015 to branch
[ https://issues.apache.org/jira/browse/HBASE-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4352. -- Resolution: Fixed Hadoop Flags: Reviewed Applied to 0.90 branch. Need to test that it doesn't break rolling restarts. Committing so can put up a 0.90.5 RC. Apply version of hbase-4015 to branch - Key: HBASE-4352 URL: https://issues.apache.org/jira/browse/HBASE-4352 Project: HBase Issue Type: Bug Reporter: stack Assignee: ramkrishna.s.vasudevan Priority: Blocker Fix For: 0.90.5 Attachments: HBASE-4352_0.90.patch, HBASE-4352_0.90_1.patch Consider adding a version of hbase-4015 to 0.90. It changes HRegionInterface so would need move change to end of the Interface and then test that it doesn't break rolling restart. -- 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
