[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602085#comment-13602085 ] Lars Hofhansl commented on HBASE-8099: -- With that change you can also leave the initialization of queues where it was and remove the null check in the run() method, which is nicer I think... I.e. what leaves copyQueuesFromRSUsingMulti is a list of queues or an empty list (just as it is case for copyQueuesFromRS) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.94.7 Attachments: HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8099: - Fix Version/s: 0.98.0 0.95.0 ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8099: - Fix Version/s: (was: 0.94.7) 0.94.6 ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.94.6 Attachments: HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8099: - Attachment: 8099-example.txt Like this. ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8099-example.txt, HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[
https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602089#comment-13602089
]
Hadoop QA commented on HBASE-8099:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12573672/HBase-8099-trunk-v3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4811//console
This message is automatically generated.
ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues
if it failed to execute.
-
Key: HBASE-8099
URL: https://issues.apache.org/jira/browse/HBASE-8099
Project: HBase
Issue Type: Bug
Reporter: Lars Hofhansl
Assignee: Himanshu Vashishtha
Priority: Blocker
Fix For: 0.95.0, 0.98.0, 0.94.6
Attachments: 8099-example.txt, HBase-8099-94.patch,
HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch,
HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch
We just ran into an interesting scenario. We restarted a cluster that was
setup as a replication source.
The stop went cleanly.
Upon restart *all* regionservers aborted within a few seconds with variations
of these errors:
http://pastebin.com/3iQVuBqS
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[
https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602090#comment-13602090
]
Hadoop QA commented on HBASE-8099:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12573684/8099-example.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4812//console
This message is automatically generated.
ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues
if it failed to execute.
-
Key: HBASE-8099
URL: https://issues.apache.org/jira/browse/HBASE-8099
Project: HBase
Issue Type: Bug
Reporter: Lars Hofhansl
Assignee: Himanshu Vashishtha
Priority: Blocker
Fix For: 0.95.0, 0.98.0, 0.94.6
Attachments: 8099-example.txt, HBase-8099-94.patch,
HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch,
HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch
We just ran into an interesting scenario. We restarted a cluster that was
setup as a replication source.
The stop went cleanly.
Upon restart *all* regionservers aborted within a few seconds with variations
of these errors:
http://pastebin.com/3iQVuBqS
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[ https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-8101: - Status: Patch Available (was: Open) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc. - Key: HBASE-8101 URL: https://issues.apache.org/jira/browse/HBASE-8101 Project: HBase Issue Type: Sub-task Components: IPC/RPC Reporter: stack Fix For: 0.95.0 Attachments: 8101.txt Part of hbase-7900 broken out so that patch gets smaller. This is a patch with cleanup mostly findbugs fixes (general ones) as well as adding check for null row being passed to Put, Get, etc. This patch helps rpc along. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-8090: - Attachment: 8090.094.txt Some 0.94 changes. Just adding 0.94 to the documentation label in the navbar. Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Priority: Blocker Attachments: 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[
https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602102#comment-13602102
]
Hadoop QA commented on HBASE-8101:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12573668/8101.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 11 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4813//console
This message is automatically generated.
Cleanup: findbugs and javadoc warning fixes as well as making it illegal
passing null row to Put/Delete, etc.
-
Key: HBASE-8101
URL: https://issues.apache.org/jira/browse/HBASE-8101
Project: HBase
Issue Type: Sub-task
Components: IPC/RPC
Reporter: stack
Fix For: 0.95.0
Attachments: 8101.txt
Part of hbase-7900 broken out so that patch gets smaller. This is a patch
with cleanup mostly findbugs fixes (general ones) as well as adding check for
null row being passed to Put, Get, etc. This patch helps rpc along.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8066) Provide Admin.isTableAvailable() for a given table along with splitkeys
[ https://issues.apache.org/jira/browse/HBASE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602107#comment-13602107 ] Hudson commented on HBASE-8066: --- Integrated in HBase-TRUNK #3958 (See [https://builds.apache.org/job/HBase-TRUNK/3958/]) HBASE-8066 - Provide Admin.isTableAvailable() for a given table along with splitkeys (Ram) - addendum for javadoc warnings (Revision 1456316) Result = FAILURE ramkrishna : Files : * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java Provide Admin.isTableAvailable() for a given table along with splitkeys --- Key: HBASE-8066 URL: https://issues.apache.org/jira/browse/HBASE-8066 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.95.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Minor Fix For: 0.95.0, 0.98.0 Attachments: HBASE-8066_1.patch, HBASE-8066_addendum.patch, HBASE-8066.patch As part of HBASE-5583 if the master reboots during creation of table there is a chance that the table gets created with partial split keys. This api helps to check if the table was created with the required number of splitkeys. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7938) Add integration test for ImportTsv/LoadIncrementalHFiles workflow
[ https://issues.apache.org/jira/browse/HBASE-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602106#comment-13602106 ] stack commented on HBASE-7938: -- They your failures above Mr Nick? Add integration test for ImportTsv/LoadIncrementalHFiles workflow - Key: HBASE-7938 URL: https://issues.apache.org/jira/browse/HBASE-7938 Project: HBase Issue Type: Sub-task Components: mapreduce Reporter: Nick Dimiduk Assignee: Nick Dimiduk Fix For: 0.95.0, 0.98.0 Attachments: 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch, 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch We have existing unit tests for smoke-testing the packaged MR jobs, however they do not create a runtime environment that is true to running on a real MR cluster. This is particularly true in regard to classpaths (HBASE-7934) but also other static state (HBASE-4802). An integration test that can be pointed to run on a pseudo-distributed Hadoop deployed on localhost would find these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7938) Add integration test for ImportTsv/LoadIncrementalHFiles workflow
[ https://issues.apache.org/jira/browse/HBASE-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602110#comment-13602110 ] stack commented on HBASE-7938: -- Skimmed the patch. It looks excellent. Nice commit message. Use as release note? Add integration test for ImportTsv/LoadIncrementalHFiles workflow - Key: HBASE-7938 URL: https://issues.apache.org/jira/browse/HBASE-7938 Project: HBase Issue Type: Sub-task Components: mapreduce Reporter: Nick Dimiduk Assignee: Nick Dimiduk Fix For: 0.95.0, 0.98.0 Attachments: 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch, 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch We have existing unit tests for smoke-testing the packaged MR jobs, however they do not create a runtime environment that is true to running on a real MR cluster. This is particularly true in regard to classpaths (HBASE-7934) but also other static state (HBASE-4802). An integration test that can be pointed to run on a pseudo-distributed Hadoop deployed on localhost would find these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8066) Provide Admin.isTableAvailable() for a given table along with splitkeys
[ https://issues.apache.org/jira/browse/HBASE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602112#comment-13602112 ] Hudson commented on HBASE-8066: --- Integrated in hbase-0.95 #73 (See [https://builds.apache.org/job/hbase-0.95/73/]) HBASE-8066 - Provide Admin.isTableAvailable() for a given table along with splitkeys (Ram)-addendum to for javadoc warnings (Revision 1456315) Result = FAILURE ramkrishna : Files : * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java Provide Admin.isTableAvailable() for a given table along with splitkeys --- Key: HBASE-8066 URL: https://issues.apache.org/jira/browse/HBASE-8066 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.95.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Minor Fix For: 0.95.0, 0.98.0 Attachments: HBASE-8066_1.patch, HBASE-8066_addendum.patch, HBASE-8066.patch As part of HBASE-5583 if the master reboots during creation of table there is a chance that the table gets created with partial split keys. This api helps to check if the table was created with the required number of splitkeys. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-8090: - Attachment: 8080.trunk.txt What I applied for trunk. Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Priority: Blocker Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-8090. -- Resolution: Fixed Fix Version/s: 0.95.0 Assignee: stack Release Note: Added a '0.94 Documentation' to hbase.apache.org navbar. Points into reports, refguide, and apidocs generated out of 0.94 branch. Committed small changes to 0.94 and trunk. Updated site. Points at 0.94 docs now. Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.95.0 Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[ https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-8101: - Attachment: 8101v2.txt Rebase. HBaseAdmin changed under my patch. Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc. - Key: HBASE-8101 URL: https://issues.apache.org/jira/browse/HBASE-8101 Project: HBase Issue Type: Sub-task Components: IPC/RPC Reporter: stack Fix For: 0.95.0 Attachments: 8101.txt, 8101v2.txt Part of hbase-7900 broken out so that patch gets smaller. This is a patch with cleanup mostly findbugs fixes (general ones) as well as adding check for null row being passed to Put, Get, etc. This patch helps rpc along. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602125#comment-13602125 ] stack commented on HBASE-7876: -- [~ram_krish] A config. would be overkill. I'd say if a user wants to split a region, they should be able to. If you had one-to-one relationship indexing, then you probably didn't have users at shell or ui doing split? I'd say its good to go. [~maryannxue] Does it work for you? Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.5 Reporter: Maryann Xue Assignee: Maryann Xue Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (HBASE-7876) Got exception when manually triggers a split on an empty region
@stack, this patches works for me, I defined a custom split policy, and a empty region can be splitted successfully. On Sat, Mar 9, 2013 at 3:52 AM, stack (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597470#comment-13597470] stack commented on HBASE-7876: -- +1 on patch. Are you good with it [~ram_krish]? [~clockfly] Any chance of a test? Or at least evidence this works for you? Thanks. Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.5 Reporter: Maryann Xue Assignee: Maryann Xue Priority: Minor Attachments: HBASE-7876-0.94.patch, HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602132#comment-13602132 ] clockfly commented on HBASE-7876: - @stack, this patches works for me, I defined a custom split policy, and a empty region can be splitted successfully. Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.5 Reporter: Maryann Xue Assignee: Maryann Xue Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602135#comment-13602135 ] ramkrishna.s.vasudevan commented on HBASE-7876: --- Ok Stack. I am +1 on the patch. We can commit this. Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.5 Reporter: Maryann Xue Assignee: Maryann Xue Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602136#comment-13602136 ] Maryann Xue commented on HBASE-7876: @stack agree~ Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.5 Reporter: Maryann Xue Assignee: Maryann Xue Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[
https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602150#comment-13602150
]
Hadoop QA commented on HBASE-8101:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12573696/8101v2.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 11 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.constraint.TestConstraint
org.apache.hadoop.hbase.client.TestFromClientSideWithCoprocessor
org.apache.hadoop.hbase.client.TestFromClientSide
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4814//console
This message is automatically generated.
Cleanup: findbugs and javadoc warning fixes as well as making it illegal
passing null row to Put/Delete, etc.
-
Key: HBASE-8101
URL: https://issues.apache.org/jira/browse/HBASE-8101
Project: HBase
Issue Type: Sub-task
Components: IPC/RPC
Reporter: stack
Fix For: 0.95.0
Attachments: 8101.txt, 8101v2.txt
Part of hbase-7900 broken out so that patch gets smaller. This is a patch
with cleanup mostly findbugs fixes (general ones) as well as adding check for
null row being passed to Put, Get, etc. This patch helps rpc along.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602163#comment-13602163 ] Hudson commented on HBASE-8090: --- Integrated in HBase-0.94 #899 (See [https://builds.apache.org/job/HBase-0.94/899/]) HBASE-8090 Versioning site; part two, publish 0.94 site and add link from main site (Revision 1456357) HBASE-8090 Versioning site; part two, publish 0.94 site and add link from main site (Revision 1456356) Result = FAILURE stack : Files : * /hbase/branches/0.94/pom.xml stack : Files : * /hbase/branches/0.94/src/site/site.vm * /hbase/branches/0.94/src/site/site.xml Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.95.0 Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8103) Fix pom so 0.94 can generate site reports
[ https://issues.apache.org/jira/browse/HBASE-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602164#comment-13602164 ] Hudson commented on HBASE-8103: --- Integrated in HBase-0.94 #899 (See [https://builds.apache.org/job/HBase-0.94/899/]) HBASE-8103 Fix pom so 0.94 can generate site reports (Revision 1456335) Result = FAILURE stack : Files : * /hbase/branches/0.94/pom.xml Fix pom so 0.94 can generate site reports - Key: HBASE-8103 URL: https://issues.apache.org/jira/browse/HBASE-8103 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.94.6 Attachments: 8103.txt Site and info plugins are too old. The site plugin is in the wrong place. Can't generate reports w/o update and move of location. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8088) Versioning site: part one, put stake in the ground for 0.94 by copying current versions of book and site
[ https://issues.apache.org/jira/browse/HBASE-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602162#comment-13602162 ] Hudson commented on HBASE-8088: --- Integrated in HBase-0.94 #899 (See [https://builds.apache.org/job/HBase-0.94/899/]) HBASE-8088 Versioning site: part one, put stake in the ground for 0.94 by copying current versions of book and site; SVN ADD NEW FILES (Revision 1456334) Result = FAILURE stack : Files : * /hbase/branches/0.94/src/site/resources/images/big_h_logo.png * /hbase/branches/0.94/src/site/resources/images/big_h_logo.svg Versioning site: part one, put stake in the ground for 0.94 by copying current versions of book and site Key: HBASE-8088 URL: https://issues.apache.org/jira/browse/HBASE-8088 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Fix For: 0.94.6 Attachments: addendum.txt Doug Meil suggests its time we started versioning doc and site. First step is copying current version over to 0.94 so we have something to work against (site and book have only been kept up on trunk up to this). Let me do this much for now. Can figure how to do the rest later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[
https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602173#comment-13602173
]
nkeywal commented on HBASE-8101:
@Override
+ public int hashCode() {
+// TODO: This is wrong. Can't have two gets the same just because on same
row. But it
+// matches how equals works currently and gets rid of the findbugs warning.
+return this.getRow().hashCode();
+ }
= You shouldn't call hashCode on an array, you could call
java.util.Arrays.hashCode
+ public Increment(final byte [] row, final int offset, final int length) {
+if (row == null || length = 0 || length HConstants.MAX_ROW_LENGTH) {
throw new IllegalArgumentException(Row key is invalid);
}
= When it happens in production, I like to have the actual values (i.e. row=
offset= so on ;-)
+@edu.umd.cs.findbugs.annotations.SuppressWarnings(
+value=CN_IDIOM_NO_SUPER_CALL,
+justification=Its PITA calling the super.clone)
= There is a good reason for this warning: subclasses won't be able to call
super.clone themselves if we do that (the type will be wrong: the object.clone
creates the right object). As it's private (i.e. we don't offer a public API
that should be subclassed I guess it's acceptable. At the very least we should
put a warning in the justification.
+1 otherwise, thanks for doing this!
Cleanup: findbugs and javadoc warning fixes as well as making it illegal
passing null row to Put/Delete, etc.
-
Key: HBASE-8101
URL: https://issues.apache.org/jira/browse/HBASE-8101
Project: HBase
Issue Type: Sub-task
Components: IPC/RPC
Reporter: stack
Fix For: 0.95.0
Attachments: 8101.txt, 8101v2.txt
Part of hbase-7900 broken out so that patch gets smaller. This is a patch
with cleanup mostly findbugs fixes (general ones) as well as adding check for
null row being passed to Put, Get, etc. This patch helps rpc along.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602199#comment-13602199 ] Hudson commented on HBASE-8090: --- Integrated in HBase-TRUNK #3959 (See [https://builds.apache.org/job/HBase-TRUNK/3959/]) HBASE-8090 Versioning site; part two, publish 0.94 site and add link from main site (Revision 1456355) Result = FAILURE stack : Files : * /hbase/trunk/src/site/site.xml Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.95.0 Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8000) create integration/perf tests for stripe compactions
[ https://issues.apache.org/jira/browse/HBASE-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602240#comment-13602240 ] Jean-Marc Spaggiari commented on HBASE-8000: [~sershe] will it be possible to add the perf test in the existing class? Like adding it to PerformanceEvaluation or LoadTestTool? Also, will be good if this can be backport to a 0.94 release where the stripe compaction is not there, to compare the performances with and without the strip compaction activated. create integration/perf tests for stripe compactions Key: HBASE-8000 URL: https://issues.apache.org/jira/browse/HBASE-8000 Project: HBase Issue Type: Sub-task Components: Compaction Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin While writing tests I seem to be finding more errors with edge cases unrelated to what test actually tests compared to what is expected. Integration test will be needed... probably good for perf/compare too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8104) HBase consistency and availability after replication
Brian Fu created HBASE-8104: --- Summary: HBase consistency and availability after replication Key: HBASE-8104 URL: https://issues.apache.org/jira/browse/HBASE-8104 Project: HBase Issue Type: New Feature Affects Versions: 0.94.3 Reporter: Brian Fu Priority: Critical HBase consistency and availability after replication Scene as follows: 1. There are two HBase clusters are the Master clusters and Slave Clusters. two clusters replication function is open. 2. if master cluster have problems, so all write and read request switching to the slave cluster. 3. After a period of time ,we need to switch back to the Master cluster, there will be a part of the data is inconsistent, lead to this part of the data is not available. This feature is particularly important for providing online services HBase cluster. So, I want through a write-back program to keep the data consistency, then to improve HBase availability. we will provide a patch for this function. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8066) Provide Admin.isTableAvailable() for a given table along with splitkeys
[ https://issues.apache.org/jira/browse/HBASE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602252#comment-13602252 ] Hudson commented on HBASE-8066: --- Integrated in hbase-0.95-on-hadoop2 #26 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/26/]) HBASE-8066 - Provide Admin.isTableAvailable() for a given table along with splitkeys (Ram)-addendum to for javadoc warnings (Revision 1456315) Result = FAILURE ramkrishna : Files : * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java Provide Admin.isTableAvailable() for a given table along with splitkeys --- Key: HBASE-8066 URL: https://issues.apache.org/jira/browse/HBASE-8066 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.95.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Minor Fix For: 0.95.0, 0.98.0 Attachments: HBASE-8066_1.patch, HBASE-8066_addendum.patch, HBASE-8066.patch As part of HBASE-5583 if the master reboots during creation of table there is a chance that the table gets created with partial split keys. This api helps to check if the table was created with the required number of splitkeys. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8094) TestTableInputFormatScan doesn't assert anything
[
https://issues.apache.org/jira/browse/HBASE-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602253#comment-13602253
]
Hudson commented on HBASE-8094:
---
Integrated in hbase-0.95-on-hadoop2 #26 (See
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/26/])
HBASE-8094 TestTableInputFormatScan doesn't assert anything (Nick Dimiduk)
(Revision 1456286)
Result = FAILURE
enis :
Files :
*
/hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
TestTableInputFormatScan doesn't assert anything
Key: HBASE-8094
URL: https://issues.apache.org/jira/browse/HBASE-8094
Project: HBase
Issue Type: Sub-task
Components: mapreduce, test
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
Fix For: 0.95.0, 0.98.0
Attachments: 0001-HBASE-8094-fix-broken-TestTableInputFormatScan.patch
This test makes assertions from within the Reducer. These tests are not
respected because the control harness asserts only that jobs complete, not
that they succeed.
Verify this is true by adding a failure to the reducer:
{noformat}
$ git diff
diff --git
a/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
b/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
index bab9633..322cb4f 100644
---
a/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
+++
b/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
@@ -160,6 +160,7 @@ public class TestTableInputFormatScan {
if (lastRow != null lastRow.length() 0) {
assertEquals(lastRow, last);
}
+ assertTrue(false);
}
}
{noformat}
The test still passes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602255#comment-13602255 ] Hudson commented on HBASE-8090: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #447 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/447/]) HBASE-8090 Versioning site; part two, publish 0.94 site and add link from main site (Revision 1456355) Result = FAILURE stack : Files : * /hbase/trunk/src/site/site.xml Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.95.0 Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8094) TestTableInputFormatScan doesn't assert anything
[
https://issues.apache.org/jira/browse/HBASE-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602257#comment-13602257
]
Hudson commented on HBASE-8094:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #447 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/447/])
HBASE-8094 TestTableInputFormatScan doesn't assert anything (Nick Dimiduk)
(Revision 1456285)
Result = FAILURE
enis :
Files :
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
TestTableInputFormatScan doesn't assert anything
Key: HBASE-8094
URL: https://issues.apache.org/jira/browse/HBASE-8094
Project: HBase
Issue Type: Sub-task
Components: mapreduce, test
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
Fix For: 0.95.0, 0.98.0
Attachments: 0001-HBASE-8094-fix-broken-TestTableInputFormatScan.patch
This test makes assertions from within the Reducer. These tests are not
respected because the control harness asserts only that jobs complete, not
that they succeed.
Verify this is true by adding a failure to the reducer:
{noformat}
$ git diff
diff --git
a/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
b/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
index bab9633..322cb4f 100644
---
a/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
+++
b/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableInputFormatScan.java
@@ -160,6 +160,7 @@ public class TestTableInputFormatScan {
if (lastRow != null lastRow.length() 0) {
assertEquals(lastRow, last);
}
+ assertTrue(false);
}
}
{noformat}
The test still passes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8066) Provide Admin.isTableAvailable() for a given table along with splitkeys
[ https://issues.apache.org/jira/browse/HBASE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602256#comment-13602256 ] Hudson commented on HBASE-8066: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #447 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/447/]) HBASE-8066 - Provide Admin.isTableAvailable() for a given table along with splitkeys (Ram) - addendum for javadoc warnings (Revision 1456316) Result = FAILURE ramkrishna : Files : * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java Provide Admin.isTableAvailable() for a given table along with splitkeys --- Key: HBASE-8066 URL: https://issues.apache.org/jira/browse/HBASE-8066 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.95.0 Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Minor Fix For: 0.95.0, 0.98.0 Attachments: HBASE-8066_1.patch, HBASE-8066_addendum.patch, HBASE-8066.patch As part of HBASE-5583 if the master reboots during creation of table there is a chance that the table gets created with partial split keys. This api helps to check if the table was created with the required number of splitkeys. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602293#comment-13602293 ] Jean-Marc Spaggiari commented on HBASE-8025: Will it be possible also to add this as a parameter if we want to force a command to be server or client? zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.7 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602301#comment-13602301 ] Himanshu Vashishtha commented on HBASE-8099: Yeah agree, but then we are always instantiating a TreeMap irrespective of the outcome. ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8099-example.txt, HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602305#comment-13602305 ] nkeywal commented on HBASE-8025: Reading the patch, it seems ok to me. I will test it commit to trunk 0.95 tomorrow if there is no objection. Will wait for Lars for 0.94, but it seems it should be committed there as well. As well, Jean-Marc Dave, if you want to study it more (cf. suggestion above), I will wait for you. zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.7 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8017) Upgrade hadoop 1 dependency to 1.1.2
[ https://issues.apache.org/jira/browse/HBASE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602306#comment-13602306 ] Jean-Marc Spaggiari commented on HBASE-8017: I'm -1 to add this new dependency for 0.94 since many are running 0.94 on Hadoop 1.0.x. That will mean an hadoop upgrade for them, and I don't think it's a good idea for a minor release. However, I'm +1 to add this dependency for version 0.95 and more. Upgrade hadoop 1 dependency to 1.1.2 Key: HBASE-8017 URL: https://issues.apache.org/jira/browse/HBASE-8017 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.98.0 Attachments: 8017.txt, 8017.txt Hadoop 1.1.2 has been released. From Matt: This release includes 24 bug fixes and backward-compatible enhancements, compared to Hadoop 1.1.1. Improvements include: - bug fixes in use of Kerberos security and SPNEGO - a couple potential deadlock situations - fixes for IBM JDK compatibility - several unit test failure cleanups - other useful improvements For details, please see http://hadoop.apache.org/docs/r1.1.2/releasenotes.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602312#comment-13602312 ] Dave Latham commented on HBASE-8025: [~jmspaggi] I've got no objection to adding the extra parameter, though I'd prefer to just get zkcli fixed ASAP. If you've got a patch to add it, go for it - otherwise perhaps create a separate issue? zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.7 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602313#comment-13602313 ] Jean-Marc Spaggiari commented on HBASE-8025: [~davelatham] Sorry, I don't have a patch for that. Was just sharing ideas. I agree this should not stop your fix to be commited. Since you already have the hands in it, do you think it's something you can add in another jira? zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.7 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602317#comment-13602317 ] Dave Latham commented on HBASE-8025: To be honest, I haven't gone through the rest of these scripts to add new things to them - just enough to fix this targeted problem. zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.7 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8105) RegionServer Doesn't Rejoin Cluster after Netsplit
philo vivero created HBASE-8105: --- Summary: RegionServer Doesn't Rejoin Cluster after Netsplit Key: HBASE-8105 URL: https://issues.apache.org/jira/browse/HBASE-8105 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.1 Environment: Linux Ubuntu 10.04 LTS Reporter: philo vivero Running a 15-node HBase cluster. Testing various failure scenarios. Segregate one RegionServer from the cluster by firewalling off every port except SSH (because we need to be able to re-enable the node later). After the RS is automatically removed from the cluster, we re-enable all ports again, but RS never rejoins the cluster. I suspect the possibility this is desired behaviour, but haven't found proof so far. The code doesn't have any comment indicating this is the behaviour desired: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase/hbase/0.92.2/org/apache/hadoop/hbase/regionserver/HRegionServer.java/ See lines starting at 624, public void run(). It makes it through the first try/catch block, but then loops inside the second try/catch block. Our hypothesis is that it never gets out naturally. If we bounce the RegionServer process, then it rejoins the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8105) RegionServer Doesn't Rejoin Cluster after Netsplit
[ https://issues.apache.org/jira/browse/HBASE-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602324#comment-13602324 ] Jean-Marc Spaggiari commented on HBASE-8105: Is the RS still running when you re-open the ports? Since it losts the connection with ZooKeeper, it might have sent down already, no? RegionServer Doesn't Rejoin Cluster after Netsplit -- Key: HBASE-8105 URL: https://issues.apache.org/jira/browse/HBASE-8105 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.1 Environment: Linux Ubuntu 10.04 LTS Reporter: philo vivero Running a 15-node HBase cluster. Testing various failure scenarios. Segregate one RegionServer from the cluster by firewalling off every port except SSH (because we need to be able to re-enable the node later). After the RS is automatically removed from the cluster, we re-enable all ports again, but RS never rejoins the cluster. I suspect the possibility this is desired behaviour, but haven't found proof so far. The code doesn't have any comment indicating this is the behaviour desired: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase/hbase/0.92.2/org/apache/hadoop/hbase/regionserver/HRegionServer.java/ See lines starting at 624, public void run(). It makes it through the first try/catch block, but then loops inside the second try/catch block. Our hypothesis is that it never gets out naturally. If we bounce the RegionServer process, then it rejoins the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[ https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602329#comment-13602329 ] stack commented on HBASE-8101: -- [~nkeywal] Thanks for the very nice review. Let me address... Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc. - Key: HBASE-8101 URL: https://issues.apache.org/jira/browse/HBASE-8101 Project: HBase Issue Type: Sub-task Components: IPC/RPC Reporter: stack Fix For: 0.95.0 Attachments: 8101.txt, 8101v2.txt Part of hbase-7900 broken out so that patch gets smaller. This is a patch with cleanup mostly findbugs fixes (general ones) as well as adding check for null row being passed to Put, Get, etc. This patch helps rpc along. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8105) RegionServer Doesn't Rejoin Cluster after Netsplit
[ https://issues.apache.org/jira/browse/HBASE-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602334#comment-13602334 ] Time Less commented on HBASE-8105: -- The RS runs the whole time, so yes, still running when ports are re-opened. It definitely would lose its ZK connection. But then, I would expect when it begins communicating again with ZK, it would note its I've been ejected from the cluster status and rejoin, or RS process die, or something. RS process keeps running normally, but not part of the cluster seems an erroneous state. On Thu, Mar 14, 2013 at 8:06 AM, Jean-Marc Spaggiari (JIRA) j...@apache.org -- *Tim Ellis: *Fifth Sigma, Inc. Multimedia and Technology++ *Contact: *t...@fifthsigma.com, 510-761-6610 *Urgent Contact:* timeless.ph...@gmail.com (gtalk preferred. if email, CC no-one) RegionServer Doesn't Rejoin Cluster after Netsplit -- Key: HBASE-8105 URL: https://issues.apache.org/jira/browse/HBASE-8105 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.1 Environment: Linux Ubuntu 10.04 LTS Reporter: philo vivero Running a 15-node HBase cluster. Testing various failure scenarios. Segregate one RegionServer from the cluster by firewalling off every port except SSH (because we need to be able to re-enable the node later). After the RS is automatically removed from the cluster, we re-enable all ports again, but RS never rejoins the cluster. I suspect the possibility this is desired behaviour, but haven't found proof so far. The code doesn't have any comment indicating this is the behaviour desired: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase/hbase/0.92.2/org/apache/hadoop/hbase/regionserver/HRegionServer.java/ See lines starting at 624, public void run(). It makes it through the first try/catch block, but then loops inside the second try/catch block. Our hypothesis is that it never gets out naturally. If we bounce the RegionServer process, then it rejoins the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602348#comment-13602348 ] Lars Hofhansl commented on HBASE-8099: -- That's fine I think. It's only an empty map (a few dozen bytes), and it's only if there something to failover. It's just easier to read (IMHO) if you prefer the other approach that's fine. By the same logic we the Random could also be per failover worker, although the Random constructor does increment an AtomicLong. Let's get this in soon, so I can spin the next RC. ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8099-example.txt, HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8017) Upgrade hadoop 1 dependency to 1.1.2
[
https://issues.apache.org/jira/browse/HBASE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602351#comment-13602351
]
Lars Hofhansl commented on HBASE-8017:
--
I agree. It's not targeted to 0.94 anyway :)
In 0.94 we should only update the Hadoop 1.1 dependency (i.e. when you build
with {{mvn -Dhadoop.profile=1.1}} it should pull in 1.1.2 instead of 1.1.1).
The default in 0.94 would remain 1.0.4.
Upgrade hadoop 1 dependency to 1.1.2
Key: HBASE-8017
URL: https://issues.apache.org/jira/browse/HBASE-8017
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Fix For: 0.98.0
Attachments: 8017.txt, 8017.txt
Hadoop 1.1.2 has been released.
From Matt:
This release includes 24 bug fixes and backward-compatible enhancements,
compared to Hadoop 1.1.1. Improvements include:
- bug fixes in use of Kerberos security and SPNEGO
- a couple potential deadlock situations
- fixes for IBM JDK compatibility
- several unit test failure cleanups
- other useful improvements
For details, please see
http://hadoop.apache.org/docs/r1.1.2/releasenotes.html.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8105) RegionServer Doesn't Rejoin Cluster after Netsplit
[ https://issues.apache.org/jira/browse/HBASE-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602355#comment-13602355 ] nkeywal commented on HBASE-8105: I suppose you have a YouAreDeadException in the logs? This would be expected. The logic is that the region server cannot be trusted anymore as it was ejected from the cluster. Then yes, it could abort. On the other hand you may want to look at it in details. Personally I would prefer to abort to be sure I don't have clients trying to use this dead server. Note that for questions or discussions, it's better to use the user mailing list. RegionServer Doesn't Rejoin Cluster after Netsplit -- Key: HBASE-8105 URL: https://issues.apache.org/jira/browse/HBASE-8105 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.1 Environment: Linux Ubuntu 10.04 LTS Reporter: philo vivero Running a 15-node HBase cluster. Testing various failure scenarios. Segregate one RegionServer from the cluster by firewalling off every port except SSH (because we need to be able to re-enable the node later). After the RS is automatically removed from the cluster, we re-enable all ports again, but RS never rejoins the cluster. I suspect the possibility this is desired behaviour, but haven't found proof so far. The code doesn't have any comment indicating this is the behaviour desired: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase/hbase/0.92.2/org/apache/hadoop/hbase/regionserver/HRegionServer.java/ See lines starting at 624, public void run(). It makes it through the first try/catch block, but then loops inside the second try/catch block. Our hypothesis is that it never gets out naturally. If we bounce the RegionServer process, then it rejoins the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8090: - Fix Version/s: (was: 0.95.0) Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.98.0, 0.94.6 Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8090: - Fix Version/s: 0.94.6 0.98.0 Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8090) Versioning site; part two, publish 0.94 site and add link from main site
[ https://issues.apache.org/jira/browse/HBASE-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602363#comment-13602363 ] Lars Hofhansl commented on HBASE-8090: -- No 0.95 change needed for this, right? (Just 0.94 and trunk) Versioning site; part two, publish 0.94 site and add link from main site Key: HBASE-8090 URL: https://issues.apache.org/jira/browse/HBASE-8090 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.98.0, 0.94.6 Attachments: 8080.trunk.txt, 8090.094.txt Do the rest of site versioning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8104) HBase consistency and availability after replication
[ https://issues.apache.org/jira/browse/HBASE-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602365#comment-13602365 ] Lars Hofhansl commented on HBASE-8104: -- Can you setup the two clusters in Master-Master replication? That way all changes made the slave cluster during the failover are scheduled to be replicated back to the main cluster once that becomes available. HBase consistency and availability after replication Key: HBASE-8104 URL: https://issues.apache.org/jira/browse/HBASE-8104 Project: HBase Issue Type: New Feature Affects Versions: 0.94.3 Reporter: Brian Fu Priority: Critical Original Estimate: 336h Remaining Estimate: 336h HBase consistency and availability after replication Scene as follows: 1. There are two HBase clusters are the Master clusters and Slave Clusters. two clusters replication function is open. 2. if master cluster have problems, so all write and read request switching to the slave cluster. 3. After a period of time ,we need to switch back to the Master cluster, there will be a part of the data is inconsistent, lead to this part of the data is not available. This feature is particularly important for providing online services HBase cluster. So, I want through a write-back program to keep the data consistency, then to improve HBase availability. we will provide a patch for this function. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8025: - Fix Version/s: (was: 0.94.7) 0.94.6 zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602367#comment-13602367 ] Lars Hofhansl commented on HBASE-8025: -- +1 (including 0.94). Thanks Dave. Let's commit to 0.94 today (soon) so that this gets into the next 0.94.6 RC. zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8017) Upgrade hadoop 1 dependency to 1.1.2
[ https://issues.apache.org/jira/browse/HBASE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-8017: -- Attachment: (was: 8017.txt) Upgrade hadoop 1 dependency to 1.1.2 Key: HBASE-8017 URL: https://issues.apache.org/jira/browse/HBASE-8017 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.98.0 Attachments: 8017.txt, 8017.txt Hadoop 1.1.2 has been released. From Matt: This release includes 24 bug fixes and backward-compatible enhancements, compared to Hadoop 1.1.1. Improvements include: - bug fixes in use of Kerberos security and SPNEGO - a couple potential deadlock situations - fixes for IBM JDK compatibility - several unit test failure cleanups - other useful improvements For details, please see http://hadoop.apache.org/docs/r1.1.2/releasenotes.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8017) Upgrade hadoop 1 dependency to 1.1.2
[ https://issues.apache.org/jira/browse/HBASE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-8017: -- Attachment: 8017.txt Upgrade hadoop 1 dependency to 1.1.2 Key: HBASE-8017 URL: https://issues.apache.org/jira/browse/HBASE-8017 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.98.0 Attachments: 8017.txt, 8017.txt Hadoop 1.1.2 has been released. From Matt: This release includes 24 bug fixes and backward-compatible enhancements, compared to Hadoop 1.1.1. Improvements include: - bug fixes in use of Kerberos security and SPNEGO - a couple potential deadlock situations - fixes for IBM JDK compatibility - several unit test failure cleanups - other useful improvements For details, please see http://hadoop.apache.org/docs/r1.1.2/releasenotes.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Himanshu Vashishtha updated HBASE-8099: --- Attachment: HBase-8099-trunk-v4.patch HBase-8099-94-v4.patch with Lars' suggestions. ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8099-example.txt, HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-94-v4.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch, HBase-8099-trunk-v4.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602392#comment-13602392 ] Lars Hofhansl commented on HBASE-8099: -- +1 Going to commit in a bit unless there are objections. ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8099-example.txt, HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-94-v4.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch, HBase-8099-trunk-v4.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7233) Serializing KeyValues over RPC
[ https://issues.apache.org/jira/browse/HBASE-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602394#comment-13602394 ] ramkrishna.s.vasudevan commented on HBASE-7233: --- bq.Tags are a little different than our current fields because there are multiple per Cell The above comment is from Matt. So basically we say we will have multiple tags for a Cell. Which means cell which internally is now a represenation of a KV will have more than one additional attributes added to it (which is Tags) and one among them will be an ACL tag, visibility tag etc. So now how will we say which tag to see if i want to know only the Visibility part of the Cell? I could see an tagIterator() api added that iterates thro the tags, so is it like every time iterate to find out which is my Visisbility tag. Will there be a mechanism which says visibility tag should be the first tag or second .something like that? Serializing KeyValues over RPC -- Key: HBASE-7233 URL: https://issues.apache.org/jira/browse/HBASE-7233 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.95.0 Attachments: 7233sketch.txt, 7233.txt, 7233v10.txt, 7233-v2.txt, 7233v3_encoders.txt, 7233v4_encoders.txt, 7233v5_encoders.txt, 7233v6_encoder.txt, 7233v7.txt, 7233v9.txt Undo KeyValue being a Writable. This issue wandered and became general discussion of KeyValue serialization, in particular, how to pass lots of KeyValues across rpc. It was noticed that what we were passing over the wire for KeyValues was not protobuf'd KeyValues but the old serialization which assumes the KeyValue version 1 format. After a bunch of good discussion working out rpc formats, was decided to close this issue in favor of more specific issues: see summary at https://issues.apache.org/jira/browse/HBASE-7233?focusedCommentId=13573259page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13573259 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8044) split/flush/compact/major_compact from hbase shell does not work for region key with \x format
[ https://issues.apache.org/jira/browse/HBASE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602395#comment-13602395 ] Tianying Chang commented on HBASE-8044: --- hi, HBASE-8085 has been committed. Can we commit this one into 94 also? Thanks split/flush/compact/major_compact from hbase shell does not work for region key with \x format -- Key: HBASE-8044 URL: https://issues.apache.org/jira/browse/HBASE-8044 Project: HBase Issue Type: Bug Components: Admin Affects Versions: 0.94.5 Reporter: Tianying Chang Assignee: Tianying Chang Fix For: 0.95.0, 0.98.0, 0.94.7 Attachments: 8044.patch, 8044-trunk.txt, 8044-trunk-v2.txt, 8044-v2.patch the conversion between bytes and string is incorrect -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7897) Add support for tags to Cell Interface
[ https://issues.apache.org/jira/browse/HBASE-7897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602398#comment-13602398 ] ramkrishna.s.vasudevan commented on HBASE-7897: --- I posted the comment in HBASE-7233. Pasting the comment on this JIRA as this one is active bq.Tags are a little different than our current fields because there are multiple per Cell The above comment is from Matt. So basically we say we will have multiple tags for a Cell. Which means cell which internally is now a represenation of a KV will have more than one additional attributes added to it (which is Tags) and one among them will be an ACL tag, visibility tag etc. So now how will we say which tag to see if i want to know only the Visibility part of the Cell? I could see an tagIterator() api added that iterates thro the tags, so is it like every time iterate to find out which is my Visisbility tag. Will there be a mechanism which says visibility tag should be the first tag or second .something like that? Add support for tags to Cell Interface -- Key: HBASE-7897 URL: https://issues.apache.org/jira/browse/HBASE-7897 Project: HBase Issue Type: Task Reporter: stack Assignee: stack Priority: Critical Fix For: 0.95.0 Cell Interface has suppport for mvcc. The only thing we'd add to Cell in the near future is support for tags it would seem. Should be easy to add. Should add it now. See backing discussion here: https://issues.apache.org/jira/browse/HBASE-7233?focusedCommentId=13573784page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13573784 Matt outlines what the additions to Cell might look like here: https://issues.apache.org/jira/browse/HBASE-7233?focusedCommentId=13531619page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13531619 Would be good to get these in now. Marking as 0.96. Can more later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7985) TestMasterFailover.testMasterFailoverWithMockedRITOnDeadRS fails frequently in 0.94
[ https://issues.apache.org/jira/browse/HBASE-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7985: - Fix Version/s: (was: 0.94.7) TestMasterFailover.testMasterFailoverWithMockedRITOnDeadRS fails frequently in 0.94 --- Key: HBASE-7985 URL: https://issues.apache.org/jira/browse/HBASE-7985 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl 4 failures of this test in the last 6 builds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-7985) TestMasterFailover.testMasterFailoverWithMockedRITOnDeadRS fails frequently in 0.94
[ https://issues.apache.org/jira/browse/HBASE-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl resolved HBASE-7985. -- Resolution: Not A Problem This is no longer a problem with the changes in HBASE-7824 (was reverted and then fixed). Closing this. TestMasterFailover.testMasterFailoverWithMockedRITOnDeadRS fails frequently in 0.94 --- Key: HBASE-7985 URL: https://issues.apache.org/jira/browse/HBASE-7985 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl 4 failures of this test in the last 6 builds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7624) Backport HBASE-5359 and HBASE-7596 to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7624: - Fix Version/s: (was: 0.94.7) 0.94.6 Backport HBASE-5359 and HBASE-7596 to 0.94 -- Key: HBASE-7624 URL: https://issues.apache.org/jira/browse/HBASE-7624 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Jeffrey Zhong Fix For: 0.94.6 Attachments: hbase-7624_0.patch, hbase-7624_1.patch Both HBASE-5359 and HBASE-7596 are useful and should be added to 0.94. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-7624) Backport HBASE-5359 and HBASE-7596 to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl resolved HBASE-7624. -- Resolution: Fixed Hadoop Flags: Reviewed Backport HBASE-5359 and HBASE-7596 to 0.94 -- Key: HBASE-7624 URL: https://issues.apache.org/jira/browse/HBASE-7624 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Jeffrey Zhong Fix For: 0.94.6 Attachments: hbase-7624_0.patch, hbase-7624_1.patch Both HBASE-5359 and HBASE-7596 are useful and should be added to 0.94. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7824) Improve master start up time when there is log splitting work
[ https://issues.apache.org/jira/browse/HBASE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7824: - Fix Version/s: (was: 0.94.7) 0.94.6 Improve master start up time when there is log splitting work - Key: HBASE-7824 URL: https://issues.apache.org/jira/browse/HBASE-7824 Project: HBase Issue Type: Bug Components: master Reporter: Jeffrey Zhong Assignee: Jeffrey Zhong Fix For: 0.94.6 Attachments: HBASE-7824_3.patch, hbase-7824.patch, hbase-7824_v2.patch, hbase-7824_v3.patch When there is log split work going on, master start up waits till all log split work completes even though the log split has nothing to do with meta region servers. It's a bad behavior considering a master node can run when log split is happening while its start up is blocking by log split work. Since master is kind of single point of failure, we should start it ASAP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-7824) Improve master start up time when there is log splitting work
[ https://issues.apache.org/jira/browse/HBASE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl resolved HBASE-7824. -- Resolution: Fixed Improve master start up time when there is log splitting work - Key: HBASE-7824 URL: https://issues.apache.org/jira/browse/HBASE-7824 Project: HBase Issue Type: Bug Components: master Reporter: Jeffrey Zhong Assignee: Jeffrey Zhong Fix For: 0.94.6 Attachments: HBASE-7824_3.patch, hbase-7824.patch, hbase-7824_v2.patch, hbase-7824_v3.patch When there is log split work going on, master start up waits till all log split work completes even though the log split has nothing to do with meta region servers. It's a bad behavior considering a master node can run when log split is happening while its start up is blocking by log split work. Since master is kind of single point of failure, we should start it ASAP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8025: - Assignee: Dave Latham zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Assignee: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602403#comment-13602403 ] Lars Hofhansl commented on HBASE-8025: -- Going to commit in a bit. [~jesse_yates] can you have a look too? zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Assignee: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8099: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.94, 0.95, and 0.98. ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8099-example.txt, HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-94-v4.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch, HBase-8099-trunk-v4.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8044) split/flush/compact/major_compact from hbase shell does not work for region key with \x format
[ https://issues.apache.org/jira/browse/HBASE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602418#comment-13602418 ] Lars Hofhansl commented on HBASE-8044: -- I am still not sure this is right. If there's a problem with string parsing/escaping/etc in the shell it should be fixed there, not in the Java API that can deal with bytes. In fact, I think we should revert this from 0.95 and 0.98. split/flush/compact/major_compact from hbase shell does not work for region key with \x format -- Key: HBASE-8044 URL: https://issues.apache.org/jira/browse/HBASE-8044 Project: HBase Issue Type: Bug Components: Admin Affects Versions: 0.94.5 Reporter: Tianying Chang Assignee: Tianying Chang Fix For: 0.95.0, 0.98.0, 0.94.7 Attachments: 8044.patch, 8044-trunk.txt, 8044-trunk-v2.txt, 8044-v2.patch the conversion between bytes and string is incorrect -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602420#comment-13602420 ] Jesse Yates commented on HBASE-8025: I'm good with this. Alternative idea - we already have a case statement for each of these processes, so what about just adding the GC_OPTS to HBASE_OPTS in each case statement? Or each case statement sets HBASE_GC_OPTS=appropriate variable and then we tag it onto HBASE_OPTS at the end? Its a bit more code, but easier to change on a per process basis, as I could easily see other/new tools potentially wanting even different options. zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Assignee: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8106) Test to check replication log znodes move is done correctly
Himanshu Vashishtha created HBASE-8106: -- Summary: Test to check replication log znodes move is done correctly Key: HBASE-8106 URL: https://issues.apache.org/jira/browse/HBASE-8106 Project: HBase Issue Type: Test Components: Replication Affects Versions: 0.94.5 Reporter: Himanshu Vashishtha Fix For: 0.94.7 ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a regionserver failover environment. This jira is to add that the move is done correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602428#comment-13602428 ] Himanshu Vashishtha commented on HBASE-8106: I'll try to come up with a test case by today. Test to check replication log znodes move is done correctly --- Key: HBASE-8106 URL: https://issues.apache.org/jira/browse/HBASE-8106 Project: HBase Issue Type: Test Components: Replication Affects Versions: 0.94.5 Reporter: Himanshu Vashishtha Fix For: 0.94.7 ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a regionserver failover environment. This jira is to add that the move is done correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8107) Allow non-trunk patch to be tested by Hadoop QA
Ted Yu created HBASE-8107:
-
Summary: Allow non-trunk patch to be tested by Hadoop QA
Key: HBASE-8107
URL: https://issues.apache.org/jira/browse/HBASE-8107
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
If the contributor clicks 'Submit Patch' button for the backport patch, he /
she would get:
-1 patch. The patch command could not apply the patch.
I tried patch testing in 0.94 branch locally with the following command:
{code}
cd 94hbase
~/trunk/dev-support/test-patch.sh --jenkins --basedir=`pwd` HBASE-8085
{code}
I used test-patch.sh from trunk because it is up-to-date.
It seemed to work mostly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HBASE-7876: Assignee: stack (was: Maryann Xue) Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.5 Reporter: Maryann Xue Assignee: stack Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-7876: - Attachment: HBASE-7876-trunkv2.patch What I applied to trunk (patch rejected because of cleaned up white space done by previous patch) Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.5 Reporter: Maryann Xue Assignee: stack Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch, HBASE-7876-trunkv2.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8025: - Status: Open (was: Patch Available) zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Assignee: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8025-alt.txt, HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[ https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-8025: - Attachment: 8025-alt.txt I like that. Something like this? zkcli fails when SERVER_GC_OPTS is enabled -- Key: HBASE-8025 URL: https://issues.apache.org/jira/browse/HBASE-8025 Project: HBase Issue Type: Bug Affects Versions: 0.94.4 Reporter: Dave Latham Assignee: Dave Latham Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8025-alt.txt, HBASE-8025-0.94.patch HBASE-7091 added logic to separate GC logging options for some client commands versus server commands. It uses a list of known client commands (shell hbck hlog hfile zkcli) and uses the server GC logging options for all other invocations of bin/hbase. When zkcli is invoked, it in turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg to gather the server command line arguments, but because org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white list it enables server GC logging, which causes extra output that causes the zkcli invocation to break. HBASE-7153 addressed this but the fix only solved the array syntax - not the white list, so the zkcli command still fails. There are many other tools you can invoke that are more likely to client than server options. For example, bin/hbase org.jruby.Main region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable or bin/hbase version or bin/hbase org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands is shorter and easier to maintain than a whitelist of client commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-7876: - Affects Version/s: (was: 0.94.5) 0.95.0 Committed 0.95 and trunk. Lars, you want this? (Usability) Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.95.0 Reporter: Maryann Xue Assignee: stack Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch, HBASE-7876-trunkv2.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602446#comment-13602446 ] stack commented on HBASE-7876: -- [~lhofhansl] You want this? Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.95.0 Reporter: Maryann Xue Assignee: stack Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch, HBASE-7876-trunkv2.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8017) Upgrade hadoop 1 dependency to 1.1.2
[
https://issues.apache.org/jira/browse/HBASE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602450#comment-13602450
]
Hadoop QA commented on HBASE-8017:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12573725/8017.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4816//console
This message is automatically generated.
Upgrade hadoop 1 dependency to 1.1.2
Key: HBASE-8017
URL: https://issues.apache.org/jira/browse/HBASE-8017
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Fix For: 0.98.0
Attachments: 8017.txt, 8017.txt
Hadoop 1.1.2 has been released.
From Matt:
This release includes 24 bug fixes and backward-compatible enhancements,
compared to Hadoop 1.1.1. Improvements include:
- bug fixes in use of Kerberos security and SPNEGO
- a couple potential deadlock situations
- fixes for IBM JDK compatibility
- several unit test failure cleanups
- other useful improvements
For details, please see
http://hadoop.apache.org/docs/r1.1.2/releasenotes.html.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7876) Got exception when manually triggers a split on an empty region
[ https://issues.apache.org/jira/browse/HBASE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-7876: - Assignee: Maryann Xue (was: stack) Got exception when manually triggers a split on an empty region --- Key: HBASE-7876 URL: https://issues.apache.org/jira/browse/HBASE-7876 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.95.0 Reporter: Maryann Xue Assignee: Maryann Xue Priority: Minor Attachments: HBASE-7876-0.94V2.patch, HBASE-7876-trunk.patch, HBASE-7876-trunkv2.patch We should allow a region to split successfully even if it does not yet have storefiles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7938) Add integration test for ImportTsv/LoadIncrementalHFiles workflow
[ https://issues.apache.org/jira/browse/HBASE-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602451#comment-13602451 ] Nick Dimiduk commented on HBASE-7938: - I don't believe those failures belong to me. I'm having issues with local runs now... Add integration test for ImportTsv/LoadIncrementalHFiles workflow - Key: HBASE-7938 URL: https://issues.apache.org/jira/browse/HBASE-7938 Project: HBase Issue Type: Sub-task Components: mapreduce Reporter: Nick Dimiduk Assignee: Nick Dimiduk Fix For: 0.95.0, 0.98.0 Attachments: 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch, 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch We have existing unit tests for smoke-testing the packaged MR jobs, however they do not create a runtime environment that is true to running on a real MR cluster. This is particularly true in regard to classpaths (HBASE-7934) but also other static state (HBASE-4802). An integration test that can be pointed to run on a pseudo-distributed Hadoop deployed on localhost would find these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7938) Add integration test for ImportTsv/LoadIncrementalHFiles workflow
[ https://issues.apache.org/jira/browse/HBASE-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-7938: Status: Open (was: Patch Available) Add integration test for ImportTsv/LoadIncrementalHFiles workflow - Key: HBASE-7938 URL: https://issues.apache.org/jira/browse/HBASE-7938 Project: HBase Issue Type: Sub-task Components: mapreduce Reporter: Nick Dimiduk Assignee: Nick Dimiduk Fix For: 0.95.0, 0.98.0 Attachments: 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch, 0001-HBASE-7938-Add-integration-test-for-ImportTsv-LoadIn.patch We have existing unit tests for smoke-testing the packaged MR jobs, however they do not create a runtime environment that is true to running on a real MR cluster. This is particularly true in regard to classpaths (HBASE-7934) but also other static state (HBASE-4802). An integration test that can be pointed to run on a pseudo-distributed Hadoop deployed on localhost would find these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[
https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602455#comment-13602455
]
Jesse Yates commented on HBASE-8025:
Yeah, for even something like:
{code}
#default to server opts
GC_OPTS=$SERVER_GC_OPTS
if [ $COMMAND = shell ] ; then
# eg export JRUBY_HOME=/usr/local/share/jruby
if [ $JRUBY_HOME != ] ; then
CLASSPATH=$JRUBY_HOME/lib/jruby.jar:$CLASSPATH
HBASE_OPTS=$HBASE_OPTS -Djruby.home=$JRUBY_HOME
-Djruby.lib=$JRUBY_HOME/lib
GC_OPTS=$CLIENT_GC_OPTS
fi
elif [ $COMMAND = hbck ] ; then
CLASS='org.apache.hadoop.hbase.util.HBaseFsck'
GC_OPTS=$CLIENT_GC_OPTS
...
HBASE_OPTS=$HBASE_OPTS $GC_OPTS -Djruby.home=$JRUBY_HOME
-Djruby.lib=$JRUBY_HOME/lib
{code}
zkcli fails when SERVER_GC_OPTS is enabled
--
Key: HBASE-8025
URL: https://issues.apache.org/jira/browse/HBASE-8025
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.4
Reporter: Dave Latham
Assignee: Dave Latham
Fix For: 0.95.0, 0.98.0, 0.94.6
Attachments: 8025-alt.txt, HBASE-8025-0.94.patch
HBASE-7091 added logic to separate GC logging options for some client
commands versus server commands. It uses a list of known client commands
(shell hbck hlog hfile zkcli) and uses the server GC logging
options for all other invocations of bin/hbase. When zkcli is invoked, it in
turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg
to gather the server command line arguments, but because
org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white
list it enables server GC logging, which causes extra output that causes the
zkcli invocation to break. HBASE-7153 addressed this but the fix only solved
the array syntax - not the white list, so the zkcli command still fails.
There are many other tools you can invoke that are more likely to client
than server options. For example, bin/hbase org.jruby.Main
region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable
or bin/hbase version or bin/hbase
org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands
is shorter and easier to maintain than a whitelist of client commands.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (HBASE-8025) zkcli fails when SERVER_GC_OPTS is enabled
[
https://issues.apache.org/jira/browse/HBASE-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602455#comment-13602455
]
Jesse Yates edited comment on HBASE-8025 at 3/14/13 5:22 PM:
-
Yeah, for even something like:
{code}
#default to server opts
GC_OPTS=$SERVER_GC_OPTS
if [ $COMMAND = shell ] ; then
# eg export JRUBY_HOME=/usr/local/share/jruby
if [ $JRUBY_HOME != ] ; then
CLASSPATH=$JRUBY_HOME/lib/jruby.jar:$CLASSPATH
HBASE_OPTS=$HBASE_OPTS -Djruby.home=$JRUBY_HOME
-Djruby.lib=$JRUBY_HOME/lib
GC_OPTS=$CLIENT_GC_OPTS
fi
elif [ $COMMAND = hbck ] ; then
CLASS='org.apache.hadoop.hbase.util.HBaseFsck'
GC_OPTS=$CLIENT_GC_OPTS
...
HBASE_OPTS=$HBASE_OPTS $GC_OPTS
{code}
was (Author: jesse_yates):
Yeah, for even something like:
{code}
#default to server opts
GC_OPTS=$SERVER_GC_OPTS
if [ $COMMAND = shell ] ; then
# eg export JRUBY_HOME=/usr/local/share/jruby
if [ $JRUBY_HOME != ] ; then
CLASSPATH=$JRUBY_HOME/lib/jruby.jar:$CLASSPATH
HBASE_OPTS=$HBASE_OPTS -Djruby.home=$JRUBY_HOME
-Djruby.lib=$JRUBY_HOME/lib
GC_OPTS=$CLIENT_GC_OPTS
fi
elif [ $COMMAND = hbck ] ; then
CLASS='org.apache.hadoop.hbase.util.HBaseFsck'
GC_OPTS=$CLIENT_GC_OPTS
...
HBASE_OPTS=$HBASE_OPTS $GC_OPTS -Djruby.home=$JRUBY_HOME
-Djruby.lib=$JRUBY_HOME/lib
{code}
zkcli fails when SERVER_GC_OPTS is enabled
--
Key: HBASE-8025
URL: https://issues.apache.org/jira/browse/HBASE-8025
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.4
Reporter: Dave Latham
Assignee: Dave Latham
Fix For: 0.95.0, 0.98.0, 0.94.6
Attachments: 8025-alt.txt, HBASE-8025-0.94.patch
HBASE-7091 added logic to separate GC logging options for some client
commands versus server commands. It uses a list of known client commands
(shell hbck hlog hfile zkcli) and uses the server GC logging
options for all other invocations of bin/hbase. When zkcli is invoked, it in
turn invokes hbase org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg
to gather the server command line arguments, but because
org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServerArg is not on the white
list it enables server GC logging, which causes extra output that causes the
zkcli invocation to break. HBASE-7153 addressed this but the fix only solved
the array syntax - not the white list, so the zkcli command still fails.
There are many other tools you can invoke that are more likely to client
than server options. For example, bin/hbase org.jruby.Main
region_mover.rb or bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable
or bin/hbase version or bin/hbase
org.apache.hadoop.hbase.mapreduce.Export. The whitelist of server commands
is shorter and easier to maintain than a whitelist of client commands.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[
https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602456#comment-13602456
]
Hadoop QA commented on HBASE-8099:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12573728/HBase-8099-trunk-v4.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.master.TestZKBasedOpenCloseRegion
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4815//console
This message is automatically generated.
ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues
if it failed to execute.
-
Key: HBASE-8099
URL: https://issues.apache.org/jira/browse/HBASE-8099
Project: HBase
Issue Type: Bug
Reporter: Lars Hofhansl
Assignee: Himanshu Vashishtha
Priority: Blocker
Fix For: 0.95.0, 0.98.0, 0.94.6
Attachments: 8099-example.txt, HBase-8099-94.patch,
HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-94-v4.patch,
HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch,
HBase-8099-trunk-v4.patch
We just ran into an interesting scenario. We restarted a cluster that was
setup as a replication source.
The stop went cleanly.
Upon restart *all* regionservers aborted within a few seconds with variations
of these errors:
http://pastebin.com/3iQVuBqS
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8108) Add m2eclispe lifecycle mapping to hbase-commn
Jesse Yates created HBASE-8108: -- Summary: Add m2eclispe lifecycle mapping to hbase-commn Key: HBASE-8108 URL: https://issues.apache.org/jira/browse/HBASE-8108 Project: HBase Issue Type: Bug Reporter: Jesse Yates Assignee: Jesse Yates The maven-antrun-plugin execution doesn't have a default mapping in m2eclipse, so if you import the project into eclipse, you will get an error that the mapping is undefined. All that's needed is to define an execution via the org.eclipse.m2 lifecycle-mapping plugin - it doesn't actually affect the usual maven build at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8099) ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute.
[ https://issues.apache.org/jira/browse/HBASE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602468#comment-13602468 ] Himanshu Vashishtha commented on HBASE-8099: TestZKBasedOpenCloseRegion passes on local. ReplicationZookeeper.copyQueuesFromRSUsingMulti should not return any queues if it failed to execute. - Key: HBASE-8099 URL: https://issues.apache.org/jira/browse/HBASE-8099 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Himanshu Vashishtha Priority: Blocker Fix For: 0.95.0, 0.98.0, 0.94.6 Attachments: 8099-example.txt, HBase-8099-94.patch, HBase-8099-94-v2.patch, HBase-8099-94-v3.patch, HBase-8099-94-v4.patch, HBase-8099-trunk-2.patch, HBase-8099-trunk.patch, HBase-8099-trunk-v3.patch, HBase-8099-trunk-v4.patch We just ran into an interesting scenario. We restarted a cluster that was setup as a replication source. The stop went cleanly. Upon restart *all* regionservers aborted within a few seconds with variations of these errors: http://pastebin.com/3iQVuBqS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8108) Add m2eclispe lifecycle mapping to hbase-commn
[ https://issues.apache.org/jira/browse/HBASE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-8108: --- Affects Version/s: 0.96.0 Add m2eclispe lifecycle mapping to hbase-commn -- Key: HBASE-8108 URL: https://issues.apache.org/jira/browse/HBASE-8108 Project: HBase Issue Type: Bug Affects Versions: 0.96.0 Reporter: Jesse Yates Assignee: Jesse Yates The maven-antrun-plugin execution doesn't have a default mapping in m2eclipse, so if you import the project into eclipse, you will get an error that the mapping is undefined. All that's needed is to define an execution via the org.eclipse.m2 lifecycle-mapping plugin - it doesn't actually affect the usual maven build at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8108) Add m2eclispe lifecycle mapping to hbase-commn
[ https://issues.apache.org/jira/browse/HBASE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-8108: --- Component/s: build Add m2eclispe lifecycle mapping to hbase-commn -- Key: HBASE-8108 URL: https://issues.apache.org/jira/browse/HBASE-8108 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.96.0 Reporter: Jesse Yates Assignee: Jesse Yates The maven-antrun-plugin execution doesn't have a default mapping in m2eclipse, so if you import the project into eclipse, you will get an error that the mapping is undefined. All that's needed is to define an execution via the org.eclipse.m2 lifecycle-mapping plugin - it doesn't actually affect the usual maven build at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8000) create integration/perf tests for stripe compactions
[ https://issues.apache.org/jira/browse/HBASE-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602473#comment-13602473 ] Sergey Shelukhin commented on HBASE-8000: - Adding to performance evaluation is possible; integration test would be nice first to see that it works beyond unit tests. As for 94, it depends on many previous refactoring (intrusive) JIRAs so that's very unlikely. create integration/perf tests for stripe compactions Key: HBASE-8000 URL: https://issues.apache.org/jira/browse/HBASE-8000 Project: HBase Issue Type: Sub-task Components: Compaction Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin While writing tests I seem to be finding more errors with edge cases unrelated to what test actually tests compared to what is expected. Integration test will be needed... probably good for perf/compare too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8108) Add m2eclispe lifecycle mapping to hbase-commn
[ https://issues.apache.org/jira/browse/HBASE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-8108: --- Affects Version/s: (was: 0.96.0) 0.98.0 0.95.0 Add m2eclispe lifecycle mapping to hbase-commn -- Key: HBASE-8108 URL: https://issues.apache.org/jira/browse/HBASE-8108 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.95.0, 0.98.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-8108.patch The maven-antrun-plugin execution doesn't have a default mapping in m2eclipse, so if you import the project into eclipse, you will get an error that the mapping is undefined. All that's needed is to define an execution via the org.eclipse.m2 lifecycle-mapping plugin - it doesn't actually affect the usual maven build at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8108) Add m2eclispe lifecycle mapping to hbase-commn
[ https://issues.apache.org/jira/browse/HBASE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-8108: --- Attachment: hbase-8108.patch Simple patch to fix the pom. We've done this same kind of fix before, not sure why didn't make it into common. Add m2eclispe lifecycle mapping to hbase-commn -- Key: HBASE-8108 URL: https://issues.apache.org/jira/browse/HBASE-8108 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.95.0, 0.98.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-8108.patch The maven-antrun-plugin execution doesn't have a default mapping in m2eclipse, so if you import the project into eclipse, you will get an error that the mapping is undefined. All that's needed is to define an execution via the org.eclipse.m2 lifecycle-mapping plugin - it doesn't actually affect the usual maven build at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7295) Contention in HBaseClient.getConnection
[ https://issues.apache.org/jira/browse/HBASE-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Sharma updated HBASE-7295: Attachment: 7295-trunk-v4.txt Contention in HBaseClient.getConnection --- Key: HBASE-7295 URL: https://issues.apache.org/jira/browse/HBASE-7295 Project: HBase Issue Type: Improvement Affects Versions: 0.94.3 Reporter: Varun Sharma Assignee: Varun Sharma Fix For: 0.95.0 Attachments: 7295-0.94.txt, 7295-0.94-v2.txt, 7295-0.94-v3.txt, 7295-0.94-v4.txt, 7295-0.94-v5.txt, 7295-trunk.txt, 7295-trunk.txt, 7295-trunk-v2.txt, 7295-trunk-v3.txt, 7295-trunk-v3.txt, 7295-trunk-v4.txt HBaseClient.getConnection() synchronizes on the connections object. We found severe contention on a thrift gateway which was fanning out roughly 3000+ calls per second to hbase region servers. The thrift gateway had 2000+ threads for handling incoming connections. Threads were blocked on the syncrhonized block - we set ipc.pool.size to 200. Since we are using RoundRobin/ThreadLocal pool only - its not necessary to synchronize on connections - it might lead to cases where we might go slightly over the ipc.max.pool.size() but the additional connections would timeout after maxIdleTime - underlying PoolMap connections object is thread safe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8000) create integration/perf tests for stripe compactions
[ https://issues.apache.org/jira/browse/HBASE-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602484#comment-13602484 ] Jean-Marc Spaggiari commented on HBASE-8000: For 94 backport I was talking only about the performance evaluation, not the stripe compactions itself. To compare major compactions or similar processes between 0.94 where we don't have the stripe compaction, and 0.96 where we have it. This might allow us to figure how stripe compactions is impacting the performances. create integration/perf tests for stripe compactions Key: HBASE-8000 URL: https://issues.apache.org/jira/browse/HBASE-8000 Project: HBase Issue Type: Sub-task Components: Compaction Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin While writing tests I seem to be finding more errors with edge cases unrelated to what test actually tests compared to what is expected. Integration test will be needed... probably good for perf/compare too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8108) Add m2eclispe lifecycle mapping to hbase-commn
[ https://issues.apache.org/jira/browse/HBASE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602489#comment-13602489 ] Sergey Shelukhin commented on HBASE-8108: - +1 on patch as such, but I'm not sure what the approach is to adding such things to pom here (what if everyone wants to add stuff for their IDE/tools?). I am ok, maybe someone else can comment. Add m2eclispe lifecycle mapping to hbase-commn -- Key: HBASE-8108 URL: https://issues.apache.org/jira/browse/HBASE-8108 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.95.0, 0.98.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-8108.patch The maven-antrun-plugin execution doesn't have a default mapping in m2eclipse, so if you import the project into eclipse, you will get an error that the mapping is undefined. All that's needed is to define an execution via the org.eclipse.m2 lifecycle-mapping plugin - it doesn't actually affect the usual maven build at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[ https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-8101: - Attachment: 8101v3.txt Address [~nkeywal] review. Actually let the clone exception out; the clone is used in tests only And regards check for null row, do it more thoroughly... which turned up a few tests creating null rows which I fixed in this patch. Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc. - Key: HBASE-8101 URL: https://issues.apache.org/jira/browse/HBASE-8101 Project: HBase Issue Type: Sub-task Components: IPC/RPC Reporter: stack Fix For: 0.95.0 Attachments: 8101.txt, 8101v2.txt, 8101v3.txt Part of hbase-7900 broken out so that patch gets smaller. This is a patch with cleanup mostly findbugs fixes (general ones) as well as adding check for null row being passed to Put, Get, etc. This patch helps rpc along. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8108) Add m2eclispe lifecycle mapping to hbase-commn
[ https://issues.apache.org/jira/browse/HBASE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602494#comment-13602494 ] Jesse Yates commented on HBASE-8108: Given that eclipse and intellij are the main two tools by a large fraction (I doubt many people are hacking HBase with a basic text editor), this isn't all that unreasonable...especially as we have done this in the code before. IMO supporting the most widely used tools well is not only good, its nearly mandatory. Add m2eclispe lifecycle mapping to hbase-commn -- Key: HBASE-8108 URL: https://issues.apache.org/jira/browse/HBASE-8108 Project: HBase Issue Type: Bug Components: build Affects Versions: 0.95.0, 0.98.0 Reporter: Jesse Yates Assignee: Jesse Yates Attachments: hbase-8108.patch The maven-antrun-plugin execution doesn't have a default mapping in m2eclipse, so if you import the project into eclipse, you will get an error that the mapping is undefined. All that's needed is to define an execution via the org.eclipse.m2 lifecycle-mapping plugin - it doesn't actually affect the usual maven build at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
