[jira] [Created] (HBASE-5842) Passing shell commands as an argument
Passing shell commands as an argument
-
Key: HBASE-5842
URL: https://issues.apache.org/jira/browse/HBASE-5842
Project: HBase
Issue Type: Improvement
Components: shell
Affects Versions: 0.94.0
Reporter: Harsh J
Priority: Minor
Many times we've required scans of .META. to analyze issues with the cluster we
work on, and to have the result in a file we can pass around we usually end up
doing something like:
{{echo scan '.META.'| hbase shell meta-scan.txt}}
This can rather be simplified as something like the following instead, with
support for a commands reading argument:
{{hbase shell -c scan '.META.'}}
[Note though: File reading is possible already, i.e. {{hbase shell file.hs}},
but then thats two steps and we usually don't keep a file around for just a
meta table scan.]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5281) Should a failure in creating an unassigned node abort the master?
Should a failure in creating an unassigned node abort the master?
-
Key: HBASE-5281
URL: https://issues.apache.org/jira/browse/HBASE-5281
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.90.5
Reporter: Harsh J
Fix For: 0.94.0, 0.92.1
In {{AssignmentManager}}'s {{CreateUnassignedAsyncCallback}}, we have the
following condition:
{code}
if (rc != 0) {
// Thisis resultcode. If non-zero, need to resubmit.
LOG.warn(rc != 0 for + path + -- retryable connectionloss -- +
FIX see http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A2;);
this.zkw.abort(Connectionloss writing unassigned at + path +
, rc= + rc, null);
return;
}
{code}
While a similar structure inside {{ExistsUnassignedAsyncCallback}} (which the
above is linked to), does not have such a force abort.
Do we really require the abort statement here, or can we make do without?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5167) We shouldn't be injecting 'Killing [daemon]' into logs, when we aren't doing that.
We shouldn't be injecting 'Killing [daemon]' into logs, when we aren't doing that. -- Key: HBASE-5167 URL: https://issues.apache.org/jira/browse/HBASE-5167 Project: HBase Issue Type: Improvement Components: scripts Affects Versions: 0.92.0 Reporter: Harsh J Priority: Trivial HBASE-4209 changed the behavior of the scripts such that we do not kill the daemons away anymore. We should have also changed the message shown in the logs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5143) Fix config typo in pluggable load balancer factory
Fix config typo in pluggable load balancer factory -- Key: HBASE-5143 URL: https://issues.apache.org/jira/browse/HBASE-5143 Project: HBase Issue Type: Sub-task Components: master Reporter: Harsh J Priority: Critical HBASE-4240 made LoadBalancer pluggable. Configuration it loads seems to be wrongly named and carries a typo: hbase.maser.loadBalancer.class Could rather be hbase.master.loadbalancer.class Luckily 0.92 is not out yet and we should fix it asap, before folks start using it. Attaching patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5144) Add a test for LoadBalancerFactory
Add a test for LoadBalancerFactory -- Key: HBASE-5144 URL: https://issues.apache.org/jira/browse/HBASE-5144 Project: HBase Issue Type: Sub-task Reporter: Harsh J Priority: Minor We should add a simple class loading test surrounding LoadBalancerFactory to prevent regressions. Perhaps a simple test that loads and uses a custom load balancer should suffice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5145) HMasterCommandLine's -minServers seems to be useless.
HMasterCommandLine's -minServers seems to be useless. - Key: HBASE-5145 URL: https://issues.apache.org/jira/browse/HBASE-5145 Project: HBase Issue Type: Sub-task Components: master Affects Versions: 0.94.0 Reporter: Harsh J HMasterCommandLine gets a number via -minServers opt. and sets it to a config param hbase.regions.server.count.min. This config is not used anywhere else. Perhaps it wants to use hbase.master.wait.on.regionservers.mintostart instead? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5135) TableMapReduceUtil should be using the DistributedCache API, not the 'tmpjars' config directly.
TableMapReduceUtil should be using the DistributedCache API, not the 'tmpjars' config directly. --- Key: HBASE-5135 URL: https://issues.apache.org/jira/browse/HBASE-5135 Project: HBase Issue Type: Improvement Reporter: Harsh J The jar adding methods of TableMapReduceUtil seem to be bypassing the DistributedCache API by plugging in the jar lists themselves to the actual property. This is not a good practice and must be avoided if possible. _Observed during HBASE-3274_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5098) Update hbase-default.xml to reflect the state of HConstants once its the center.
Update hbase-default.xml to reflect the state of HConstants once its the center. Key: HBASE-5098 URL: https://issues.apache.org/jira/browse/HBASE-5098 Project: HBase Issue Type: Sub-task Reporter: Harsh J Priority: Trivial Once the parent task is done, we should be easily able to add to and update hbase-default.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-5071) HFile has a possible cast issue.
HFile has a possible cast issue.
Key: HBASE-5071
URL: https://issues.apache.org/jira/browse/HBASE-5071
Project: HBase
Issue Type: Bug
Components: io
Affects Versions: 0.90.0
Reporter: Harsh J
HBASE-3040 introduced this line originally in HFile.Reader#loadFileInfo(...):
{code}
int allIndexSize = (int)(this.fileSize - this.trailer.dataIndexOffset -
FixedFileTrailer.trailerSize());
{code}
Which on trunk today, for HFile v1 is:
{code}
int sizeToLoadOnOpen = (int) (fileSize - trailer.getLoadOnOpenDataOffset() -
trailer.getTrailerSize());
{code}
This computed (and casted) integer is then used to build an array of the same
size. But if fileSize is very large ( Integer.MAX_VALUE), then there's an
easy chance this can go negative at some point and spew out exceptions such as:
{code}
java.lang.NegativeArraySizeException
at org.apache.hadoop.hbase.io.hfile.HFile$Reader.readAllIndex(HFile.java:805)
at org.apache.hadoop.hbase.io.hfile.HFile$Reader.loadFileInfo(HFile.java:832)
at
org.apache.hadoop.hbase.regionserver.StoreFile$Reader.loadFileInfo(StoreFile.java:1003)
at org.apache.hadoop.hbase.regionserver.StoreFile.open(StoreFile.java:382)
at
org.apache.hadoop.hbase.regionserver.StoreFile.createReader(StoreFile.java:438)
at org.apache.hadoop.hbase.regionserver.Store.loadStoreFiles(Store.java:267)
at org.apache.hadoop.hbase.regionserver.Store.init(Store.java:209)
at
org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:2088)
at org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:358)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:2661)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:2647)
{code}
Did we accidentally limit single region sizes this way?
(Unsure about HFile v2's structure so far, so do not know if v2 has the same
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] [Created] (HBASE-4705) HBase won't initialize if /hbase is not present
HBase won't initialize if /hbase is not present
---
Key: HBASE-4705
URL: https://issues.apache.org/jira/browse/HBASE-4705
Project: HBase
Issue Type: Bug
Reporter: Harsh J
{code}
2011-10-31 00:09:09,549 FATAL org.apache.hadoop.hbase.master.HMaster: Unhandled
exception. Starting shutdown.
java.io.FileNotFoundException: File does not exist: hdfs://C3S31:9000/hbase
at
org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:731)
at org.apache.hadoop.hbase.util.FSUtils.isInSafeMode(FSUtils.java:163)
at org.apache.hadoop.hbase.util.FSUtils.waitOnSafeMode(FSUtils.java:458)
at
org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:301)
at
org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:127)
at
org.apache.hadoop.hbase.master.MasterFileSystem.init(MasterFileSystem.java:112)
at
org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:426)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:309)
at java.lang.Thread.run(Thread.java:662)
2011-10-31 00:09:09,551 INFO org.apache.hadoop.hbase.master.HMaster: Aborting
2011-10-31 00:09:09,551 DEBUG org.apache.hadoop.hbase.master.HMaster: Stopping
service threads
{code}
Trunk won't start HBase unless /hbase is already present, after HBASE-4680 (and
the silly error I made in HBASE-4510).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-4510) HDFS-1620 related changes downstream (For compiling with HDFS 0.23+)
HDFS-1620 related changes downstream (For compiling with HDFS 0.23+) Key: HBASE-4510 URL: https://issues.apache.org/jira/browse/HBASE-4510 Project: HBase Issue Type: Task Affects Versions: 0.94.0 Reporter: Harsh J Priority: Blocker HBase isn't seemingly compiling anymore on 0.23 after the HDFS-1620 naming refactorings were carried out. Two solutions: * We use new classnames. This breaks HBase's backward compatibility with older Hadoop releases (is that a concern with future releases?) * HBase gets its own sets of constants as the upstream one is not marked for public usage. This needs a little more maintenance on HBases' side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
