[jira] [Created] (HBASE-4882) Shell enhancements - getting description of row (list 'T1','R1')
Shell enhancements - getting description of row (list 'T1','R1') Key: HBASE-4882 URL: https://issues.apache.org/jira/browse/HBASE-4882 Project: HBase Issue Type: Improvement Components: shell Affects Versions: 0.90.2 Reporter: Mikael Sitruk Fix For: 0.90.2 In case a row keep a lot of columns, invoking the get operation on the key will display too much information (without scrolling possibility) The idea here is not to display the content of the cells, but the name of each columns. for example list 'T1','R1' will display the columns of R1 of T1 C1, C2, C3, C4, C5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-4902) invalid end key shown in hbase web ui.
invalid end key shown in hbase web ui. -- Key: HBASE-4902 URL: https://issues.apache.org/jira/browse/HBASE-4902 Project: HBase Issue Type: Bug Affects Versions: 0.90.2 Reporter: Mikael Sitruk i have 13 millions keys, I use presplit of 1000 regions. while looking at the regions created, i see Region Name : TC,sub_10386999,132260343.5b36001298f3dab177edf3a7265c628a. Start Key: sub_10386999 End Key: sub_103999 That is instead sub_10386999 + 13000 = sub_1039 the ui will only show sub_103 (missing last 9 digit) It occurs in several place in different region for another key also: Start: sub_4406999 End: sub_441999 instead of sub_441 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5110) code enhancement - remove unnecessary if-checks in every loop in HLog class
code enhancement - remove unnecessary if-checks in every loop in HLog class
---
Key: HBASE-5110
URL: https://issues.apache.org/jira/browse/HBASE-5110
Project: HBase
Issue Type: Improvement
Components: wal
Affects Versions: 0.90.4, 0.90.2, 0.90.1, 0.92.0
Reporter: Mikael Sitruk
Priority: Minor
The HLog class (method findMemstoresWithEditsEqualOrOlderThan) has unnecessary
if check in a loop.
static byte [][] findMemstoresWithEditsEqualOrOlderThan(final long
oldestWALseqid,
final Map regionsToSeqids) {
// This method is static so it can be unit tested the easier.
List regions = null;
for (Map.Entry e: regionsToSeqids.entrySet()) {
if (e.getValue().longValue() <= oldestWALseqid) {
if (regions == null) regions = new ArrayList();
regions.add(e.getKey());
}
}
return regions == null?
null: regions.toArray(new byte [][] {HConstants.EMPTY_BYTE_ARRAY});
}
The following change is suggested
static byte [][] findMemstoresWithEditsEqualOrOlderThan(final long
oldestWALseqid,
final Map regionsToSeqids) {
// This method is static so it can be unit tested the easier.
List regions = new ArrayList();
for (Map.Entry e: regionsToSeqids.entrySet()) {
if (e.getValue().longValue() <= oldestWALseqid) {
regions.add(e.getKey());
}
}
return regions.size() == 0?
null: regions.toArray(new byte [][] {HConstants.EMPTY_BYTE_ARRAY});
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5129) book is inconsistent regarding disabling - major compaction
book is inconsistent regarding disabling - major compaction --- Key: HBASE-5129 URL: https://issues.apache.org/jira/browse/HBASE-5129 Project: HBase Issue Type: Bug Components: documentation Affects Versions: 0.90.1 Reporter: Mikael Sitruk Priority: Minor It seems that the book has some inconsistencies regarding the way to disable major compactions According to the book in chapter 2.6.1.1. HBase Default Configuration hbase.hregion.majorcompaction - The time (in miliseconds) between 'major' compactions of all HStoreFiles in a region. Default: 1 day. Set to 0 to disable automated major compactions. Default: 8640 (http://hbase.apache.org/book.html#hbase_default_configurations) According to the book at chapter 2.8.2.8. Managed Compactions "A common administrative technique is to manage major compactions manually, rather than letting HBase do it. By default, HConstants.MAJOR_COMPACTION_PERIOD is one day and major compactions may kick in when you least desire it - especially on a busy system. To "turn off" automatic major compactions set the value to Long.MAX_VALUE." According to the code org.apache.hadoop.hbase.regionserver.Store.java, "0" is the right answer. (affect all documentation from 0.90.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] [Created] (HBASE-5146) Hbase Shell - allow setting config properties
Hbase Shell - allow setting config properties - Key: HBASE-5146 URL: https://issues.apache.org/jira/browse/HBASE-5146 Project: HBase Issue Type: New Feature Components: shell Affects Versions: 0.90.2, 0.90.1 Reporter: Mikael Sitruk It should be possible to set config properties of the cluster/table/column family via the shell and not only via API For example the 'hbase.hregion.majorcompaction' property cannot be set via the shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5147) Compaction/Major compaction operation from shell/API/JMX
Compaction/Major compaction operation from shell/API/JMX Key: HBASE-5147 URL: https://issues.apache.org/jira/browse/HBASE-5147 Project: HBase Issue Type: New Feature Components: master, regionserver, shell Affects Versions: 0.90.2, 0.90.1, 0.92.0 Reporter: Mikael Sitruk Compaction handling is important internal process nevertheless when it occurs it can have dramatic impact on cluster performance (especially when the cluster growth uniformly). Secondly current operations enabled are just to trigger a compaction process without possibility to know what is its status. Making very unconvenient to manage compaction manually. This JIRA suggests to allow management of compaction from different interfaces - Shell, API, JMX Following is the list of requested operations 1. getting compaction status - which server/region is under compaction and what is compacted (currently this info is only via log) 2. % of uncompacted files 3. Possibility to stop major compaction 4. Starting compaction from JMX (other interface already support this) Note - part of these requirements are also suggested in HBASE-3965 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-5148) Compaction property at the server level are not propagated at the table level.
Compaction property at the server level are not propagated at the table level.
--
Key: HBASE-5148
URL: https://issues.apache.org/jira/browse/HBASE-5148
Project: HBase
Issue Type: Bug
Components: master, regionserver
Affects Versions: 0.90.1
Reporter: Mikael Sitruk
In case you do not override compaction parameter on the table/cf level, the
values returned by the table descriptor will not reflect the value configured
in the cluster.
For example - let assume you disabled major compaction by setting
"hbase.hregion.majorcompaction" in the config to "0", prior starting the
cluster. Let also assume that you have a table that in which you didn't set at
all this parameter.
Then invoking
HTableDescriptor hTableDescriptor = conn.getHTableDescriptor(Bytes.toBytes("my
table"));
hTableDescriptor.getValue("hbase.hregion.majorcompaction")
should return the cluster property (currently returns the default, ignoring the
cluster prop.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-5149) getConfiguration() implementation is misleading
getConfiguration() implementation is misleading
---
Key: HBASE-5149
URL: https://issues.apache.org/jira/browse/HBASE-5149
Project: HBase
Issue Type: Improvement
Components: master, regionserver
Affects Versions: 0.90.4, 0.90.2, 0.90.1
Reporter: Mikael Sitruk
The following code will not return the cluster configuration but the local one
which is somewhat misleading.
{code}
conn = (HConnection) HConnectionManager.getConnection(m_hbConfig); //here the
configuration is local
Configuration conf = conn.getConfiguration()
conf.getString("hbase.hregion.majorcompaction"); // will return the parameter
from the local config instead of the cluster the connection is connected to.
{code}
It is suggested that once a connection has been acquired the configuration
object should be the one of the cluster.
As a general observation it is not possible to retrieve the used configuration
on the cluster
It is suggested to add API at {{HRegionServerInterface}}, {{HMasterInterface}}
to get the configuration used by the component appropriately (note in 0.90.4
the getConfiguration exist on the Server interface implemented by HRegionServer
and HMaster classes) but this interface is not visible/extended by
HRegionServerInterface/HMasterInterface, therefore not accessible from client
code.
Also an API like {{HashMap
getClusterConfigurations()}} can be added on the HConnection object.
Additional notes:
Since servers can have different properties values (like disk, tmp dir,...) it
can be acceptable that the configuration object returned by the connection
returns special value to indicate - conflict between value or that multiple
values exist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
