[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261342#comment-13261342 ] Hudson commented on HBASE-5848: --- Integrated in HBase-0.94 #147 (See [https://builds.apache.org/job/HBase-0.94/147/]) HBASE-5848 Addendum (Revision 1330106) Result = SUCCESS larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5869) Move SplitLogManager splitlog taskstate and AssignmentManager RegionTransitionData znode datas to pb
[ https://issues.apache.org/jira/browse/HBASE-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-5869: - Attachment: secondcut.txt Second cut. Still not done. > Move SplitLogManager splitlog taskstate and AssignmentManager > RegionTransitionData znode datas to pb > - > > Key: HBASE-5869 > URL: https://issues.apache.org/jira/browse/HBASE-5869 > Project: HBase > Issue Type: Task >Reporter: stack > Attachments: firstcut.txt, secondcut.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] [Commented] (HBASE-5863) Improve the graceful_stop.sh CLI help (especially about reloads)
[
https://issues.apache.org/jira/browse/HBASE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261338#comment-13261338
]
Hudson commented on HBASE-5863:
---
Integrated in HBase-TRUNK-security #183 (See
[https://builds.apache.org/job/HBase-TRUNK-security/183/])
HBASE-5863 Improve the graceful_stop.sh CLI help (especially about reloads)
(Revision 1329793)
Result = FAILURE
stack :
Files :
* /hbase/trunk/bin/graceful_stop.sh
> Improve the graceful_stop.sh CLI help (especially about reloads)
>
>
> Key: HBASE-5863
> URL: https://issues.apache.org/jira/browse/HBASE-5863
> Project: HBase
> Issue Type: Improvement
> Components: scripts
>Affects Versions: 0.94.0
>Reporter: Harsh J
>Assignee: Harsh J
>Priority: Minor
> Fix For: 0.92.2, 0.94.1
>
> Attachments: HBASE-5863.patch
>
>
> Right now, graceful_stop.sh prints:
> {code}
> Usage: graceful_stop.sh [--config ] [--restart] [--reload]
> [--thrift] [--rest]
> thrift If we should stop/start thrift before/after the hbase stop/start
> restIf we should stop/start rest before/after the hbase stop/start
> restart If we should restart after graceful stop
> reload Move offloaded regions back on to the stopped server
> debug Move offloaded regions back on to the stopped server
> hostnameHostname of server we are to stop
> {code}
> This does not help us specify that "reload" is actually a sub/additive-option
> to "restart".
> Also, the "debug" line seems to still have an old copy/paste mistake.
> I've updated these two in the patch here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261340#comment-13261340 ] Hudson commented on HBASE-5848: --- Integrated in HBase-TRUNK-security #183 (See [https://builds.apache.org/job/HBase-TRUNK-security/183/]) HBASE-5848 Addendum (Revision 1330105) HBASE-5848 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort (Ram) (Revision 1329819) Result = FAILURE larsh : Files : * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java ramkrishna : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261339#comment-13261339 ] Hudson commented on HBASE-5849: --- Integrated in HBase-TRUNK-security #183 (See [https://builds.apache.org/job/HBase-TRUNK-security/183/]) HBASE-5849 On first cluster startup, RS aborts if root znode is not available; REVERT (Revision 1329560) Result = FAILURE stack : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/TestClusterBootOrder.java > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4393) Implement a canary monitoring program
[ https://issues.apache.org/jira/browse/HBASE-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261337#comment-13261337 ] Hudson commented on HBASE-4393: --- Integrated in HBase-TRUNK-security #183 (See [https://builds.apache.org/job/HBase-TRUNK-security/183/]) HBASE-4393 Implement a canary monitoring program (Revision 1329574) Result = FAILURE stack : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/tools * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/tools/Canary.java > Implement a canary monitoring program > - > > Key: HBASE-4393 > URL: https://issues.apache.org/jira/browse/HBASE-4393 > Project: HBase > Issue Type: New Feature > Components: monitoring >Affects Versions: 0.92.0 >Reporter: Todd Lipcon >Assignee: Matteo Bertozzi > Fix For: 0.94.0, 0.96.0 > > Attachments: Canary-v0.java, HBASE-4393-v0.patch, HBaseCanary.java > > > This JIRA is to implement a standalone program that can be used to do "canary > monitoring" of a running HBase cluster. This program would gather a list of > the regions in the cluster, then iterate over them doing lightweight > operations (eg short scans) to provide metrics about latency as well as alert > on availability issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5064) utilize surefire tests parallelization
[ https://issues.apache.org/jira/browse/HBASE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261334#comment-13261334 ] Hudson commented on HBASE-5064: --- Integrated in HBase-TRUNK-security #183 (See [https://builds.apache.org/job/HBase-TRUNK-security/183/]) HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064 (Revision 1330072) Result = FAILURE jmhsieh : Files : * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java > utilize surefire tests parallelization > -- > > Key: HBASE-5064 > URL: https://issues.apache.org/jira/browse/HBASE-5064 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.94.0 >Reporter: nkeywal >Assignee: nkeywal > Fix For: 0.94.0 > > Attachments: 5064.addendum, 5064.patch, 5064.patch, 5064.v10.patch, > 5064.v11.patch, 5064.v12.patch, 5064.v13.patch, 5064.v14.patch, > 5064.v14.patch, 5064.v15.patch, 5064.v16.patch, 5064.v17.patch, > 5064.v18.patch, 5064.v18.patch, 5064.v19.patch, 5064.v19.patch, > 5064.v19.patch, 5064.v2.patch, 5064.v20.patch, 5064.v3.patch, 5064.v4.patch, > 5064.v5.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, > 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, > 5064.v8.patch, 5064.v8.patch, 5064.v9.patch > > > To be tried multiple times on hadoop-qa before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5866) Canary in tool package but says its in tools.
[ https://issues.apache.org/jira/browse/HBASE-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261335#comment-13261335 ] Hudson commented on HBASE-5866: --- Integrated in HBase-TRUNK-security #183 (See [https://builds.apache.org/job/HBase-TRUNK-security/183/]) HBASE-5866 Canary in tool package but says its in tools (Revision 1329898) Result = FAILURE stack : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/tool * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/tool/Canary.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/tools > Canary in tool package but says its in tools. > - > > Key: HBASE-5866 > URL: https://issues.apache.org/jira/browse/HBASE-5866 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 0.94.0, 0.96.0 > > Attachments: 5866.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] [Commented] (HBASE-5865) test-util.sh broken with unittest updates
[ https://issues.apache.org/jira/browse/HBASE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261336#comment-13261336 ] Hudson commented on HBASE-5865: --- Integrated in HBase-TRUNK-security #183 (See [https://builds.apache.org/job/HBase-TRUNK-security/183/]) HBASE-5865 test-util.sh broken with unittest updates (Revision 1329904) Result = FAILURE stack : Files : * /hbase/trunk/dev-support/test-util.sh > test-util.sh broken with unittest updates > - > > Key: HBASE-5865 > URL: https://issues.apache.org/jira/browse/HBASE-5865 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.96.0, 0.94.1 >Reporter: Jesse Yates >Assignee: Jesse Yates >Priority: Minor > Fix For: 0.96.0, 0.94.1 > > Attachments: sh_HBASE-5865-v0.patch > > > Since the default maven test is meant to be run on the server, this test > script always fails. Needs to take into account the location of where the > script is being run as well as some debugging options for future fixes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5861) Hadoop 23 compilation broken due to tests introduced in HBASE-5604
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261333#comment-13261333
]
Hudson commented on HBASE-5861:
---
Integrated in HBase-TRUNK-security #183 (See
[https://builds.apache.org/job/HBase-TRUNK-security/183/])
HBASE-5861 ADDENDUM (missed new MapredcueTestingShim.java file) (Revision
1330078)
HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064
(Revision 1330072)
Result = FAILURE
jmhsieh :
Files :
*
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java
jmhsieh :
Files :
*
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java
> Hadoop 23 compilation broken due to tests introduced in HBASE-5604
> --
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261332#comment-13261332 ] Hudson commented on HBASE-5848: --- Integrated in HBase-TRUNK #2810 (See [https://builds.apache.org/job/HBase-TRUNK/2810/]) HBASE-5848 Addendum (Revision 1330105) Result = FAILURE larsh : Files : * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5829) Inconsistency between the "regions" map and the "servers" map in AssignmentManager
[
https://issues.apache.org/jira/browse/HBASE-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maryann Xue updated HBASE-5829:
---
Status: Patch Available (was: Open)
> Inconsistency between the "regions" map and the "servers" map in
> AssignmentManager
> --
>
> Key: HBASE-5829
> URL: https://issues.apache.org/jira/browse/HBASE-5829
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.92.1, 0.90.6
>Reporter: Maryann Xue
> Attachments: HBASE-5829-0.90.patch, HBASE-5829-trunk.patch
>
>
> There are occurrences in AM where this.servers is not kept consistent with
> this.regions. This might cause balancer to offline a region from the RS that
> already returned NotServingRegionException at a previous offline attempt.
> In AssignmentManager.unassign(HRegionInfo, boolean)
> try {
> // TODO: We should consider making this look more like it does for the
> // region open where we catch all throwables and never abort
> if (serverManager.sendRegionClose(server, state.getRegion(),
> versionOfClosingNode)) {
> LOG.debug("Sent CLOSE to " + server + " for region " +
> region.getRegionNameAsString());
> return;
> }
> // This never happens. Currently regionserver close always return true.
> LOG.warn("Server " + server + " region CLOSE RPC returned false for " +
> region.getRegionNameAsString());
> } catch (NotServingRegionException nsre) {
> LOG.info("Server " + server + " returned " + nsre + " for " +
> region.getRegionNameAsString());
> // Presume that master has stale data. Presume remote side just split.
> // Presume that the split message when it comes in will fix up the
> master's
> // in memory cluster state.
> } catch (Throwable t) {
> if (t instanceof RemoteException) {
> t = ((RemoteException)t).unwrapRemoteException();
> if (t instanceof NotServingRegionException) {
> if (checkIfRegionBelongsToDisabling(region)) {
> // Remove from the regionsinTransition map
> LOG.info("While trying to recover the table "
> + region.getTableNameAsString()
> + " to DISABLED state the region " + region
> + " was offlined but the table was in DISABLING state");
> synchronized (this.regionsInTransition) {
> this.regionsInTransition.remove(region.getEncodedName());
> }
> // Remove from the regionsMap
> synchronized (this.regions) {
> this.regions.remove(region);
> }
> deleteClosingOrClosedNode(region);
> }
> }
> // RS is already processing this region, only need to update the
> timestamp
> if (t instanceof RegionAlreadyInTransitionException) {
> LOG.debug("update " + state + " the timestamp.");
> state.update(state.getState());
> }
> }
> In AssignmentManager.assign(HRegionInfo, RegionState, boolean, boolean,
> boolean)
> synchronized (this.regions) {
> this.regions.put(plan.getRegionInfo(), plan.getDestination());
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5829) Inconsistency between the "regions" map and the "servers" map in AssignmentManager
[
https://issues.apache.org/jira/browse/HBASE-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maryann Xue updated HBASE-5829:
---
Attachment: HBASE-5829-trunk.patch
HBASE-5829-0.90.patch
Add corresponding operations to this.servers
> Inconsistency between the "regions" map and the "servers" map in
> AssignmentManager
> --
>
> Key: HBASE-5829
> URL: https://issues.apache.org/jira/browse/HBASE-5829
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.90.6, 0.92.1
>Reporter: Maryann Xue
> Attachments: HBASE-5829-0.90.patch, HBASE-5829-trunk.patch
>
>
> There are occurrences in AM where this.servers is not kept consistent with
> this.regions. This might cause balancer to offline a region from the RS that
> already returned NotServingRegionException at a previous offline attempt.
> In AssignmentManager.unassign(HRegionInfo, boolean)
> try {
> // TODO: We should consider making this look more like it does for the
> // region open where we catch all throwables and never abort
> if (serverManager.sendRegionClose(server, state.getRegion(),
> versionOfClosingNode)) {
> LOG.debug("Sent CLOSE to " + server + " for region " +
> region.getRegionNameAsString());
> return;
> }
> // This never happens. Currently regionserver close always return true.
> LOG.warn("Server " + server + " region CLOSE RPC returned false for " +
> region.getRegionNameAsString());
> } catch (NotServingRegionException nsre) {
> LOG.info("Server " + server + " returned " + nsre + " for " +
> region.getRegionNameAsString());
> // Presume that master has stale data. Presume remote side just split.
> // Presume that the split message when it comes in will fix up the
> master's
> // in memory cluster state.
> } catch (Throwable t) {
> if (t instanceof RemoteException) {
> t = ((RemoteException)t).unwrapRemoteException();
> if (t instanceof NotServingRegionException) {
> if (checkIfRegionBelongsToDisabling(region)) {
> // Remove from the regionsinTransition map
> LOG.info("While trying to recover the table "
> + region.getTableNameAsString()
> + " to DISABLED state the region " + region
> + " was offlined but the table was in DISABLING state");
> synchronized (this.regionsInTransition) {
> this.regionsInTransition.remove(region.getEncodedName());
> }
> // Remove from the regionsMap
> synchronized (this.regions) {
> this.regions.remove(region);
> }
> deleteClosingOrClosedNode(region);
> }
> }
> // RS is already processing this region, only need to update the
> timestamp
> if (t instanceof RegionAlreadyInTransitionException) {
> LOG.debug("update " + state + " the timestamp.");
> state.update(state.getState());
> }
> }
> In AssignmentManager.assign(HRegionInfo, RegionState, boolean, boolean,
> boolean)
> synchronized (this.regions) {
> this.regions.put(plan.getRegionInfo(), plan.getDestination());
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5829) Inconsistency between the "regions" map and the "servers" map in AssignmentManager
[
https://issues.apache.org/jira/browse/HBASE-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261327#comment-13261327
]
Maryann Xue commented on HBASE-5829:
@ for the second, think we should guarantee that it is also added to the map
"this.servers".
> Inconsistency between the "regions" map and the "servers" map in
> AssignmentManager
> --
>
> Key: HBASE-5829
> URL: https://issues.apache.org/jira/browse/HBASE-5829
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.90.6, 0.92.1
>Reporter: Maryann Xue
> Attachments: HBASE-5829-0.90.patch, HBASE-5829-trunk.patch
>
>
> There are occurrences in AM where this.servers is not kept consistent with
> this.regions. This might cause balancer to offline a region from the RS that
> already returned NotServingRegionException at a previous offline attempt.
> In AssignmentManager.unassign(HRegionInfo, boolean)
> try {
> // TODO: We should consider making this look more like it does for the
> // region open where we catch all throwables and never abort
> if (serverManager.sendRegionClose(server, state.getRegion(),
> versionOfClosingNode)) {
> LOG.debug("Sent CLOSE to " + server + " for region " +
> region.getRegionNameAsString());
> return;
> }
> // This never happens. Currently regionserver close always return true.
> LOG.warn("Server " + server + " region CLOSE RPC returned false for " +
> region.getRegionNameAsString());
> } catch (NotServingRegionException nsre) {
> LOG.info("Server " + server + " returned " + nsre + " for " +
> region.getRegionNameAsString());
> // Presume that master has stale data. Presume remote side just split.
> // Presume that the split message when it comes in will fix up the
> master's
> // in memory cluster state.
> } catch (Throwable t) {
> if (t instanceof RemoteException) {
> t = ((RemoteException)t).unwrapRemoteException();
> if (t instanceof NotServingRegionException) {
> if (checkIfRegionBelongsToDisabling(region)) {
> // Remove from the regionsinTransition map
> LOG.info("While trying to recover the table "
> + region.getTableNameAsString()
> + " to DISABLED state the region " + region
> + " was offlined but the table was in DISABLING state");
> synchronized (this.regionsInTransition) {
> this.regionsInTransition.remove(region.getEncodedName());
> }
> // Remove from the regionsMap
> synchronized (this.regions) {
> this.regions.remove(region);
> }
> deleteClosingOrClosedNode(region);
> }
> }
> // RS is already processing this region, only need to update the
> timestamp
> if (t instanceof RegionAlreadyInTransitionException) {
> LOG.debug("update " + state + " the timestamp.");
> state.update(state.getState());
> }
> }
> In AssignmentManager.assign(HRegionInfo, RegionState, boolean, boolean,
> boolean)
> synchronized (this.regions) {
> this.regions.put(plan.getRegionInfo(), plan.getDestination());
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5732) Remove the SecureRPCEngine and merge the security-related logic in the core engine
[ https://issues.apache.org/jira/browse/HBASE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261325#comment-13261325 ] Andrew Purtell commented on HBASE-5732: --- Only the secure RPC basics have been merged. Please reread my above comments about TokenProvider and AccessController. > Remove the SecureRPCEngine and merge the security-related logic in the core > engine > -- > > Key: HBASE-5732 > URL: https://issues.apache.org/jira/browse/HBASE-5732 > Project: HBase > Issue Type: Improvement >Reporter: Devaraj Das >Assignee: Devaraj Das > Attachments: rpcengine-merge.3.patch, rpcengine-merge.patch > > > Remove the SecureRPCEngine and merge the security-related logic in the core > engine. Follow up to HBASE-5727. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5864) Error while reading from hfile in 0.94
[
https://issues.apache.org/jira/browse/HBASE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-5864:
-
Priority: Blocker (was: Critical)
I see. This is a blocker then.
> Error while reading from hfile in 0.94
> --
>
> Key: HBASE-5864
> URL: https://issues.apache.org/jira/browse/HBASE-5864
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.94.0
>Reporter: Gopinathan A
>Assignee: ramkrishna.s.vasudevan
>Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: HBASE-5864_1.patch, HBASE-5864_2.patch,
> HBASE-5864_test.patch
>
>
> Got the following stacktrace during region split.
> {noformat}
> 2012-04-24 16:05:42,168 WARN org.apache.hadoop.hbase.regionserver.Store:
> Failed getting store size for value
> java.io.IOException: Requested block is out of range: 2906737606134037404,
> lastDataBlockOffset: 84764558
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:278)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.midkey(HFileBlockIndex.java:285)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.midkey(HFileReaderV2.java:402)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Reader.midkey(StoreFile.java:1638)
> at
> org.apache.hadoop.hbase.regionserver.Store.getSplitPoint(Store.java:1943)
> at
> org.apache.hadoop.hbase.regionserver.RegionSplitPolicy.getSplitPoint(RegionSplitPolicy.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkSplit(HRegion.java:4921)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.splitRegion(HRegionServer.java:2901)
> {noformat}
--
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-5871) Usability regression, we don't parse compression algos anymore
[
https://issues.apache.org/jira/browse/HBASE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved HBASE-5871.
--
Resolution: Fixed
Committed to 0.92, 0.94, 0.96.
> Usability regression, we don't parse compression algos anymore
> --
>
> Key: HBASE-5871
> URL: https://issues.apache.org/jira/browse/HBASE-5871
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.1
>Reporter: Jean-Daniel Cryans
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5871-0.92.txt, 5871-0.94.txt, 5871-trunk.txt
>
>
> It seems that string with 0.92.0 we can't create tables in the shell by
> specifying "lzo" anymore. I remember we used to do better parsing than that,
> but right now if you follow the wiki doing this:
> bq. create 'mytable', {NAME=>'colfam:', COMPRESSION=>'lzo'}
> You'll get:
> bq. ERROR: java.lang.IllegalArgumentException: No enum const class
> org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.lzo
> Bad for usability.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5864) Error while reading from hfile in 0.94
[
https://issues.apache.org/jira/browse/HBASE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261319#comment-13261319
]
ramkrishna.s.vasudevan commented on HBASE-5864:
---
@Lars
In a file that has only one level of index, if we need to find the midkey(
during external split operation) we should ideally get the midkey from
{code}
else {
// The middle of the root-level index.
midKey = blockKeys[(rootCount - 1) / 2];
}
{code}
Because the midLeafBlockOffset should be -1.
But in this problem that we faced the midLeafBlockOffset is wrongly set with
some value and hence the midkey() tries to
{code}
if (midLeafBlockOffset >= 0) {
if (cachingBlockReader == null) {
throw new IOException("Have to read the middle leaf block but " +
"no block reader available");
}
// Caching, using pread, assuming this is not a compaction.
HFileBlock midLeafBlock = cachingBlockReader.readBlock(
midLeafBlockOffset, midLeafBlockOnDiskSize, true, true, false,
BlockType.LEAF_INDEX);
{code}
That is where the problem happens as per this bug. For a single level index
file there should not be any midLeafBlockOffset. Correct me if am wrong.
> Error while reading from hfile in 0.94
> --
>
> Key: HBASE-5864
> URL: https://issues.apache.org/jira/browse/HBASE-5864
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.94.0
>Reporter: Gopinathan A
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.94.0
>
> Attachments: HBASE-5864_1.patch, HBASE-5864_2.patch,
> HBASE-5864_test.patch
>
>
> Got the following stacktrace during region split.
> {noformat}
> 2012-04-24 16:05:42,168 WARN org.apache.hadoop.hbase.regionserver.Store:
> Failed getting store size for value
> java.io.IOException: Requested block is out of range: 2906737606134037404,
> lastDataBlockOffset: 84764558
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:278)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.midkey(HFileBlockIndex.java:285)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.midkey(HFileReaderV2.java:402)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Reader.midkey(StoreFile.java:1638)
> at
> org.apache.hadoop.hbase.regionserver.Store.getSplitPoint(Store.java:1943)
> at
> org.apache.hadoop.hbase.regionserver.RegionSplitPolicy.getSplitPoint(RegionSplitPolicy.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkSplit(HRegion.java:4921)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.splitRegion(HRegionServer.java:2901)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-5849: - Resolution: Fixed Status: Resolved (was: Patch Available) Applied to 0.92, 0.94, and trunk (took Ted's work for it that it works -- thanks Ted). Thanks for the patch Enis and for digging in again. > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5732) Remove the SecureRPCEngine and merge the security-related logic in the core engine
[ https://issues.apache.org/jira/browse/HBASE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261318#comment-13261318 ] Zhihong Yu commented on HBASE-5732: --- Now that security profile is gone in patch v2, the build would be intrinsically secure HBase ? > Remove the SecureRPCEngine and merge the security-related logic in the core > engine > -- > > Key: HBASE-5732 > URL: https://issues.apache.org/jira/browse/HBASE-5732 > Project: HBase > Issue Type: Improvement >Reporter: Devaraj Das >Assignee: Devaraj Das > Attachments: rpcengine-merge.3.patch, rpcengine-merge.patch > > > Remove the SecureRPCEngine and merge the security-related logic in the core > engine. Follow up to HBASE-5727. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261316#comment-13261316 ] Lars Hofhansl commented on HBASE-5849: -- TestRegionRebalancing is unrelated (see HBASE-5848). TestReplication passes for me locally with v4 applied. > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5864) Error while reading from hfile in 0.94
[
https://issues.apache.org/jira/browse/HBASE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261315#comment-13261315
]
Lars Hofhansl commented on HBASE-5864:
--
I also don't quite follow the patch or problem.
How is it that HBase during normal operation (scanning, etc) can read HFiles
correctly?
> Error while reading from hfile in 0.94
> --
>
> Key: HBASE-5864
> URL: https://issues.apache.org/jira/browse/HBASE-5864
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.94.0
>Reporter: Gopinathan A
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.94.0
>
> Attachments: HBASE-5864_1.patch, HBASE-5864_2.patch,
> HBASE-5864_test.patch
>
>
> Got the following stacktrace during region split.
> {noformat}
> 2012-04-24 16:05:42,168 WARN org.apache.hadoop.hbase.regionserver.Store:
> Failed getting store size for value
> java.io.IOException: Requested block is out of range: 2906737606134037404,
> lastDataBlockOffset: 84764558
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:278)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.midkey(HFileBlockIndex.java:285)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.midkey(HFileReaderV2.java:402)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Reader.midkey(StoreFile.java:1638)
> at
> org.apache.hadoop.hbase.regionserver.Store.getSplitPoint(Store.java:1943)
> at
> org.apache.hadoop.hbase.regionserver.RegionSplitPolicy.getSplitPoint(RegionSplitPolicy.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkSplit(HRegion.java:4921)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.splitRegion(HRegionServer.java:2901)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261314#comment-13261314 ] stack commented on HBASE-5849: -- @Enis LruBlockCache.EvictionThread should be cleaned up on cluster shutdown? I thought I fixed that a day or so ago. > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5871) Usability regression, we don't parse compression algos anymore
[
https://issues.apache.org/jira/browse/HBASE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261313#comment-13261313
]
stack commented on HBASE-5871:
--
+1 if it works
> Usability regression, we don't parse compression algos anymore
> --
>
> Key: HBASE-5871
> URL: https://issues.apache.org/jira/browse/HBASE-5871
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.1
>Reporter: Jean-Daniel Cryans
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5871-0.92.txt, 5871-0.94.txt, 5871-trunk.txt
>
>
> It seems that string with 0.92.0 we can't create tables in the shell by
> specifying "lzo" anymore. I remember we used to do better parsing than that,
> but right now if you follow the wiki doing this:
> bq. create 'mytable', {NAME=>'colfam:', COMPRESSION=>'lzo'}
> You'll get:
> bq. ERROR: java.lang.IllegalArgumentException: No enum const class
> org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.lzo
> Bad for usability.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5732) Remove the SecureRPCEngine and merge the security-related logic in the core engine
[ https://issues.apache.org/jira/browse/HBASE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261312#comment-13261312 ] Andrew Purtell commented on HBASE-5732: --- TokenProvider is an interesting issue. On the one hand it pulls in new runtime dependencies on ZooKeeper (it will abort the RS if shared private keys for creating MR job tokens cannot be synced or rolled); on the other, authentication for HBase clients in MR jobs when HBase RPC security is enabled must happen via a token based mechanism such as TokenProvider provides. In production we've found that sharing state in ZK as TokenProvider does introduces new cases of RS aborts when the network has issues. Whether the RS would have gone down anyway is a good possibility. We could leave it aside as a CP that people must use if they want to run MR jobs with secure RPC, or consider folding it in as well as a follow on JIRA, along with possible design changes. However I think the design is pretty good, and it's proven in production, and ZK disconnects are an issue elsewhere as well. But increasing the cases where ZK disconnects can be a problem should be considered. > Remove the SecureRPCEngine and merge the security-related logic in the core > engine > -- > > Key: HBASE-5732 > URL: https://issues.apache.org/jira/browse/HBASE-5732 > Project: HBase > Issue Type: Improvement >Reporter: Devaraj Das >Assignee: Devaraj Das > Attachments: rpcengine-merge.3.patch, rpcengine-merge.patch > > > Remove the SecureRPCEngine and merge the security-related logic in the core > engine. Follow up to HBASE-5727. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5853) java.lang.RuntimeException: readObject can't find class org.apache.hadoop.hdfs.protocol.HdfsFileStatus
[ https://issues.apache.org/jira/browse/HBASE-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261310#comment-13261310 ] Lars Hofhansl commented on HBASE-5853: -- Had anybody else seen this? Seem any HBase flushCache on top of Hadoop 0.23 should cause this. > java.lang.RuntimeException: readObject can't find class > org.apache.hadoop.hdfs.protocol.HdfsFileStatus > -- > > Key: HBASE-5853 > URL: https://issues.apache.org/jira/browse/HBASE-5853 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.92.1 > Environment: hadoop-0.23.1 hbase-0.92.1 >Reporter: jiafeng.zhang > Fix For: 0.92.1, 0.94.0 > > > 2012-04-23 12:51:07,474 WARN org.apache.hadoop.ipc.Client: Unexpected error > reading responses on connection Thread[IPC Client (1260987126) connection to > server121/172.16.40.121:9000 from smp,5,main] > java.lang.RuntimeException: readObject can't find class > org.apache.hadoop.hdfs.protocol.HdfsFileStatus > at > org.apache.hadoop.io.ObjectWritable.loadClass(ObjectWritable.java:372) > at > org.apache.hadoop.io.ObjectWritable.readObject(ObjectWritable.java:223) > at > org.apache.hadoop.io.ObjectWritable.readFields(ObjectWritable.java:75) > at > org.apache.hadoop.ipc.Client$Connection.receiveResponse(Client.java:832) > at org.apache.hadoop.ipc.Client$Connection.run(Client.java:756) > Caused by: java.lang.ClassNotFoundException: Class > org.apache.hadoop.hdfs.protocol.HdfsFileStatus not found > at > org.apache.hadoop.conf.Configuration.getClassByName(Configuration.java:1151) > at > org.apache.hadoop.io.ObjectWritable.loadClass(ObjectWritable.java:368) > ... 4 more > 2012-04-23 12:51:07,797 FATAL > org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server > server124,60020,1335152900476: Replay of HLog required. Forcing server > shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > hbase_cdr,e0072b2b-5e19-431f-bb69-a6427765eac4,1334902272934.8365a7cbf90dd558f297d70224113c8a. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1278) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1162) > at > org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1104) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:400) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushOneForGlobalPressure(MemStoreFlusher.java:202) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.run(MemStoreFlusher.java:223) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.io.IOException: Failed on local exception: > java.io.IOException: Error reading responses; Host Details : local host is: > "server124/172.16.40.124"; destination host is: ""server121":9000; > at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:724) > at org.apache.hadoop.ipc.Client.call(Client.java:1094) > at > org.apache.hadoop.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:193) > at $Proxy10.getFileInfo(Unknown Source) > at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:100) > at > org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:65) > at $Proxy10.getFileInfo(Unknown Source) > at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1172) > at > org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:725) > at > org.apache.hadoop.hbase.regionserver.StoreFile.computeHDFSBlockDistribution(StoreFile.java:449) > at > org.apache.hadoop.hbase.regionserver.StoreFile.open(StoreFile.java:473) > at > org.apache.hadoop.hbase.regionserver.StoreFile.createReader(StoreFile.java:548) > at > org.apache.hadoop.hbase.regionserver.Store.internalFlushCache(Store.java:595) > at org.apache.hadoop.hbase.regionserver.Store.flushCache(Store.java:506) > at org.apache.hadoop.hbase.regionserver.Store.access$100(Store.java:89) > at > org.apache.hadoop.hbase.regionserver.Store$StoreFlusherImpl.flushCache(Store.java:1905) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1254) > ... 6 more > Caused by: java.io.IOException: Error reading responses > at org.apache.hadoo
[jira] [Assigned] (HBASE-5871) Usability regression, we don't parse compression algos anymore
[
https://issues.apache.org/jira/browse/HBASE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl reassigned HBASE-5871:
Assignee: Lars Hofhansl
> Usability regression, we don't parse compression algos anymore
> --
>
> Key: HBASE-5871
> URL: https://issues.apache.org/jira/browse/HBASE-5871
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.1
>Reporter: Jean-Daniel Cryans
>Assignee: Lars Hofhansl
>Priority: Critical
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5871-0.92.txt, 5871-0.94.txt, 5871-trunk.txt
>
>
> It seems that string with 0.92.0 we can't create tables in the shell by
> specifying "lzo" anymore. I remember we used to do better parsing than that,
> but right now if you follow the wiki doing this:
> bq. create 'mytable', {NAME=>'colfam:', COMPRESSION=>'lzo'}
> You'll get:
> bq. ERROR: java.lang.IllegalArgumentException: No enum const class
> org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.lzo
> Bad for usability.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5871) Usability regression, we don't parse compression algos anymore
[
https://issues.apache.org/jira/browse/HBASE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-5871:
-
Attachment: 5871-trunk.txt
5871-0.94.txt
5871-0.92.txt
Indeed in 0.92+ somebody added a superfluous call to setCompression, which
causes this problem.
Simple patches for 0.92, 0.94, and 0.96, removing that. Works fine now.
> Usability regression, we don't parse compression algos anymore
> --
>
> Key: HBASE-5871
> URL: https://issues.apache.org/jira/browse/HBASE-5871
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.1
>Reporter: Jean-Daniel Cryans
>Priority: Critical
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
> Attachments: 5871-0.92.txt, 5871-0.94.txt, 5871-trunk.txt
>
>
> It seems that string with 0.92.0 we can't create tables in the shell by
> specifying "lzo" anymore. I remember we used to do better parsing than that,
> but right now if you follow the wiki doing this:
> bq. create 'mytable', {NAME=>'colfam:', COMPRESSION=>'lzo'}
> You'll get:
> bq. ERROR: java.lang.IllegalArgumentException: No enum const class
> org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.lzo
> Bad for usability.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261308#comment-13261308 ] Zhihong Yu commented on HBASE-5849: --- I looped TestClusterBootOrder using patch v4 5 times and didn't see hanging test. > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5864) Error while reading from hfile in 0.94
[
https://issues.apache.org/jira/browse/HBASE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261307#comment-13261307
]
ramkrishna.s.vasudevan commented on HBASE-5864:
---
bq.I suggest using HFileBlock.totalChecksumBytes() in place of the above.
Yes Ted this should be used. It's scope is default so we can use it.
> Error while reading from hfile in 0.94
> --
>
> Key: HBASE-5864
> URL: https://issues.apache.org/jira/browse/HBASE-5864
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.94.0
>Reporter: Gopinathan A
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.94.0
>
> Attachments: HBASE-5864_1.patch, HBASE-5864_2.patch,
> HBASE-5864_test.patch
>
>
> Got the following stacktrace during region split.
> {noformat}
> 2012-04-24 16:05:42,168 WARN org.apache.hadoop.hbase.regionserver.Store:
> Failed getting store size for value
> java.io.IOException: Requested block is out of range: 2906737606134037404,
> lastDataBlockOffset: 84764558
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:278)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.midkey(HFileBlockIndex.java:285)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.midkey(HFileReaderV2.java:402)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Reader.midkey(StoreFile.java:1638)
> at
> org.apache.hadoop.hbase.regionserver.Store.getSplitPoint(Store.java:1943)
> at
> org.apache.hadoop.hbase.regionserver.RegionSplitPolicy.getSplitPoint(RegionSplitPolicy.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkSplit(HRegion.java:4921)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.splitRegion(HRegionServer.java:2901)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261306#comment-13261306 ] ramkrishna.s.vasudevan commented on HBASE-5848: --- @Lars and @Ted Thank you very much. > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261304#comment-13261304 ] Hadoop QA commented on HBASE-5848: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12524110/5848-addendum-v7.txt against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. -1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.hbase.client.TestFromClientSide org.apache.hadoop.hbase.replication.TestReplication org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1641//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1641//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1641//console This message is automatically generated. > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5870) Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method is not found
[
https://issues.apache.org/jira/browse/HBASE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261302#comment-13261302
]
Hadoop QA commented on HBASE-5870:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12524109/5870.txt
against trunk revision .
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 6 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.TestRegionRebalancing
org.apache.hadoop.hbase.replication.TestReplication
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1642//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1642//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1642//console
This message is automatically generated.
> Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method
> is not found
> -
>
> Key: HBASE-5870
> URL: https://issues.apache.org/jira/browse/HBASE-5870
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.96.0
>
> Attachments: 5870.txt
>
>
> After HBASE-5861 on 0.94 we are left with this issue on trunk.
> {code}
> $ mvn clean test -PlocalTests -DskipTests -Dhadoop.profile=23
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure
> [ERROR]
> /home/jon/proj/hbase-svn/hbase/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:[1333,35]
> cannot find symbol
> [ERROR] symbol : method getJobTracker()
> [ERROR] location: class
> org.apache.hadoop.mapred.MiniMRCluster.JobTrackerRunner
> [ERROR] -> [Help 1]
> {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] [Updated] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5848: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Addendum committed to 0.94 and 0.96. > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261298#comment-13261298 ] Hadoop QA commented on HBASE-5848: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12524107/5848-addendum-v7.txt against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. -1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1640//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1640//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1640//console This message is automatically generated. > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261291#comment-13261291 ] Zhihong Yu commented on HBASE-5872: --- Thanks for the explanation, Jon. I think the patch cannot be tested by Hadoop QA. Otherwise the QA report should include have contained compilation error instead of failed tests. I am fine with checking in the patch after HBASE-5870 is fixed - otherwise all Hadoop QA reports would only contain compilation error :-) > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261289#comment-13261289 ] Jonathan Hsieh commented on HBASE-5872: --- The goal I had in mind for this patch is to get compilation problems caught before commit. Waiting for the daily build assumes that it is committed already. > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5848: - Status: Patch Available (was: Open) > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5848: - Attachment: 5848-addendum-v7.txt Trying again for HadoopQA > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, 5848-addendum-v7.txt, HBASE-5848.patch, > HBASE-5848.patch, HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5848: - Status: Open (was: Patch Available) > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, HBASE-5848.patch, HBASE-5848.patch, > HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4393) Implement a canary monitoring program
[ https://issues.apache.org/jira/browse/HBASE-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261286#comment-13261286 ] Lars Hofhansl commented on HBASE-4393: -- Thanks Stack... I do like this in 0.94 (- the wrong package of course :) ) > Implement a canary monitoring program > - > > Key: HBASE-4393 > URL: https://issues.apache.org/jira/browse/HBASE-4393 > Project: HBase > Issue Type: New Feature > Components: monitoring >Affects Versions: 0.92.0 >Reporter: Todd Lipcon >Assignee: Matteo Bertozzi > Fix For: 0.94.0, 0.96.0 > > Attachments: Canary-v0.java, HBASE-4393-v0.patch, HBaseCanary.java > > > This JIRA is to implement a standalone program that can be used to do "canary > monitoring" of a running HBase cluster. This program would gather a list of > the regions in the cluster, then iterate over them doing lightweight > operations (eg short scans) to provide metrics about latency as well as alert > on availability issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261285#comment-13261285 ] Jonathan Hsieh commented on HBASE-5872: --- @Zhihong When I tested the script I notice that the unit tests (where there can be compilation errors) are not compiled unless the test phase is included. So, 'mvn test -DskipTests' compiles the tests but does not run them which is what I wanted. (I had added a comment about core and tests compilation). > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5870) Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method is not found
[
https://issues.apache.org/jira/browse/HBASE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-5870:
-
Status: Patch Available (was: Open)
> Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method
> is not found
> -
>
> Key: HBASE-5870
> URL: https://issues.apache.org/jira/browse/HBASE-5870
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.96.0
>
> Attachments: 5870.txt
>
>
> After HBASE-5861 on 0.94 we are left with this issue on trunk.
> {code}
> $ mvn clean test -PlocalTests -DskipTests -Dhadoop.profile=23
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure
> [ERROR]
> /home/jon/proj/hbase-svn/hbase/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:[1333,35]
> cannot find symbol
> [ERROR] symbol : method getJobTracker()
> [ERROR] location: class
> org.apache.hadoop.mapred.MiniMRCluster.JobTrackerRunner
> [ERROR] -> [Help 1]
> {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] [Updated] (HBASE-5870) Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method is not found
[
https://issues.apache.org/jira/browse/HBASE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-5870:
-
Attachment: 5870.txt
Ted's proposed patch extracted from parent.
> Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method
> is not found
> -
>
> Key: HBASE-5870
> URL: https://issues.apache.org/jira/browse/HBASE-5870
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.96.0
>
> Attachments: 5870.txt
>
>
> After HBASE-5861 on 0.94 we are left with this issue on trunk.
> {code}
> $ mvn clean test -PlocalTests -DskipTests -Dhadoop.profile=23
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure
> [ERROR]
> /home/jon/proj/hbase-svn/hbase/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:[1333,35]
> cannot find symbol
> [ERROR] symbol : method getJobTracker()
> [ERROR] location: class
> org.apache.hadoop.mapred.MiniMRCluster.JobTrackerRunner
> [ERROR] -> [Help 1]
> {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] [Updated] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5848: - Attachment: 5848-addendum-v7.txt Arrghhh... Off by one. Now fixed in TestRegionBalancing > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > 5848-addendum-v7.txt, HBASE-5848.patch, HBASE-5848.patch, > HBASE-5848_0.94.patch, HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261278#comment-13261278 ] Lars Hofhansl commented on HBASE-5848: -- @Ram: No worries. I looked at the patch too. This is part of doing development. :) > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, > HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5864) Error while reading from hfile in 0.94
[
https://issues.apache.org/jira/browse/HBASE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261276#comment-13261276
]
ramkrishna.s.vasudevan commented on HBASE-5864:
---
bq.Dhruba should have a look this too.
+1 on Dhruba seeing this.
> Error while reading from hfile in 0.94
> --
>
> Key: HBASE-5864
> URL: https://issues.apache.org/jira/browse/HBASE-5864
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.94.0
>Reporter: Gopinathan A
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.94.0
>
> Attachments: HBASE-5864_1.patch, HBASE-5864_2.patch,
> HBASE-5864_test.patch
>
>
> Got the following stacktrace during region split.
> {noformat}
> 2012-04-24 16:05:42,168 WARN org.apache.hadoop.hbase.regionserver.Store:
> Failed getting store size for value
> java.io.IOException: Requested block is out of range: 2906737606134037404,
> lastDataBlockOffset: 84764558
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:278)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.midkey(HFileBlockIndex.java:285)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.midkey(HFileReaderV2.java:402)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Reader.midkey(StoreFile.java:1638)
> at
> org.apache.hadoop.hbase.regionserver.Store.getSplitPoint(Store.java:1943)
> at
> org.apache.hadoop.hbase.regionserver.RegionSplitPolicy.getSplitPoint(RegionSplitPolicy.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkSplit(HRegion.java:4921)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.splitRegion(HRegionServer.java:2901)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5848: - Status: Patch Available (was: Open) > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, > HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261274#comment-13261274 ] ramkrishna.s.vasudevan commented on HBASE-5848: --- Sorry guys... :( I was the reason for this trouble. I should have been very careful before doing this. > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, > HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5672) TestLruBlockCache#testBackgroundEvictionThread fails occasionally
[
https://issues.apache.org/jira/browse/HBASE-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261259#comment-13261259
]
Hadoop QA commented on HBASE-5672:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12524103/HBASE-5672v3.patch
against trunk revision .
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
-1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9)
warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.TestRegionRebalancing
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/1638//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/1638//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/1638//console
This message is automatically generated.
> TestLruBlockCache#testBackgroundEvictionThread fails occasionally
> -
>
> Key: HBASE-5672
> URL: https://issues.apache.org/jira/browse/HBASE-5672
> Project: HBase
> Issue Type: Bug
>Reporter: chunhui shen
>Assignee: chunhui shen
> Attachments: HBASE-5672.patch, HBASE-5672v2.patch, HBASE-5672v3.patch
>
>
> We find TestLruBlockCache#testBackgroundEvictionThread fails occasionally.
> I think it's a problem of the test case.
> Because runEviction() only do evictionThread.evict():
> {code}
> public void evict() {
> synchronized(this) {
> this.notify(); // FindBugs NN_NAKED_NOTIFY
> }
> }
> {code}
> However when we call evictionThread.evict(), the evictionThread may haven't
> been in run() in the TestLruBlockCache#testBackgroundEvictionThread.
> If we run the test many times, we could find failture easily.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5870) Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method is not found
[
https://issues.apache.org/jira/browse/HBASE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261254#comment-13261254
]
Zhihong Yu commented on HBASE-5870:
---
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK-on-Hadoop-23/136/console
was the last build which didn't show this compilation error.
> Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method
> is not found
> -
>
> Key: HBASE-5870
> URL: https://issues.apache.org/jira/browse/HBASE-5870
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.96.0
>
>
> After HBASE-5861 on 0.94 we are left with this issue on trunk.
> {code}
> $ mvn clean test -PlocalTests -DskipTests -Dhadoop.profile=23
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure
> [ERROR]
> /home/jon/proj/hbase-svn/hbase/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:[1333,35]
> cannot find symbol
> [ERROR] symbol : method getJobTracker()
> [ERROR] location: class
> org.apache.hadoop.mapred.MiniMRCluster.JobTrackerRunner
> [ERROR] -> [Help 1]
> {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] [Commented] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261253#comment-13261253 ] Hadoop QA commented on HBASE-5849: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12524099/HBASE-5849_v4.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 2 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. -1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.hbase.TestRegionRebalancing org.apache.hadoop.hbase.replication.TestReplication Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1637//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1637//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1637//console This message is automatically generated. > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5672) TestLruBlockCache#testBackgroundEvictionThread fails occasionally
[
https://issues.apache.org/jira/browse/HBASE-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-5672:
Attachment: HBASE-5672v3.patch
Update the patch for applying to current trunk version
> TestLruBlockCache#testBackgroundEvictionThread fails occasionally
> -
>
> Key: HBASE-5672
> URL: https://issues.apache.org/jira/browse/HBASE-5672
> Project: HBase
> Issue Type: Bug
>Reporter: chunhui shen
>Assignee: chunhui shen
> Attachments: HBASE-5672.patch, HBASE-5672v2.patch, HBASE-5672v3.patch
>
>
> We find TestLruBlockCache#testBackgroundEvictionThread fails occasionally.
> I think it's a problem of the test case.
> Because runEviction() only do evictionThread.evict():
> {code}
> public void evict() {
> synchronized(this) {
> this.notify(); // FindBugs NN_NAKED_NOTIFY
> }
> }
> {code}
> However when we call evictionThread.evict(), the evictionThread may haven't
> been in run() in the TestLruBlockCache#testBackgroundEvictionThread.
> If we run the test many times, we could find failture easily.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5870) Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method is not found
[
https://issues.apache.org/jira/browse/HBASE-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhihong Yu updated HBASE-5870:
--
Summary: Hadoop 23 compilation broken because
JobTrackerRunner#getJobTracker() method is not found (was: Hadoop 23 compile
broken because can't find HBaseTestingUtility#getJobTracker() method)
> Hadoop 23 compilation broken because JobTrackerRunner#getJobTracker() method
> is not found
> -
>
> Key: HBASE-5870
> URL: https://issues.apache.org/jira/browse/HBASE-5870
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.96.0
>
>
> After HBASE-5861 on 0.94 we are left with this issue on trunk.
> {code}
> $ mvn clean test -PlocalTests -DskipTests -Dhadoop.profile=23
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure
> [ERROR]
> /home/jon/proj/hbase-svn/hbase/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java:[1333,35]
> cannot find symbol
> [ERROR] symbol : method getJobTracker()
> [ERROR] location: class
> org.apache.hadoop.mapred.MiniMRCluster.JobTrackerRunner
> [ERROR] -> [Help 1]
> {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] [Updated] (HBASE-5861) Hadoop 23 compilation broken due to tests introduced in HBASE-5604
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhihong Yu updated HBASE-5861:
--
Summary: Hadoop 23 compilation broken due to tests introduced in HBASE-5604
(was: Hadoop 23 compile broken due to tests introduced in HBASE-5064 )
> Hadoop 23 compilation broken due to tests introduced in HBASE-5604
> --
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5064) utilize surefire tests parallelization
[ https://issues.apache.org/jira/browse/HBASE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261240#comment-13261240 ] Hudson commented on HBASE-5064: --- Integrated in HBase-TRUNK #2809 (See [https://builds.apache.org/job/HBase-TRUNK/2809/]) HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064 (Revision 1330072) Result = FAILURE jmhsieh : Files : * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java > utilize surefire tests parallelization > -- > > Key: HBASE-5064 > URL: https://issues.apache.org/jira/browse/HBASE-5064 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.94.0 >Reporter: nkeywal >Assignee: nkeywal > Fix For: 0.94.0 > > Attachments: 5064.addendum, 5064.patch, 5064.patch, 5064.v10.patch, > 5064.v11.patch, 5064.v12.patch, 5064.v13.patch, 5064.v14.patch, > 5064.v14.patch, 5064.v15.patch, 5064.v16.patch, 5064.v17.patch, > 5064.v18.patch, 5064.v18.patch, 5064.v19.patch, 5064.v19.patch, > 5064.v19.patch, 5064.v2.patch, 5064.v20.patch, 5064.v3.patch, 5064.v4.patch, > 5064.v5.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, > 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, > 5064.v8.patch, 5064.v8.patch, 5064.v9.patch > > > To be tried multiple times on hadoop-qa before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5862) After Region Close remove the Operation Metrics.
[ https://issues.apache.org/jira/browse/HBASE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261238#comment-13261238 ] Zhihong Yu commented on HBASE-5862: --- MetricsRecord has become an interface in MRv2. Please introduce Shim to make the solution work for both hadoop 1.0 and 2.0 > After Region Close remove the Operation Metrics. > > > Key: HBASE-5862 > URL: https://issues.apache.org/jira/browse/HBASE-5862 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Minor > Attachments: HBASE-5862-0.patch, HBASE-5862-1.patch, > HBASE-5862-2.patch, HBASE-5862-3.patch > > > If a region is closed then Hadoop metrics shouldn't still be reporting about > that region. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5861) Hadoop 23 compile broken due to tests introduced in HBASE-5064
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261239#comment-13261239
]
Hudson commented on HBASE-5861:
---
Integrated in HBase-TRUNK #2809 (See
[https://builds.apache.org/job/HBase-TRUNK/2809/])
HBASE-5861 ADDENDUM (missed new MapredcueTestingShim.java file) (Revision
1330078)
HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064
(Revision 1330072)
Result = FAILURE
jmhsieh :
Files :
*
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java
jmhsieh :
Files :
*
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java
> Hadoop 23 compile broken due to tests introduced in HBASE-5064
> ---
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5064) utilize surefire tests parallelization
[ https://issues.apache.org/jira/browse/HBASE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261231#comment-13261231 ] Hudson commented on HBASE-5064: --- Integrated in HBase-0.94 #146 (See [https://builds.apache.org/job/HBase-0.94/146/]) HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064 (Revision 1330071) Result = FAILURE jmhsieh : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java > utilize surefire tests parallelization > -- > > Key: HBASE-5064 > URL: https://issues.apache.org/jira/browse/HBASE-5064 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.94.0 >Reporter: nkeywal >Assignee: nkeywal > Fix For: 0.94.0 > > Attachments: 5064.addendum, 5064.patch, 5064.patch, 5064.v10.patch, > 5064.v11.patch, 5064.v12.patch, 5064.v13.patch, 5064.v14.patch, > 5064.v14.patch, 5064.v15.patch, 5064.v16.patch, 5064.v17.patch, > 5064.v18.patch, 5064.v18.patch, 5064.v19.patch, 5064.v19.patch, > 5064.v19.patch, 5064.v2.patch, 5064.v20.patch, 5064.v3.patch, 5064.v4.patch, > 5064.v5.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, > 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, > 5064.v8.patch, 5064.v8.patch, 5064.v9.patch > > > To be tried multiple times on hadoop-qa before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-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:comment-tabpanel&focusedCommentId=13261227#comment-13261227 ] Hudson commented on HBASE-5833: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5833 0.92 build has been failing pretty consistently on TestMasterFailover (Revision 1329418) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/metrics/histogram/ExponentiallyDecayingSample.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/JVMClusterUtil.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/filter/TestColumnPrefixFilter.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestOpenedRegionHandler.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestBlocksRead.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestColumnSeeking.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompactSelection.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionOnCluster.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestMinVersions.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestResettingCounters.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransaction.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/handler/TestCloseRegionHandler.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/handler/TestOpenRegionHandler.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestMergeTool.java > 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.90.7, 0.92.2, 0.94.0 > > Attachments: 5833-trunk.txt, 5833-v2.092.txt, 5833.txt, > 5833v3092.txt, 5833v4090.txt, 5833v4092.txt, 5833v4trunk.txt, 5833v5094.txt, > 5833v5trunk.txt, closehregions.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] [Commented] (HBASE-5861) Hadoop 23 compile broken due to tests introduced in HBASE-5064
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261230#comment-13261230
]
Hudson commented on HBASE-5861:
---
Integrated in HBase-0.94 #146 (See
[https://builds.apache.org/job/HBase-0.94/146/])
HBASE-5861 ADDENDUM (missed new MapredcueTestingShim.java file) (Revision
1330077)
HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064
(Revision 1330071)
Result = FAILURE
jmhsieh :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java
jmhsieh :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java
> Hadoop 23 compile broken due to tests introduced in HBASE-5064
> ---
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4393) Implement a canary monitoring program
[ https://issues.apache.org/jira/browse/HBASE-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261223#comment-13261223 ] Hudson commented on HBASE-4393: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-4393 Implement a canary monitoring program (Revision 1329575) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/tools * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/tools/Canary.java > Implement a canary monitoring program > - > > Key: HBASE-4393 > URL: https://issues.apache.org/jira/browse/HBASE-4393 > Project: HBase > Issue Type: New Feature > Components: monitoring >Affects Versions: 0.92.0 >Reporter: Todd Lipcon >Assignee: Matteo Bertozzi > Fix For: 0.94.0, 0.96.0 > > Attachments: Canary-v0.java, HBASE-4393-v0.patch, HBaseCanary.java > > > This JIRA is to implement a standalone program that can be used to do "canary > monitoring" of a running HBase cluster. This program would gather a list of > the regions in the cluster, then iterate over them doing lightweight > operations (eg short scans) to provide metrics about latency as well as alert > on availability issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5856) byte <-> String is not consistent between HBaseAdmin and HRegionInfo
[
https://issues.apache.org/jira/browse/HBASE-5856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261229#comment-13261229
]
binlijin commented on HBASE-5856:
-
@stack
We can get the
string(testsplit,\x00\x00\x00\x00\x00\x00\x00\x00,1335169851181.79d80fbc6c4f6cfc2cdca8a5310b7223.
) from the web (/table.jsp) or HRegionInfo.getRegionNameAsString(), if we pass
the string to web or jruby shell or HBaseAdmin.split(String) will get
TableNotFoundException.
> byte <-> String is not consistent between HBaseAdmin and HRegionInfo
>
>
> Key: HBASE-5856
> URL: https://issues.apache.org/jira/browse/HBASE-5856
> Project: HBase
> Issue Type: Bug
> Components: client
>Affects Versions: 0.90.6, 0.92.1
>Reporter: binlijin
> Attachments: HBASE-5856-0.92.patch
>
>
> In HBaseAdmin
> public void split(final String tableNameOrRegionName)
> throws IOException, InterruptedException {
> split(Bytes.toBytes(tableNameOrRegionName)); // string -> byte
> }
> In HRegionInfo
> this.regionNameStr = Bytes.toStringBinary(this.regionName); // byte ->
> string
> Should we use Bytes.toBytesBinary in HBaseAdmin ？
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261224#comment-13261224 ] Hudson commented on HBASE-5849: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5849 On first cluster startup, RS aborts if root znode is not available; REVERT (Revision 1329561) HBASE-5849 On first cluster startup, RS aborts if root znode is not available (Revision 1329528) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestClusterBootOrder.java stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestClusterBootOrder.java > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5865) test-util.sh broken with unittest updates
[ https://issues.apache.org/jira/browse/HBASE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261221#comment-13261221 ] Hudson commented on HBASE-5865: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5865 test-util.sh broken with unittest updates (Revision 1329903) Result = SUCCESS stack : Files : * /hbase/branches/0.94/dev-support/test-util.sh > test-util.sh broken with unittest updates > - > > Key: HBASE-5865 > URL: https://issues.apache.org/jira/browse/HBASE-5865 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.96.0, 0.94.1 >Reporter: Jesse Yates >Assignee: Jesse Yates >Priority: Minor > Fix For: 0.96.0, 0.94.1 > > Attachments: sh_HBASE-5865-v0.patch > > > Since the default maven test is meant to be run on the server, this test > script always fails. Needs to take into account the location of where the > script is being run as well as some debugging options for future fixes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5857) RIT map in RS not getting cleared while region opening
[
https://issues.apache.org/jira/browse/HBASE-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261226#comment-13261226
]
Hudson commented on HBASE-5857:
---
Integrated in HBase-0.94-security #20 (See
[https://builds.apache.org/job/HBase-0.94-security/20/])
HBASE-5857 RIT map in RS not getting cleared while region opening (Revision
1329471)
Result = SUCCESS
stack :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestZKBasedOpenCloseRegion.java
> RIT map in RS not getting cleared while region opening
> --
>
> Key: HBASE-5857
> URL: https://issues.apache.org/jira/browse/HBASE-5857
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.90.6
>Reporter: Chinna Rao Lalam
>Assignee: Chinna Rao Lalam
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
> Attachments: HBASE-5857_0.92.1.patch, HBASE-5857_0.92.patch,
> HBASE-5857_0.94.1.patch, HBASE-5857_94.patch, HBASE-5857_trunk.1.patch,
> HBASE-5857_trunk.1.patch, HBASE-5857_trunk.2.patch, HBASE-5857_trunk.patch
>
>
> While opening the region in RS after adding the region to
> regionsInTransitionInRS if tableDescriptors.get() throws exception the region
> wont be cleared from regionsInTransitionInRS. So next time if it tries to
> open the region in the same RS it will throw the
> RegionAlreadyInTransitionException.
> if swap the below statement this issue wont come.
> {code}
> this.regionsInTransitionInRS.putIfAbsent(region.getEncodedNameAsBytes(),true);
> HTableDescriptor htd = this.tableDescriptors.get(region.getTableName());
> {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] [Commented] (HBASE-5866) Canary in tool package but says its in tools.
[ https://issues.apache.org/jira/browse/HBASE-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261220#comment-13261220 ] Hudson commented on HBASE-5866: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5866 Canary in tool package but says its in tools (Revision 1329900) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/tool * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/tool/Canary.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/tools > Canary in tool package but says its in tools. > - > > Key: HBASE-5866 > URL: https://issues.apache.org/jira/browse/HBASE-5866 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 0.94.0, 0.96.0 > > Attachments: 5866.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] [Commented] (HBASE-5863) Improve the graceful_stop.sh CLI help (especially about reloads)
[
https://issues.apache.org/jira/browse/HBASE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261222#comment-13261222
]
Hudson commented on HBASE-5863:
---
Integrated in HBase-0.94-security #20 (See
[https://builds.apache.org/job/HBase-0.94-security/20/])
HBASE-5863 Improve the graceful_stop.sh CLI help (especially about reloads)
(Revision 1329794)
Result = SUCCESS
stack :
Files :
* /hbase/branches/0.94/bin/graceful_stop.sh
> Improve the graceful_stop.sh CLI help (especially about reloads)
>
>
> Key: HBASE-5863
> URL: https://issues.apache.org/jira/browse/HBASE-5863
> Project: HBase
> Issue Type: Improvement
> Components: scripts
>Affects Versions: 0.94.0
>Reporter: Harsh J
>Assignee: Harsh J
>Priority: Minor
> Fix For: 0.92.2, 0.94.1
>
> Attachments: HBASE-5863.patch
>
>
> Right now, graceful_stop.sh prints:
> {code}
> Usage: graceful_stop.sh [--config ] [--restart] [--reload]
> [--thrift] [--rest]
> thrift If we should stop/start thrift before/after the hbase stop/start
> restIf we should stop/start rest before/after the hbase stop/start
> restart If we should restart after graceful stop
> reload Move offloaded regions back on to the stopped server
> debug Move offloaded regions back on to the stopped server
> hostnameHostname of server we are to stop
> {code}
> This does not help us specify that "reload" is actually a sub/additive-option
> to "restart".
> Also, the "debug" line seems to still have an old copy/paste mistake.
> I've updated these two in the patch here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261225#comment-13261225 ] Hudson commented on HBASE-5848: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5848 Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort (Ram) (Revision 1329827) Result = SUCCESS ramkrishna : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, > HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5836) Backport per region metrics from HBASE-3614 to 0.94.1
[ https://issues.apache.org/jira/browse/HBASE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261218#comment-13261218 ] Hudson commented on HBASE-5836: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5836 Backport per region metrics from HBASE-3614 to 0.94.1 (Revision 1329958) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/OperationMetrics.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionMetricsStorage.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerDynamicMetrics.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java > Backport per region metrics from HBASE-3614 to 0.94.1 > - > > Key: HBASE-5836 > URL: https://issues.apache.org/jira/browse/HBASE-5836 > Project: HBase > Issue Type: Task >Affects Versions: 0.94.1 >Reporter: stack >Assignee: Elliott Clark > Fix For: 0.94.1 > > Attachments: HBASE-5836-0.patch > > > This would be good to have in 0.94. Can go into 0.94.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] [Commented] (HBASE-3614) Expose per-region request rate metrics
[ https://issues.apache.org/jira/browse/HBASE-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261219#comment-13261219 ] Hudson commented on HBASE-3614: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5836 Backport per region metrics from HBASE-3614 to 0.94.1 (Revision 1329958) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/OperationMetrics.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionMetricsStorage.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerDynamicMetrics.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java > Expose per-region request rate metrics > -- > > Key: HBASE-3614 > URL: https://issues.apache.org/jira/browse/HBASE-3614 > Project: HBase > Issue Type: Improvement > Components: metrics, regionserver >Reporter: Gary Helmling >Assignee: Elliott Clark >Priority: Minor > Fix For: 0.96.0 > > Attachments: HBASE-3614-0.patch, HBASE-3614-1.patch, > HBASE-3614-2.patch, HBASE-3614-3.patch, HBASE-3614-4.patch, > HBASE-3614-5.patch, HBASE-3614-6.patch, HBASE-3614-7.patch, > HBASE-3614-8.patch, HBASE-3614-9.patch, Screen Shot 2012-04-17 at 2.41.27 > PM.png > > > We currently export metrics on request rates for each region server, and this > can help with identifying uneven load at a high level. But once you see a > given server under high load, you're forced to extrapolate based on your > application patterns and the data it's serving what the likely culprit is. > This can and should be much easier if we just exported request rate metrics > per-region on each server. > Dynamically updating the metrics keys based on assigned regions may pose some > minor challenges, but this seems a very valuable diagnostic tool to have > available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5861) Hadoop 23 compile broken due to tests introduced in HBASE-5064
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261216#comment-13261216
]
Hudson commented on HBASE-5861:
---
Integrated in HBase-0.94-security #20 (See
[https://builds.apache.org/job/HBase-0.94-security/20/])
HBASE-5861 ADDENDUM (missed new MapredcueTestingShim.java file) (Revision
1330077)
HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064
(Revision 1330071)
Result = SUCCESS
jmhsieh :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/MapreduceTestingShim.java
jmhsieh :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java
> Hadoop 23 compile broken due to tests introduced in HBASE-5064
> ---
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5064) utilize surefire tests parallelization
[ https://issues.apache.org/jira/browse/HBASE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261217#comment-13261217 ] Hudson commented on HBASE-5064: --- Integrated in HBase-0.94-security #20 (See [https://builds.apache.org/job/HBase-0.94-security/20/]) HBASE-5861 Hadoop 23 compile broken due to tests introduced in HBASE-5064 (Revision 1330071) Result = SUCCESS jmhsieh : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java > utilize surefire tests parallelization > -- > > Key: HBASE-5064 > URL: https://issues.apache.org/jira/browse/HBASE-5064 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.94.0 >Reporter: nkeywal >Assignee: nkeywal > Fix For: 0.94.0 > > Attachments: 5064.addendum, 5064.patch, 5064.patch, 5064.v10.patch, > 5064.v11.patch, 5064.v12.patch, 5064.v13.patch, 5064.v14.patch, > 5064.v14.patch, 5064.v15.patch, 5064.v16.patch, 5064.v17.patch, > 5064.v18.patch, 5064.v18.patch, 5064.v19.patch, 5064.v19.patch, > 5064.v19.patch, 5064.v2.patch, 5064.v20.patch, 5064.v3.patch, 5064.v4.patch, > 5064.v5.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, 5064.v6.patch, > 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, 5064.v7.patch, > 5064.v8.patch, 5064.v8.patch, 5064.v9.patch > > > To be tried multiple times on hadoop-qa before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5635) If getTaskList() returns null, splitlogWorker would go down and it won't serve any requests
[
https://issues.apache.org/jira/browse/HBASE-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261215#comment-13261215
]
Hudson commented on HBASE-5635:
---
Integrated in HBase-0.94-security #20 (See
[https://builds.apache.org/job/HBase-0.94-security/20/])
HBASE-5635 If getTaskList() returns null, splitlogWorker would go down and
it won't serve any requests (Chinna) (Revision 1329325)
Result = SUCCESS
ramkrishna :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/SplitLogWorker.java
> If getTaskList() returns null, splitlogWorker would go down and it won't
> serve any requests
> ---
>
> Key: HBASE-5635
> URL: https://issues.apache.org/jira/browse/HBASE-5635
> Project: HBase
> Issue Type: Bug
> Components: wal
>Affects Versions: 0.92.1
>Reporter: Kristam Subba Swathi
>Assignee: Chinna Rao Lalam
> Fix For: 0.94.0, 0.96.0
>
> Attachments: HBASE-5635.1.patch, HBASE-5635.2.patch,
> HBASE-5635._trunk.patch, HBASE-5635.patch, HBASE-5635_0.94.patch
>
>
> During the hlog split operation if all the zookeepers are down ,then the
> paths will be returned as null and the splitworker thread wil be exited
> Now this regionserver wil not be able to acquire any other tasks since the
> splitworker thread is exited
> Please find the attached code for more details
> {code}
> private List getTaskList() {
> for (int i = 0; i < zkretries; i++) {
> try {
> return (ZKUtil.listChildrenAndWatchForNewChildren(this.watcher,
> this.watcher.splitLogZNode));
> } catch (KeeperException e) {
> LOG.warn("Could not get children of znode " +
> this.watcher.splitLogZNode, e);
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e1) {
> LOG.warn("Interrupted while trying to get task list ...", e1);
> Thread.currentThread().interrupt();
> return null;
> }
> }
> }
> {code}
> in the org.apache.hadoop.hbase.regionserver.SplitLogWorker
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261213#comment-13261213 ] Zhihong Yu commented on HBASE-5872: --- Actually https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK-on-Hadoop-23 is built daily. We just need to observe the compilation error there. > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261212#comment-13261212 ] Hadoop QA commented on HBASE-5872: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12524093/hbase-5872.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. -1 findbugs. The patch appears to introduce 5 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.hbase.TestRegionRebalancing org.apache.hadoop.hbase.replication.TestReplication Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1636//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1636//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1636//console This message is automatically generated. > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[
https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261210#comment-13261210
]
Zhihong Yu commented on HBASE-5872:
---
{code}
+ echo "$MVN clean test -DskipTests -D${PROJECT_NAME}PatchProcess >
$PATCH_DIR/trunkJavacWarnings.txt 2>&1"
{code}
I am confused by the above: if tests are skipped, why is test target specified ?
> Improve hadoopqa script to include checks for hadoop 0.23 build
> ---
>
> Key: HBASE-5872
> URL: https://issues.apache.org/jira/browse/HBASE-5872
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-5872.patch
>
>
> There have been a few patches that have made it into hbase trunk that have
> broken the compile of hbase against hadoop 0.23.x, without being known for a
> few days.
> We could have the bot do a few things:
> 1) verify that patch compiles against hadoop 23
> 2) verify that unit tests pass against hadoop 23
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-5849: - Status: Patch Available (was: Reopened) > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[ https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-5849: - Attachment: HBASE-5849_v4.patch Reattaching for Jenkins. > On first cluster startup, RS aborts if root znode is not available > -- > > Key: HBASE-5849 > URL: https://issues.apache.org/jira/browse/HBASE-5849 > Project: HBase > Issue Type: Bug > Components: master, regionserver, zookeeper >Affects Versions: 0.92.2, 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.92.2, 0.94.0 > > Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch, > HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch, > HBASE-5849_v4.patch > > > When launching a fresh new cluster, the master has to be started first, which > might create race conditions for starting master and rs at the same time. > Master startup code is smt like this: > - establish zk connection > - create root znodes in zk (/hbase) > - create ephemeral node for master /hbase/master, > Region server start up code is smt like this: > - establish zk connection > - check whether the root znode (/hbase) is there. If not, shutdown. > - wait for the master to create znodes /hbase/master > So, the problem is on the very first launch of the cluster, RS aborts to > start since /hbase znode might not have been created yet (only the master > creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on > subsequent cluster starts, it does not matter which order the servers are > started. So this affects only first launchs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5849) On first cluster startup, RS aborts if root znode is not available
[
https://issues.apache.org/jira/browse/HBASE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-5849:
-
Attachment: HBASE-5849_v4.patch
HBASE-5849_v4-0.92.patch
HBASE-5849_v4.patch
I have found 2 issues, that caused timeouts in 0.92 branch:
1. hbase dir was not setup to use the temp dir under target/, but used the
default one under /tmp/hadoop-${username}, so running the test on 0.92 causes
rs to not come up if you have dirty data under /tmp/.
2. giving timeouts like @Test(timeout=xxx) causes 0.92 master to not shutdown
properly. I could not inspect this further, there might be an issue with
surefire.
As a result, I updated the patch to first boot up a mini dfs, and setup the
hbase dir. And I also removed the timeouts (the test runner (maven) will
timeout instead if something goes wrong).
All my tests for trunk,0.94, and 0.92 seem to pass.
@Ted, @Stack, can you please try the patch to see whether you can replicate?
On an unrelated note, the ResourceChecker notifies that some of the daemon
threads (like LruBlockCache.EvictionThread) are not shutdown properly (even
when using MiniHBaseCluster, and shutting down properly). Any idea, whether we
should dig into that?
> On first cluster startup, RS aborts if root znode is not available
> --
>
> Key: HBASE-5849
> URL: https://issues.apache.org/jira/browse/HBASE-5849
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver, zookeeper
>Affects Versions: 0.92.2, 0.96.0, 0.94.1
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.92.2, 0.94.0
>
> Attachments: 5849v3.txt, HBASE-5849_v1.patch, HBASE-5849_v2.patch,
> HBASE-5849_v4-0.92.patch, HBASE-5849_v4.patch, HBASE-5849_v4.patch,
> HBASE-5849_v4.patch
>
>
> When launching a fresh new cluster, the master has to be started first, which
> might create race conditions for starting master and rs at the same time.
> Master startup code is smt like this:
> - establish zk connection
> - create root znodes in zk (/hbase)
> - create ephemeral node for master /hbase/master,
> Region server start up code is smt like this:
> - establish zk connection
> - check whether the root znode (/hbase) is there. If not, shutdown.
> - wait for the master to create znodes /hbase/master
> So, the problem is on the very first launch of the cluster, RS aborts to
> start since /hbase znode might not have been created yet (only the master
> creates it if needed). Since /hbase/ is not deleted on cluster shutdown, on
> subsequent cluster starts, it does not matter which order the servers are
> started. So this affects only first launchs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5104) Provide a reliable intra-row pagination mechanism
[
https://issues.apache.org/jira/browse/HBASE-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261198#comment-13261198
]
Phabricator commented on HBASE-5104:
mbautin has commented on the revision "[jira] [HBASE-5104] Provide a reliable
intra-row pagination mechanism".
All unit tests have passed. Could someone familiar with the protobuf stuff in
trunk please take a look and accept?
REVISION DETAIL
https://reviews.facebook.net/D2799
> Provide a reliable intra-row pagination mechanism
> -
>
> Key: HBASE-5104
> URL: https://issues.apache.org/jira/browse/HBASE-5104
> Project: HBase
> Issue Type: Bug
>Reporter: Kannan Muthukkaruppan
>Assignee: Madhuwanti Vaidya
> Attachments: D2799.1.patch, D2799.2.patch, D2799.3.patch,
> D2799.4.patch,
> jira-HBASE-5104-Provide-a-reliable-intra-row-paginat-2012-04-16_12_39_42.patch,
> testFilterList.rb
>
>
> Addendum:
> Doing pagination (retrieving at most "limit" number of KVs at a particular
> "offset") is currently supported via the ColumnPaginationFilter. However, it
> is not a very clean way of supporting pagination. Some of the problems with
> it are:
> * Normally, one would expect a query with (Filter(A) AND Filter(B)) to have
> same results as (query with Filter(A)) INTERSECT (query with Filter(B)). This
> is not the case for ColumnPaginationFilter as its internal state gets updated
> depending on whether or not Filter(A) returns TRUE/FALSE for a particular
> cell.
> * When this Filter is used in combination with other filters (e.g., doing AND
> with another filter using FilterList), the behavior of the query depends on
> the order of filters in the FilterList. This is not ideal.
> * ColumnPaginationFilter is a stateful filter which ends up counting multiple
> versions of the cell as separate values even if another filter upstream or
> the ScanQueryMatcher is going to reject the value for other reasons.
> Seems like we need a reliable way to do pagination. The particular use case
> that prompted this JIRA is pagination within the same rowKey. For example,
> for a given row key R, get columns with prefix P, starting at offset X (among
> columns which have prefix P) and limit Y. Some possible fixes might be:
> 1) enhance ColumnPrefixFilter to support another constructor which supports
> limit/offset.
> 2) Support pagination (limit/offset) at the Scan/Get API level (rather than
> as a filter) [Like SQL].
> Original Post:
> Thanks Jiakai Liu for reporting this issue and doing the initial
> investigation. Email from Jiakai below:
> Assuming that we have an index column family with the following entries:
> "tag0:001:thread1"
> ...
> "tag1:001:thread1"
> "tag1:002:thread2"
> ...
> "tag1:010:thread10"
> ...
> "tag2:001:thread1"
> "tag2:005:thread5"
> ...
> To get threads with "tag1" in range [5, 10), I tried the following code:
> ColumnPrefixFilter filter1 = new
> ColumnPrefixFilter(Bytes.toBytes("tag1"));
> ColumnPaginationFilter filter2 = new ColumnPaginationFilter(5 /* limit
> */, 5 /* offset */);
> FilterList filters = new FilterList(Operator.MUST_PASS_ALL);
> filters.addFilter(filter1);
> filters.addFilter(filter2);
> Get get = new Get(USER);
> get.addFamily(COLUMN_FAMILY);
> get.setMaxVersions(1);
> get.setFilter(filters);
> Somehow it didn't work as expected. It returned the entries as if the filter1
> were not set.
> Turns out the ColumnPrefixFilter returns SEEK_NEXT_USING_HINT in some cases.
> The FilterList filter does not handle this return code properly (treat it as
> INCLUDE).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5862) After Region Close remove the Operation Metrics.
[ https://issues.apache.org/jira/browse/HBASE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261196#comment-13261196 ] Elliott Clark commented on HBASE-5862: -- I can write a more comprehensive test but that would require changing several fields to be more accessible. Not sure what the general thought was on that. > After Region Close remove the Operation Metrics. > > > Key: HBASE-5862 > URL: https://issues.apache.org/jira/browse/HBASE-5862 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Minor > Attachments: HBASE-5862-0.patch, HBASE-5862-1.patch, > HBASE-5862-2.patch, HBASE-5862-3.patch > > > If a region is closed then Hadoop metrics shouldn't still be reporting about > that region. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261194#comment-13261194 ] Lars Hofhansl commented on HBASE-5848: -- Will wait for HadoopQA, and commit if all is good. > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, > HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5862) After Region Close remove the Operation Metrics.
[ https://issues.apache.org/jira/browse/HBASE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-5862: - Attachment: HBASE-5862-3.patch > After Region Close remove the Operation Metrics. > > > Key: HBASE-5862 > URL: https://issues.apache.org/jira/browse/HBASE-5862 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Minor > Attachments: HBASE-5862-0.patch, HBASE-5862-1.patch, > HBASE-5862-2.patch, HBASE-5862-3.patch > > > If a region is closed then Hadoop metrics shouldn't still be reporting about > that region. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5861) Hadoop 23 compile broken due to tests introduced in HBASE-5064
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261195#comment-13261195
]
Jonathan Hsieh commented on HBASE-5861:
---
Oops. I've added an addendum.
> Hadoop 23 compile broken due to tests introduced in HBASE-5064
> ---
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5862) After Region Close remove the Operation Metrics.
[ https://issues.apache.org/jira/browse/HBASE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-5862: - Attachment: HBASE-5862-2.patch HRegionServer.dynamicMetrics registers it's self with the Hadoop Metrics. From then on the metrics are polled by a thread outside of hbase. We clear everything in order to clear schema metrics and metrics about cf's. It would be time consuming to iterate through all metrics and see if they are for column families that are still being served. Since the metrics are reset by jmx every time it comes through removing them is not great but saves a lot of string comparisons and ensures that all edge cases are covered. I added the bool to make sure that initializing is only tried once. Changed the or to a && since only clearing half doesn't get the job done so better not not try if one field was not accessible. > After Region Close remove the Operation Metrics. > > > Key: HBASE-5862 > URL: https://issues.apache.org/jira/browse/HBASE-5862 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Minor > Attachments: HBASE-5862-0.patch, HBASE-5862-1.patch, > HBASE-5862-2.patch > > > If a region is closed then Hadoop metrics shouldn't still be reporting about > that region. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5861) Hadoop 23 compile broken due to tests introduced in HBASE-5064
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261191#comment-13261191
]
Lars Hofhansl commented on HBASE-5861:
--
As Ted points out MapreduceTestingShim.java is missing :), build is broken
(0.94 and trunk)
> Hadoop 23 compile broken due to tests introduced in HBASE-5064
> ---
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261189#comment-13261189 ] Jonathan Hsieh commented on HBASE-5872: --- Also wondering if we should include the security profile for runs to verify patches don't break compiling them and that they execute the security related unit tests. > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-5872: -- Affects Version/s: 0.96.0 Status: Patch Available (was: Open) > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-5872: -- Attachment: hbase-5872.patch > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.96.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-5872.patch > > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261187#comment-13261187 ] Lars Hofhansl commented on HBASE-5848: -- :) Yes, was thinking that too. > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, > HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- 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-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
Jonathan Hsieh created HBASE-5872: - Summary: Improve hadoopqa script to include checks for hadoop 0.23 build Key: HBASE-5872 URL: https://issues.apache.org/jira/browse/HBASE-5872 Project: HBase Issue Type: New Feature Reporter: Jonathan Hsieh There have been a few patches that have made it into hbase trunk that have broken the compile of hbase against hadoop 0.23.x, without being known for a few days. We could have the bot do a few things: 1) verify that patch compiles against hadoop 23 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh reassigned HBASE-5872: - Assignee: Jonathan Hsieh > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5872) Improve hadoopqa script to include checks for hadoop 0.23 build
[ https://issues.apache.org/jira/browse/HBASE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261186#comment-13261186 ] Jonathan Hsieh commented on HBASE-5872: --- Since #2 can be time consuming, I'm thinking #1 may be sufficient. > Improve hadoopqa script to include checks for hadoop 0.23 build > --- > > Key: HBASE-5872 > URL: https://issues.apache.org/jira/browse/HBASE-5872 > Project: HBase > Issue Type: New Feature >Reporter: Jonathan Hsieh > > There have been a few patches that have made it into hbase trunk that have > broken the compile of hbase against hadoop 0.23.x, without being known for a > few days. > We could have the bot do a few things: > 1) verify that patch compiles against hadoop 23 > 2) verify that unit tests pass against hadoop 23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5871) Usability regression, we don't parse compression algos anymore
[
https://issues.apache.org/jira/browse/HBASE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261185#comment-13261185
]
Jean-Daniel Cryans commented on HBASE-5871:
---
No.
> Usability regression, we don't parse compression algos anymore
> --
>
> Key: HBASE-5871
> URL: https://issues.apache.org/jira/browse/HBASE-5871
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.1
>Reporter: Jean-Daniel Cryans
>Priority: Critical
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
>
> It seems that string with 0.92.0 we can't create tables in the shell by
> specifying "lzo" anymore. I remember we used to do better parsing than that,
> but right now if you follow the wiki doing this:
> bq. create 'mytable', {NAME=>'colfam:', COMPRESSION=>'lzo'}
> You'll get:
> bq. ERROR: java.lang.IllegalArgumentException: No enum const class
> org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.lzo
> Bad for usability.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5864) Error while reading from hfile in 0.94
[
https://issues.apache.org/jira/browse/HBASE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261183#comment-13261183
]
Lars Hofhansl commented on HBASE-5864:
--
Dhruba should have a look this too.
> Error while reading from hfile in 0.94
> --
>
> Key: HBASE-5864
> URL: https://issues.apache.org/jira/browse/HBASE-5864
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.94.0
>Reporter: Gopinathan A
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.94.0
>
> Attachments: HBASE-5864_1.patch, HBASE-5864_2.patch,
> HBASE-5864_test.patch
>
>
> Got the following stacktrace during region split.
> {noformat}
> 2012-04-24 16:05:42,168 WARN org.apache.hadoop.hbase.regionserver.Store:
> Failed getting store size for value
> java.io.IOException: Requested block is out of range: 2906737606134037404,
> lastDataBlockOffset: 84764558
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:278)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.midkey(HFileBlockIndex.java:285)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.midkey(HFileReaderV2.java:402)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Reader.midkey(StoreFile.java:1638)
> at
> org.apache.hadoop.hbase.regionserver.Store.getSplitPoint(Store.java:1943)
> at
> org.apache.hadoop.hbase.regionserver.RegionSplitPolicy.getSplitPoint(RegionSplitPolicy.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkSplit(HRegion.java:4921)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.splitRegion(HRegionServer.java:2901)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5853) java.lang.RuntimeException: readObject can't find class org.apache.hadoop.hdfs.protocol.HdfsFileStatus
[ https://issues.apache.org/jira/browse/HBASE-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261181#comment-13261181 ] Lars Hofhansl commented on HBASE-5853: -- I agree that looks like a setup problem, rather than an HBase problem. > java.lang.RuntimeException: readObject can't find class > org.apache.hadoop.hdfs.protocol.HdfsFileStatus > -- > > Key: HBASE-5853 > URL: https://issues.apache.org/jira/browse/HBASE-5853 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.92.1 > Environment: hadoop-0.23.1 hbase-0.92.1 >Reporter: jiafeng.zhang > Fix For: 0.92.1, 0.94.0 > > > 2012-04-23 12:51:07,474 WARN org.apache.hadoop.ipc.Client: Unexpected error > reading responses on connection Thread[IPC Client (1260987126) connection to > server121/172.16.40.121:9000 from smp,5,main] > java.lang.RuntimeException: readObject can't find class > org.apache.hadoop.hdfs.protocol.HdfsFileStatus > at > org.apache.hadoop.io.ObjectWritable.loadClass(ObjectWritable.java:372) > at > org.apache.hadoop.io.ObjectWritable.readObject(ObjectWritable.java:223) > at > org.apache.hadoop.io.ObjectWritable.readFields(ObjectWritable.java:75) > at > org.apache.hadoop.ipc.Client$Connection.receiveResponse(Client.java:832) > at org.apache.hadoop.ipc.Client$Connection.run(Client.java:756) > Caused by: java.lang.ClassNotFoundException: Class > org.apache.hadoop.hdfs.protocol.HdfsFileStatus not found > at > org.apache.hadoop.conf.Configuration.getClassByName(Configuration.java:1151) > at > org.apache.hadoop.io.ObjectWritable.loadClass(ObjectWritable.java:368) > ... 4 more > 2012-04-23 12:51:07,797 FATAL > org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server > server124,60020,1335152900476: Replay of HLog required. Forcing server > shutdown > org.apache.hadoop.hbase.DroppedSnapshotException: region: > hbase_cdr,e0072b2b-5e19-431f-bb69-a6427765eac4,1334902272934.8365a7cbf90dd558f297d70224113c8a. > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1278) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1162) > at > org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1104) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:400) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushOneForGlobalPressure(MemStoreFlusher.java:202) > at > org.apache.hadoop.hbase.regionserver.MemStoreFlusher.run(MemStoreFlusher.java:223) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.io.IOException: Failed on local exception: > java.io.IOException: Error reading responses; Host Details : local host is: > "server124/172.16.40.124"; destination host is: ""server121":9000; > at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:724) > at org.apache.hadoop.ipc.Client.call(Client.java:1094) > at > org.apache.hadoop.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:193) > at $Proxy10.getFileInfo(Unknown Source) > at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:100) > at > org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:65) > at $Proxy10.getFileInfo(Unknown Source) > at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1172) > at > org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:725) > at > org.apache.hadoop.hbase.regionserver.StoreFile.computeHDFSBlockDistribution(StoreFile.java:449) > at > org.apache.hadoop.hbase.regionserver.StoreFile.open(StoreFile.java:473) > at > org.apache.hadoop.hbase.regionserver.StoreFile.createReader(StoreFile.java:548) > at > org.apache.hadoop.hbase.regionserver.Store.internalFlushCache(Store.java:595) > at org.apache.hadoop.hbase.regionserver.Store.flushCache(Store.java:506) > at org.apache.hadoop.hbase.regionserver.Store.access$100(Store.java:89) > at > org.apache.hadoop.hbase.regionserver.Store$StoreFlusherImpl.flushCache(Store.java:1905) > at > org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:1254) > ... 6 more > Caused by: java.io.IOException: Error reading responses > at org.apache.hadoop.ipc.Client$Connection.
[jira] [Commented] (HBASE-5871) Usability regression, we don't parse compression algos anymore
[
https://issues.apache.org/jira/browse/HBASE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261180#comment-13261180
]
Lars Hofhansl commented on HBASE-5871:
--
Use LZO? I think you always had to match the case, no?
> Usability regression, we don't parse compression algos anymore
> --
>
> Key: HBASE-5871
> URL: https://issues.apache.org/jira/browse/HBASE-5871
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.1
>Reporter: Jean-Daniel Cryans
>Priority: Critical
> Fix For: 0.92.2, 0.94.0, 0.96.0
>
>
> It seems that string with 0.92.0 we can't create tables in the shell by
> specifying "lzo" anymore. I remember we used to do better parsing than that,
> but right now if you follow the wiki doing this:
> bq. create 'mytable', {NAME=>'colfam:', COMPRESSION=>'lzo'}
> You'll get:
> bq. ERROR: java.lang.IllegalArgumentException: No enum const class
> org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.lzo
> Bad for usability.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5848) Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to abort
[ https://issues.apache.org/jira/browse/HBASE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261182#comment-13261182 ] Zhihong Yu commented on HBASE-5848: --- Addendum v6 looks good. BTW this is the highest numbered addendum I have ever worked with :-) > Create table with EMPTY_START_ROW passed as splitKey causes the HMaster to > abort > > > Key: HBASE-5848 > URL: https://issues.apache.org/jira/browse/HBASE-5848 > Project: HBase > Issue Type: Bug > Components: client >Reporter: Lars Hofhansl >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 0.94.0, 0.96.0 > > Attachments: 5848-addendum-v2.txt, 5848-addendum-v3.txt, > 5848-addendum-v4.txt, 5848-addendum-v5.txt, 5848-addendum-v6.txt, > HBASE-5848.patch, HBASE-5848.patch, HBASE-5848_0.94.patch, > HBASE-5848_addendum.patch > > > A coworker of mine just had this scenario. It does not make sense the > EMPTY_START_ROW as splitKey (since the region with the empty start key is > implicit), but it should not cause the HMaster to abort. > The abort happens because it tries to bulk assign the same region twice and > then runs into race conditions with ZK. > The same would (presumably) happen when two identical split keys are passed, > but the client blocks that. The simplest solution here is to also block > passed null or EMPTY_START_ROW as split key by the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5861) Hadoop 23 compile broken due to tests introduced in HBASE-5064
[
https://issues.apache.org/jira/browse/HBASE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261179#comment-13261179
]
Lars Hofhansl commented on HBASE-5861:
--
Awesome. Thanks Jon and Ted.
> Hadoop 23 compile broken due to tests introduced in HBASE-5064
> ---
>
> Key: HBASE-5861
> URL: https://issues.apache.org/jira/browse/HBASE-5861
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Blocker
> Fix For: 0.94.0, 0.96.0
>
> Attachments: 5861-v4.patch, 5861.txt, hbase-5861-jon.patch,
> hbase-5861-v2.patch, hbase-5861-v3.patch
>
>
> When attempting to compile HBase 0.94rc1 against hadoop 23, I got this set of
> compilation error messages:
> {code}
> jon@swoop:~/proj/hbase-0.94$ mvn clean test -Dhadoop.profile=23 -DskipTests
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18.926s
> [INFO] Finished at: Mon Apr 23 10:38:47 PDT 2012
> [INFO] Final Memory: 55M/555M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
> (default-testCompile) on project hbase: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[147,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[153,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[194,46]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[206,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[213,29]
> org.apache.hadoop.mapreduce.JobContext is abstract; cannot be instantiated
> [ERROR]
> [ERROR]
> /home/jon/proj/hbase-0.94/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHLogRecordReader.java:[226,29]
> org.apache.hadoop.mapreduce.TaskAttemptContext is abstract; cannot be
> instantiated
> [ERROR] -> [Help 1]
> {code}
> Upon further investigation this issue is due to code introduced in HBASE-5064
> and is also present in trunk.
--
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
