[jira] [Commented] (HBASE-6414) Remove the WritableRpcEngine associated Invocation classes
[ https://issues.apache.org/jira/browse/HBASE-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437678#comment-13437678 ] Devaraj Das commented on HBASE-6414: Thanks Stack. BTW the files hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/WritableRpcEngine.java and hbase-server/src/test/java/org/apache/hadoop/hbase/ipc/TestPBOnWritableRpc.java should be deleted from svn (currently they are 0 length files). Remove the WritableRpcEngine associated Invocation classes Key: HBASE-6414 URL: https://issues.apache.org/jira/browse/HBASE-6414 Project: HBase Issue Type: Improvement Affects Versions: 0.96.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.96.0 Attachments: 6414-1.patch.txt, 6414-3.patch.txt, 6414-4.patch.txt, 6414-4.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-6.patch.txt, 6414-6.patch.txt, 6414-6.txt, 6414-initial.patch.txt, 6414-initial.patch.txt, 6414-v7.txt Remove the WritableRpcEngine Invocation classes once HBASE-5705 gets committed and all the protocols are rebased to use PB. Raising this jira in advance.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6589) RegionServer can't load class for dynamically loaded coprocessors with self defined class
[
https://issues.apache.org/jira/browse/HBASE-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437680#comment-13437680
]
ShiXing commented on HBASE-6589:
It is when I try to invoke the CP. Because the MultiColumnSchema is not
recognized by the rs.
RegionServer can't load class for dynamically loaded coprocessors with self
defined class
-
Key: HBASE-6589
URL: https://issues.apache.org/jira/browse/HBASE-6589
Project: HBase
Issue Type: Bug
Components: coprocessors, regionserver
Reporter: ShiXing
When using coprocessor with custom classes like LongColumnInterpreter(mine is
MultiColumnSchema), the coprocessor can not work for hot deploy, if the
custom classes do not deploy in the regionserver's classpath. Although the
self-defined class is deployed in the regions' classpath through hdfs jar.
The exception threw at the regionserver's log:
{code}
2012-08-15 16:24:24,403 ERROR org.apache.hadoop.hbase.io.HbaseObjectWritable:
Error in readFields
java.io.IOException: Can't find class
com.taobao.hbase.coprocessor.MultiColumnSchema
at
org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:674)
at
org.apache.hadoop.hbase.client.coprocessor.Exec.readFields(Exec.java:114)
at
org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:682)
at
org.apache.hadoop.hbase.ipc.Invocation.readFields(Invocation.java:125)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Connection.processData(HBaseServer.java:1292)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Connection.readAndProcess(HBaseServer.java:1207)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Listener.doRead(HBaseServer.java:735)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.doRunLoop(HBaseServer.java:524)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.run(HBaseServer.java:499)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException:
com.taobao.hbase.coprocessor.MultiColumnSchema
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
org.apache.hadoop.conf.Configuration.getClassByName(Configuration.java:943)
at
org.apache.hadoop.hbase.io.HbaseObjectWritable.getClassByName(HbaseObjectWritable.java:784)
at
org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:671)
... 11 more
{code}
It is similar as HBASE-4946, but I do not know how to solve this bug.
If add these custom class to the RegionServer's classloader may fix it, but
it is conflicted with HBASE-6308 to prevent dependency conflicts.
Does anyone have some idea?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6614) General cleanup/optimizations of the protobuf RPC engine associated RPC code
Devaraj Das created HBASE-6614: -- Summary: General cleanup/optimizations of the protobuf RPC engine associated RPC code Key: HBASE-6614 URL: https://issues.apache.org/jira/browse/HBASE-6614 Project: HBase Issue Type: Bug Reporter: Devaraj Das Raising this as a placeholder for doing cleanup/optimizations of the protobuf RPC engine associated RPC code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6414) Remove the WritableRpcEngine associated Invocation classes
[ https://issues.apache.org/jira/browse/HBASE-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437686#comment-13437686 ] Devaraj Das commented on HBASE-6414: I raised this to take care of issues like double deserialization others we come across in RPC.. https://issues.apache.org/jira/browse/HBASE-6614 Remove the WritableRpcEngine associated Invocation classes Key: HBASE-6414 URL: https://issues.apache.org/jira/browse/HBASE-6414 Project: HBase Issue Type: Improvement Affects Versions: 0.96.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.96.0 Attachments: 6414-1.patch.txt, 6414-3.patch.txt, 6414-4.patch.txt, 6414-4.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-6.patch.txt, 6414-6.patch.txt, 6414-6.txt, 6414-initial.patch.txt, 6414-initial.patch.txt, 6414-v7.txt Remove the WritableRpcEngine Invocation classes once HBASE-5705 gets committed and all the protocols are rebased to use PB. Raising this jira in advance.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6614) General cleanup/optimizations of the protobuf RPC engine associated RPC code
[ https://issues.apache.org/jira/browse/HBASE-6614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devaraj Das updated HBASE-6614: --- Component/s: ipc Fix Version/s: 0.96.0 Assignee: Devaraj Das General cleanup/optimizations of the protobuf RPC engine associated RPC code -- Key: HBASE-6614 URL: https://issues.apache.org/jira/browse/HBASE-6614 Project: HBase Issue Type: Bug Components: ipc Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.96.0 Raising this as a placeholder for doing cleanup/optimizations of the protobuf RPC engine associated RPC code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] rajeshbabu updated HBASE-6584: -- Status: Open (was: Patch Available) Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] rajeshbabu updated HBASE-6584: -- Status: Patch Available (was: Open) Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] rajeshbabu updated HBASE-6584: -- Attachment: HBASE-6584_trunk_2.patch Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437704#comment-13437704 ] rajeshbabu commented on HBASE-6584: --- Sorry for first patch. Failed tests passes with latest patch. Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437725#comment-13437725 ] Hadoop QA commented on HBASE-6584: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12541563/HBASE-6584_trunk_2.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile. +1 javadoc. The javadoc tool did not generate any warning messages. -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 6 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2626//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2626//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2626//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2626//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2626//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2626//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2626//console This message is automatically generated. Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6615) hbase.rs.evictblocksonclose seems to be ineffective
Zhou wenjian created HBASE-6615: --- Summary: hbase.rs.evictblocksonclose seems to be ineffective Key: HBASE-6615 URL: https://issues.apache.org/jira/browse/HBASE-6615 Project: HBase Issue Type: Bug Reporter: Zhou wenjian Assignee: Zhou wenjian when we close region，storefile.closeReader(true) is invoked, it seems that hbase.rs.evictblocksonclose is ineffective. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6615) hbase.rs.evictblocksonclose seems to be ineffective
[ https://issues.apache.org/jira/browse/HBASE-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhou wenjian updated HBASE-6615: Affects Version/s: 0.94.1 Fix Version/s: 0.94.2 hbase.rs.evictblocksonclose seems to be ineffective --- Key: HBASE-6615 URL: https://issues.apache.org/jira/browse/HBASE-6615 Project: HBase Issue Type: Bug Affects Versions: 0.94.1 Reporter: Zhou wenjian Assignee: Zhou wenjian Fix For: 0.94.2 when we close region，storefile.closeReader(true) is invoked, it seems that hbase.rs.evictblocksonclose is ineffective. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6516) hbck cannot detect any IOException while .tableinfo file is missing
[ https://issues.apache.org/jira/browse/HBASE-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437846#comment-13437846 ] Jie Huang commented on HBASE-6516: -- Agree with you to some extent. However I still have one question. How about .META. table? Since for that kind of table, it is quite acceptable not to have the .tableinfo file there. Actually, it is not an IOException or TableInfoMissingException for that case. Shall we handle this case in *getTableDescriptor()* ? OR let its final caller to handle it? Besides, I found the HBaseIOException was introduced in HBASE-6586, so will provide the new patch later. hbck cannot detect any IOException while .tableinfo file is missing - Key: HBASE-6516 URL: https://issues.apache.org/jira/browse/HBASE-6516 Project: HBase Issue Type: Bug Components: hbck Affects Versions: 0.94.0, 0.96.0 Reporter: Jie Huang Attachments: hbase-6516.patch, hbase-6516-v2.patch HBaseFsck checks those missing .tableinfo files in loadHdfsRegionInfos() function. However, no IoException will be catched while .tableinfo is missing, since FSTableDescriptors.getTableDescriptor doesn't throw any IoException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5714) Add write permissions check before any hbck run that modifies hdfs.
[ https://issues.apache.org/jira/browse/HBASE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437873#comment-13437873 ] Jonathan Hsieh commented on HBASE-5714: --- Jie, looks great and thanks for the testing output. I have only a one style nit i'd like your thoughts on: Can you make the calls to Runtime.getRuntime().exit(xx) happen in main instead of the helper? If we were to write tests, the exit would make it difficult. Add write permissions check before any hbck run that modifies hdfs. --- Key: HBASE-5714 URL: https://issues.apache.org/jira/browse/HBASE-5714 Project: HBase Issue Type: Sub-task Components: hbck Affects Versions: 0.90.6, 0.92.2, 0.94.0, 0.96.0 Reporter: Jonathan Hsieh Attachments: HBASE-5628.patch We encoutered a situation where hbck was run by an under-privileged user that was unable to write/modify/merge regions due to hdfs perms. Unfortunately, this user was alerted of this after several minutes of read-only operations. hbck should fail early by having a write perm check and providing actionable advice to the hbase admin. Maybe something like: Current user yy does not have write perms to hbase home. Please run hbck as hdfs user xxx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6414) Remove the WritableRpcEngine associated Invocation classes
[ https://issues.apache.org/jira/browse/HBASE-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437927#comment-13437927 ] stack commented on HBASE-6414: -- Thanks DD. I just removed them. Remove the WritableRpcEngine associated Invocation classes Key: HBASE-6414 URL: https://issues.apache.org/jira/browse/HBASE-6414 Project: HBase Issue Type: Improvement Affects Versions: 0.96.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.96.0 Attachments: 6414-1.patch.txt, 6414-3.patch.txt, 6414-4.patch.txt, 6414-4.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-6.patch.txt, 6414-6.patch.txt, 6414-6.txt, 6414-initial.patch.txt, 6414-initial.patch.txt, 6414-v7.txt Remove the WritableRpcEngine Invocation classes once HBASE-5705 gets committed and all the protocols are rebased to use PB. Raising this jira in advance.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437935#comment-13437935 ] stack commented on HBASE-6584: -- @Rajeshbabu You set it to an explicit 6281? You think that a good idea? If you set it to zero, it won't choose an arbitrary port? Should we retry a new port if 6281 itself is taken? (There used to be code that did this maybe its been removed). Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5714) Add write permissions check before any hbck run that modifies hdfs.
[ https://issues.apache.org/jira/browse/HBASE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liang xie updated HBASE-5714: - Attachment: HBASE-5628.patch.v2 Modified per Jon's comments Add write permissions check before any hbck run that modifies hdfs. --- Key: HBASE-5714 URL: https://issues.apache.org/jira/browse/HBASE-5714 Project: HBase Issue Type: Sub-task Components: hbck Affects Versions: 0.90.6, 0.92.2, 0.94.0, 0.96.0 Reporter: Jonathan Hsieh Attachments: HBASE-5628.patch, HBASE-5628.patch.v2 We encoutered a situation where hbck was run by an under-privileged user that was unable to write/modify/merge regions due to hdfs perms. Unfortunately, this user was alerted of this after several minutes of read-only operations. hbck should fail early by having a write perm check and providing actionable advice to the hbase admin. Maybe something like: Current user yy does not have write perms to hbase home. Please run hbck as hdfs user xxx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6407) Investigate moving to DI (guice) framework for plugin arch.
[ https://issues.apache.org/jira/browse/HBASE-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-6407: - Resolution: Won't Fix Status: Resolved (was: Patch Available) Adding this with metrics is too much code. After 0.96 is branched we can come back to Guice and start the process slowly, as splitting this patch got too hard. Investigate moving to DI (guice) framework for plugin arch. --- Key: HBASE-6407 URL: https://issues.apache.org/jira/browse/HBASE-6407 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-6407-1.patch, HBASE-6407-2.patch, HBASE-6407-3.patch, HBASE-6407-4.patch, HBASE-6407-5.patch, HBASE-6407-6.patch Investigate using Guice to inject the correct compat object provided by compat plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6588) enable table throws npe and leaves trash in zk in competition with delete table
[
https://issues.apache.org/jira/browse/HBASE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437972#comment-13437972
]
Zhihong Ted Yu commented on HBASE-6588:
---
For patch v5, if you look at
https://builds.apache.org/job/PreCommit-HBASE-Build/2623/console, you can see
that compilation failed for hadoop 2.0 profile.
I got the following error compiling against hadoop 2.0, locally:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile)
on project hbase-server: Compilation failure: Compilation failure:
[ERROR]
/home/zhihyu/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java:[722,50]
cannot find symbol
[ERROR] symbol : variable COMPACTION_KV_MAX
[ERROR] location: class org.apache.hadoop.hbase.HConstants
[ERROR]
[ERROR]
/home/zhihyu/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:[3578,36]
cannot find symbol
[ERROR] symbol : method isInternal()
[ERROR] location: class org.apache.hadoop.hbase.KeyValue
[ERROR]
[ERROR]
/home/zhihyu/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Compactor.java:[113,53]
cannot find symbol
[ERROR] symbol : variable COMPACTION_KV_MAX
[ERROR] location: class org.apache.hadoop.hbase.HConstants
{code}
enable table throws npe and leaves trash in zk in competition with delete
table
---
Key: HBASE-6588
URL: https://issues.apache.org/jira/browse/HBASE-6588
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Zhou wenjian
Assignee: Zhou wenjian
Fix For: 0.94.2
Attachments: HBASE-6588-trunk.patch, HBASE-6588-trunk-v2.patch,
HBASE-6588-trunk-v3.patch, HBASE-6588-trunk-v4.patch,
HBASE-6588-trunk-v5.patch
2012-08-15 19:23:36,178 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Creating scanner over .META. starting at key 'test,,'
2012-08-15 19:23:36,178 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Advancing internal scanner to startKey at 'test,,'
2012-08-15 19:24:09,180 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Creating scanner over .META. starting at key ''
2012-08-15 19:24:09,180 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Advancing internal scanner to startKey at ''
2012-08-15 19:24:09,183 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Finished with scanning at {NAME = '.META.,,1', STARTKEY = '', ENDKEY = '',
ENCODED = 1028785192,}
2012-08-15 19:24:09,183 DEBUG org.apache.hadoop.hbase.master.CatalogJanitor:
Scanned 2 catalog row(s) and gc'd 0 unreferenced parent region(s)
2012-08-15 19:25:12,260 DEBUG
org.apache.hadoop.hbase.master.handler.DeleteTableHandler: Deleting region
test,,1345029764571.d1e24b251ca6286c840a9a5f571b7db1. from META and FS
2012-08-15 19:25:12,263 INFO org.apache.hadoop.hbase.catalog.MetaEditor:
Deleted region test,,1345029764571.d1e24b251ca6286c840a9a5f571b7db1. from META
2012-08-15 19:25:12,265 INFO
org.apache.hadoop.hbase.master.handler.EnableTableHandler: Attemping to
enable the table test
2012-08-15 19:25:12,265 WARN org.apache.hadoop.hbase.zookeeper.ZKTable:
Moving table test state to enabling but was not first in disabled state: null
2012-08-15 19:25:12,267 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Creating scanner over .META. starting at key 'test,,'
2012-08-15 19:25:12,267 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Advancing internal scanner to startKey at 'test,,'
2012-08-15 19:25:12,270 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Finished with scanning at {NAME = '.META.,,1', STARTKEY = '', ENDKEY = '',
ENCODED = 1028785192,}
2012-08-15 19:25:12,270 ERROR org.apache.hadoop.hbase.executor.EventHandler:
Caught throwable while processing event C_M_ENABLE_TABLE
java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.handler.EnableTableHandler.handleEnableTable(EnableTableHandler.java:116)
at
org.apache.hadoop.hbase.master.handler.EnableTableHandler.process(EnableTableHandler.java:97)
at
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:169)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
table is disabled now, then we enable and delete the table at the same time.
Since the thread num of MASTER_TABLE_OPERATIONS is 1 by default. The two
operations are serial in master.Before deletetable deletes all the regions in
meta, CreateTableHandler ships the check of tableExists,then it will block
until deletetable finishs, then
[jira] [Comment Edited] (HBASE-6588) enable table throws npe and leaves trash in zk in competition with delete table
[
https://issues.apache.org/jira/browse/HBASE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437972#comment-13437972
]
Zhihong Ted Yu edited comment on HBASE-6588 at 8/21/12 3:17 AM:
For patch v5, if you look at
https://builds.apache.org/job/PreCommit-HBASE-Build/2623/console, you can see
that compilation failed for hadoop 2.0 profile.
I got the following error compiling against hadoop 2.0, locally:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile
(default-testCompile) on project hbase-server: Compilation failure: Compilation
failure:
[ERROR]
/home/zhihyu/trunk-hbase/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java:[849,16]
cannot find symbol
[ERROR] symbol : class RegionState
[ERROR] location: class org.apache.hadoop.hbase.client.TestAdmin
[ERROR]
[ERROR]
/home/zhihyu/trunk-hbase/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java:[854,29]
cannot find symbol
[ERROR] symbol : class RegionState
[ERROR] location: class org.apache.hadoop.hbase.client.TestAdmin
{code}
was (Author: zhi...@ebaysf.com):
For patch v5, if you look at
https://builds.apache.org/job/PreCommit-HBASE-Build/2623/console, you can see
that compilation failed for hadoop 2.0 profile.
I got the following error compiling against hadoop 2.0, locally:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile)
on project hbase-server: Compilation failure: Compilation failure:
[ERROR]
/home/zhihyu/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java:[722,50]
cannot find symbol
[ERROR] symbol : variable COMPACTION_KV_MAX
[ERROR] location: class org.apache.hadoop.hbase.HConstants
[ERROR]
[ERROR]
/home/zhihyu/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:[3578,36]
cannot find symbol
[ERROR] symbol : method isInternal()
[ERROR] location: class org.apache.hadoop.hbase.KeyValue
[ERROR]
[ERROR]
/home/zhihyu/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Compactor.java:[113,53]
cannot find symbol
[ERROR] symbol : variable COMPACTION_KV_MAX
[ERROR] location: class org.apache.hadoop.hbase.HConstants
{code}
enable table throws npe and leaves trash in zk in competition with delete
table
---
Key: HBASE-6588
URL: https://issues.apache.org/jira/browse/HBASE-6588
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Zhou wenjian
Assignee: Zhou wenjian
Fix For: 0.94.2
Attachments: HBASE-6588-trunk.patch, HBASE-6588-trunk-v2.patch,
HBASE-6588-trunk-v3.patch, HBASE-6588-trunk-v4.patch,
HBASE-6588-trunk-v5.patch
2012-08-15 19:23:36,178 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Creating scanner over .META. starting at key 'test,,'
2012-08-15 19:23:36,178 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Advancing internal scanner to startKey at 'test,,'
2012-08-15 19:24:09,180 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Creating scanner over .META. starting at key ''
2012-08-15 19:24:09,180 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Advancing internal scanner to startKey at ''
2012-08-15 19:24:09,183 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Finished with scanning at {NAME = '.META.,,1', STARTKEY = '', ENDKEY = '',
ENCODED = 1028785192,}
2012-08-15 19:24:09,183 DEBUG org.apache.hadoop.hbase.master.CatalogJanitor:
Scanned 2 catalog row(s) and gc'd 0 unreferenced parent region(s)
2012-08-15 19:25:12,260 DEBUG
org.apache.hadoop.hbase.master.handler.DeleteTableHandler: Deleting region
test,,1345029764571.d1e24b251ca6286c840a9a5f571b7db1. from META and FS
2012-08-15 19:25:12,263 INFO org.apache.hadoop.hbase.catalog.MetaEditor:
Deleted region test,,1345029764571.d1e24b251ca6286c840a9a5f571b7db1. from META
2012-08-15 19:25:12,265 INFO
org.apache.hadoop.hbase.master.handler.EnableTableHandler: Attemping to
enable the table test
2012-08-15 19:25:12,265 WARN org.apache.hadoop.hbase.zookeeper.ZKTable:
Moving table test state to enabling but was not first in disabled state: null
2012-08-15 19:25:12,267 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Creating scanner over .META. starting at key 'test,,'
2012-08-15 19:25:12,267 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Advancing internal scanner to startKey at 'test,,'
2012-08-15 19:25:12,270 DEBUG org.apache.hadoop.hbase.client.ClientScanner:
Finished with scanning at {NAME = '.META.,,1', STARTKEY = '', ENDKEY = '',
ENCODED = 1028785192,}
2012-08-15 19:25:12,270 ERROR
[jira] [Commented] (HBASE-6524) Hooks for hbase tracing
[ https://issues.apache.org/jira/browse/HBASE-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437990#comment-13437990 ] Jonathan Leavitt commented on HBASE-6524: - Final update on findbugs: I installed the findbugs eclipse plugin and inspected all of the files I edited. I saw no bugs introduced by any code from my patch. Hooks for hbase tracing --- Key: HBASE-6524 URL: https://issues.apache.org/jira/browse/HBASE-6524 Project: HBase Issue Type: Sub-task Reporter: Jonathan Leavitt Attachments: htracehooks1.diff Includes the hooks that use [htrace|http://www.github.com/cloudera/htrace] library to add dapper-like tracing to hbase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6414) Remove the WritableRpcEngine associated Invocation classes
[ https://issues.apache.org/jira/browse/HBASE-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437991#comment-13437991 ] Hudson commented on HBASE-6414: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #138 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/138/]) HBASE-6414 Remove the WritableRpcEngine associated Invocation classes; REMOVE EMPTY FILES (Revision 1375051) Result = FAILURE stack : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/WritableRpcEngine.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/ipc/TestPBOnWritableRpc.java Remove the WritableRpcEngine associated Invocation classes Key: HBASE-6414 URL: https://issues.apache.org/jira/browse/HBASE-6414 Project: HBase Issue Type: Improvement Affects Versions: 0.96.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.96.0 Attachments: 6414-1.patch.txt, 6414-3.patch.txt, 6414-4.patch.txt, 6414-4.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-6.patch.txt, 6414-6.patch.txt, 6414-6.txt, 6414-initial.patch.txt, 6414-initial.patch.txt, 6414-v7.txt Remove the WritableRpcEngine Invocation classes once HBASE-5705 gets committed and all the protocols are rebased to use PB. Raising this jira in advance.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437998#comment-13437998 ] Andrew Purtell commented on HBASE-5449: --- I wonder if we should use an integer instead of protobuf enum for Action. IIRC, it's not possible to extend those with new cases, and enum values are encoded as a 32-bit varint anyway. Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6414) Remove the WritableRpcEngine associated Invocation classes
[ https://issues.apache.org/jira/browse/HBASE-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438001#comment-13438001 ] Hudson commented on HBASE-6414: --- Integrated in HBase-TRUNK #3242 (See [https://builds.apache.org/job/HBase-TRUNK/3242/]) HBASE-6414 Remove the WritableRpcEngine associated Invocation classes; REMOVE EMPTY FILES (Revision 1375051) Result = FAILURE stack : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/WritableRpcEngine.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/ipc/TestPBOnWritableRpc.java Remove the WritableRpcEngine associated Invocation classes Key: HBASE-6414 URL: https://issues.apache.org/jira/browse/HBASE-6414 Project: HBase Issue Type: Improvement Affects Versions: 0.96.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.96.0 Attachments: 6414-1.patch.txt, 6414-3.patch.txt, 6414-4.patch.txt, 6414-4.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-5.patch.txt, 6414-6.patch.txt, 6414-6.patch.txt, 6414-6.txt, 6414-initial.patch.txt, 6414-initial.patch.txt, 6414-v7.txt Remove the WritableRpcEngine Invocation classes once HBASE-5705 gets committed and all the protocols are rebased to use PB. Raising this jira in advance.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6616) test failure in TestDelayedRpc#testTooManyDelayedRpcs
Ming Ma created HBASE-6616: -- Summary: test failure in TestDelayedRpc#testTooManyDelayedRpcs Key: HBASE-6616 URL: https://issues.apache.org/jira/browse/HBASE-6616 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.92.1 Reporter: Ming Ma Assignee: Ming Ma java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.hadoop.hbase.ipc.TestDelayedRpc.testTooManyDelayedRpcs(TestDelayedRpc.java:146) assertTrue(listAppender.getMessages().isEmpty()); listAppender.getMessages returned something like [Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting IPC Server listener on 41965, IPC Server Responder: starting, IPC Server listener on 41965: starting, IPC Server handler 0 on 41965: starting] That comes from HBaseServer.java, Reader class LOG.info(Starting + getName()); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6616) test failure in TestDelayedRpc#testTooManyDelayedRpcs
[ https://issues.apache.org/jira/browse/HBASE-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ming Ma updated HBASE-6616: --- Attachment: HBASE-6616.patch Here is the fix; turn on WARN log level for the test case. test failure in TestDelayedRpc#testTooManyDelayedRpcs -- Key: HBASE-6616 URL: https://issues.apache.org/jira/browse/HBASE-6616 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.92.1 Reporter: Ming Ma Assignee: Ming Ma Attachments: HBASE-6616.patch java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.hadoop.hbase.ipc.TestDelayedRpc.testTooManyDelayedRpcs(TestDelayedRpc.java:146) assertTrue(listAppender.getMessages().isEmpty()); listAppender.getMessages returned something like [Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting IPC Server listener on 41965, IPC Server Responder: starting, IPC Server listener on 41965: starting, IPC Server handler 0 on 41965: starting] That comes from HBaseServer.java, Reader class LOG.info(Starting + getName()); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6598) Combine Master Metrics into a single class.
[ https://issues.apache.org/jira/browse/HBASE-6598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-6598: - Attachment: HBASE-6598-2.patch Attaching again trying to get hadoop qa to come back around. Combine Master Metrics into a single class. --- Key: HBASE-6598 URL: https://issues.apache.org/jira/browse/HBASE-6598 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-6598-0.patch, HBASE-6598-1.patch, HBASE-6598-2.patch Rather than an MBean and a dynamic source. Lets use just one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5251) Some commands return 0 rows when 0 rows were processed successfully
[ https://issues.apache.org/jira/browse/HBASE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438017#comment-13438017 ] s...@hotmail.com commented on HBASE-5251: - Stack, reply to your questions: 1. Its a map with key/val pair and thereby will always use STDOUT. 2. Yes and I will add comments. Some commands return 0 rows when 0 rows were processed successfully --- Key: HBASE-5251 URL: https://issues.apache.org/jira/browse/HBASE-5251 Project: HBase Issue Type: Bug Components: shell Affects Versions: 0.90.5 Reporter: David S. Wang Assignee: Sameer Vaishampayan Priority: Minor Labels: noob Attachments: patch7.diff, patch8.diff From the hbase shell, I see this: hbase(main):049:0 scan 't1' ROW COLUMN+CELL r1 column=f1:c1, timestamp=1327104295560, value=value r1 column=f1:c2, timestamp=1327104330625, value=value 1 row(s) in 0.0300 seconds hbase(main):050:0 deleteall 't1', 'r1' 0 row(s) in 0.0080 seconds == I expected this to read 2 row(s) hbase(main):051:0 scan 't1' ROW COLUMN+CELL 0 row(s) in 0.0090 seconds I expected the deleteall command to return 1 row(s) instead of 0, because 1 row was deleted. Similar behavior for delete and some other commands. Some commands such as put work fine. Looking at the ruby shell code, it seems that formatter.footer() is called even for commands that will not actually increment the number of rows reported, such as deletes. Perhaps there should be another similar function to formatter.footer(), but that will not print out @row_count. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6617) ReplicationSourceManager should be able to track multiple WAL paths
Zhihong Ted Yu created HBASE-6617: - Summary: ReplicationSourceManager should be able to track multiple WAL paths Key: HBASE-6617 URL: https://issues.apache.org/jira/browse/HBASE-6617 Project: HBase Issue Type: Sub-task Reporter: Zhihong Ted Yu Currently ReplicationSourceManager uses logRolled() to receive notification about new HLog and remembers it in latestPath. When region server has multiple WAL support, we need to keep track of multiple Path's in ReplicationSourceManager -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-5937) Refactor HLog into an interface.
[ https://issues.apache.org/jira/browse/HBASE-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhihong Ted Yu reassigned HBASE-5937: - Assignee: Flavio Junqueira (was: Li Pi) Refactor HLog into an interface. Key: HBASE-5937 URL: https://issues.apache.org/jira/browse/HBASE-5937 Project: HBase Issue Type: Sub-task Reporter: Li Pi Assignee: Flavio Junqueira Priority: Minor What the summary says. Create HLog interface. Make current implementation use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5251) Some commands return 0 rows when 0 rows were processed successfully
[ https://issues.apache.org/jira/browse/HBASE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] s...@hotmail.com updated HBASE-5251: Attachment: patch9.diff Added comments to formatters. No code change from last patch uploaded. Some commands return 0 rows when 0 rows were processed successfully --- Key: HBASE-5251 URL: https://issues.apache.org/jira/browse/HBASE-5251 Project: HBase Issue Type: Bug Components: shell Affects Versions: 0.90.5 Reporter: David S. Wang Assignee: Sameer Vaishampayan Priority: Minor Labels: noob Attachments: patch7.diff, patch8.diff, patch9.diff From the hbase shell, I see this: hbase(main):049:0 scan 't1' ROW COLUMN+CELL r1 column=f1:c1, timestamp=1327104295560, value=value r1 column=f1:c2, timestamp=1327104330625, value=value 1 row(s) in 0.0300 seconds hbase(main):050:0 deleteall 't1', 'r1' 0 row(s) in 0.0080 seconds == I expected this to read 2 row(s) hbase(main):051:0 scan 't1' ROW COLUMN+CELL 0 row(s) in 0.0090 seconds I expected the deleteall command to return 1 row(s) instead of 0, because 1 row was deleted. Similar behavior for delete and some other commands. Some commands such as put work fine. Looking at the ruby shell code, it seems that formatter.footer() is called even for commands that will not actually increment the number of rows reported, such as deletes. Perhaps there should be another similar function to formatter.footer(), but that will not print out @row_count. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6598) Combine Master Metrics into a single class.
[ https://issues.apache.org/jira/browse/HBASE-6598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438029#comment-13438029 ] Elliott Clark commented on HBASE-6598: -- Everything runs clean on my local machine once I give maven a little more memory. Combine Master Metrics into a single class. --- Key: HBASE-6598 URL: https://issues.apache.org/jira/browse/HBASE-6598 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-6598-0.patch, HBASE-6598-1.patch, HBASE-6598-2.patch Rather than an MBean and a dynamic source. Lets use just one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438035#comment-13438035 ] s...@hotmail.com commented on HBASE-6584: - Why not get a random available port ? However this only will be a fix for this particular test. Some other test which might be creating HMaster using default configuration may still flap with the same error. We don't know at this point which call to shutdown of HMaster fails to actually shut it down and thereby the test seeing the port blocked. Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6608) Fix for HBASE-6160, META entries from daughters can be deleted before parent entries, shouldn't compare HRegionInfo's
[
https://issues.apache.org/jira/browse/HBASE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-6608:
-
Attachment: hbase-6608_v1-0.92+0.94.patch
Thanks for the reviews. Attaching a patch for 0.92 and 0.94.
bq. Makes me think we should not be comparing 'offline' when doing
HRI#compareTo.
I agree. I see no circumstance that comparing HRI.offline would be needed in
compareTo() comparison. I can provide an addendum patch if you think we should
remove that.
Fix for HBASE-6160, META entries from daughters can be deleted before parent
entries, shouldn't compare HRegionInfo's
-
Key: HBASE-6608
URL: https://issues.apache.org/jira/browse/HBASE-6608
Project: HBase
Issue Type: Bug
Components: client, regionserver
Affects Versions: 0.92.1, 0.96.0, 0.94.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 0.92.2, 0.96.0, 0.94.2
Attachments: 6608-v2.patch, hbase-6608_v1-0.92+0.94.patch,
hbase-6608_v1.patch
Our nightlies discovered that the patch for HBASE-6160 did not actually fix
the issue of META entries from daughters can be deleted before parent
entries. Instead of reopening the HBASE-6160, it is cleaner to track it
here.
The original issue is:
{quote}
HBASE-5986 fixed and issue, where the client sees the META entry for the
parent, but not the children. However, after the fix, we have seen the
following issue in tests:
Region A is split to - B, C
Region B is split to - D, E
After some time, META entry for B is deleted since it is not needed anymore,
but META entry for Region A stays in META (C still refers it). In this case,
the client throws RegionOfflineException for B.
{quote}
The problem with the fix seems to be that we keep and compare HRegionInfo's
in the HashSet at CatalogJanitor.java#scan(), but HRI that are compared are
not equal.
{code}
HashSetHRegionInfo parentNotCleaned = new HashSetHRegionInfo(); //regions
whose parents are still around
for (Map.EntryHRegionInfo, Result e : splitParents.entrySet()) {
if (!parentNotCleaned.contains(e.getKey()) cleanParent(e.getKey(),
e.getValue())) {
cleaned++;
} else {
...
{code}
In the above case, Meta row for region A will contain a serialized version of
B that is not offline. However Meta row for region B will contain a
serialized version of B that is offline (MetaEditor.offlineParentInMeta()
does that). So the deserialized version we put to HashSet and the
deserialized version we query contains() from HashSet are different in the
offline field, thus HRI.equals() fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6436) Netty should be moved off of snapshots.
[ https://issues.apache.org/jira/browse/HBASE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-6436: - Status: Patch Available (was: Open) Netty should be moved off of snapshots. --- Key: HBASE-6436 URL: https://issues.apache.org/jira/browse/HBASE-6436 Project: HBase Issue Type: Task Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-6436-0.patch Netty is currently at 3.5.0.final-SNAPSHOT the final 3.5.0.Final should be used when possible so that repositories aren't queried when not needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6436) Netty should be moved off of snapshots.
[ https://issues.apache.org/jira/browse/HBASE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-6436: - Attachment: HBASE-6436-0.patch No need for Netty to be on snapshots. the 3.5.0 works well with async hbase. Netty should be moved off of snapshots. --- Key: HBASE-6436 URL: https://issues.apache.org/jira/browse/HBASE-6436 Project: HBase Issue Type: Task Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-6436-0.patch Netty is currently at 3.5.0.final-SNAPSHOT the final 3.5.0.Final should be used when possible so that repositories aren't queried when not needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6025) Expose Hadoop Dynamic Metrics through JSON Rest interface
[ https://issues.apache.org/jira/browse/HBASE-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-6025: - Attachment: HBASE-6025-3.patch patch rebased on trunk Expose Hadoop Dynamic Metrics through JSON Rest interface - Key: HBASE-6025 URL: https://issues.apache.org/jira/browse/HBASE-6025 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-6025-0.patch, HBASE-6025-1.patch, HBASE-6025-2.patch, HBASE-6025-3.patch, hbase-jmx2.patch, hbase-jmx.patch, hbase-jmx.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6608) Fix for HBASE-6160, META entries from daughters can be deleted before parent entries, shouldn't compare HRegionInfo's
[
https://issues.apache.org/jira/browse/HBASE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438053#comment-13438053
]
Zhihong Ted Yu commented on HBASE-6608:
---
Integrated to 0.92 and 0.94 as well.
Thanks for the patch, Enis.
Fix for HBASE-6160, META entries from daughters can be deleted before parent
entries, shouldn't compare HRegionInfo's
-
Key: HBASE-6608
URL: https://issues.apache.org/jira/browse/HBASE-6608
Project: HBase
Issue Type: Bug
Components: client, regionserver
Affects Versions: 0.92.1, 0.96.0, 0.94.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 0.92.2, 0.96.0, 0.94.2
Attachments: 6608-v2.patch, hbase-6608_v1-0.92+0.94.patch,
hbase-6608_v1.patch
Our nightlies discovered that the patch for HBASE-6160 did not actually fix
the issue of META entries from daughters can be deleted before parent
entries. Instead of reopening the HBASE-6160, it is cleaner to track it
here.
The original issue is:
{quote}
HBASE-5986 fixed and issue, where the client sees the META entry for the
parent, but not the children. However, after the fix, we have seen the
following issue in tests:
Region A is split to - B, C
Region B is split to - D, E
After some time, META entry for B is deleted since it is not needed anymore,
but META entry for Region A stays in META (C still refers it). In this case,
the client throws RegionOfflineException for B.
{quote}
The problem with the fix seems to be that we keep and compare HRegionInfo's
in the HashSet at CatalogJanitor.java#scan(), but HRI that are compared are
not equal.
{code}
HashSetHRegionInfo parentNotCleaned = new HashSetHRegionInfo(); //regions
whose parents are still around
for (Map.EntryHRegionInfo, Result e : splitParents.entrySet()) {
if (!parentNotCleaned.contains(e.getKey()) cleanParent(e.getKey(),
e.getValue())) {
cleaned++;
} else {
...
{code}
In the above case, Meta row for region A will contain a serialized version of
B that is not offline. However Meta row for region B will contain a
serialized version of B that is offline (MetaEditor.offlineParentInMeta()
does that). So the deserialized version we put to HashSet and the
deserialized version we query contains() from HashSet are different in the
offline field, thus HRI.equals() fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6607) NullPointerException when accessing master web ui while master is initializing
[
https://issues.apache.org/jira/browse/HBASE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438059#comment-13438059
]
Jimmy Xiang commented on HBASE-6607:
That will be great. One more thing is that the server side is better not to
throw NPE.
If server side is not fully initialized, it is still better to show something
we have so far, so that we can tell from the ui what's going on in the server
side.
NullPointerException when accessing master web ui while master is initializing
--
Key: HBASE-6607
URL: https://issues.apache.org/jira/browse/HBASE-6607
Project: HBase
Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Priority: Trivial
Labels: noob
Probably I tried to check the master web ui too soon. I got some internal
error page. In the master log, there is such exception:
{noformat}
2012-08-17 16:06:25,146 ERROR org.mortbay.log: /master-status
java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.HMaster.isCatalogJanitorEnabled(HMaster.java:1213)
at
org.apache.hadoop.hbase.master.MasterStatusServlet.doGet(MasterStatusServlet.java:72)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
at
org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:835)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6608) Fix for HBASE-6160, META entries from daughters can be deleted before parent entries, shouldn't compare HRegionInfo's
[
https://issues.apache.org/jira/browse/HBASE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438068#comment-13438068
]
stack commented on HBASE-6608:
--
@Enis I'd say new issue. Thanks boss.
Fix for HBASE-6160, META entries from daughters can be deleted before parent
entries, shouldn't compare HRegionInfo's
-
Key: HBASE-6608
URL: https://issues.apache.org/jira/browse/HBASE-6608
Project: HBase
Issue Type: Bug
Components: client, regionserver
Affects Versions: 0.92.1, 0.96.0, 0.94.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 0.92.2, 0.96.0, 0.94.2
Attachments: 6608-v2.patch, hbase-6608_v1-0.92+0.94.patch,
hbase-6608_v1.patch
Our nightlies discovered that the patch for HBASE-6160 did not actually fix
the issue of META entries from daughters can be deleted before parent
entries. Instead of reopening the HBASE-6160, it is cleaner to track it
here.
The original issue is:
{quote}
HBASE-5986 fixed and issue, where the client sees the META entry for the
parent, but not the children. However, after the fix, we have seen the
following issue in tests:
Region A is split to - B, C
Region B is split to - D, E
After some time, META entry for B is deleted since it is not needed anymore,
but META entry for Region A stays in META (C still refers it). In this case,
the client throws RegionOfflineException for B.
{quote}
The problem with the fix seems to be that we keep and compare HRegionInfo's
in the HashSet at CatalogJanitor.java#scan(), but HRI that are compared are
not equal.
{code}
HashSetHRegionInfo parentNotCleaned = new HashSetHRegionInfo(); //regions
whose parents are still around
for (Map.EntryHRegionInfo, Result e : splitParents.entrySet()) {
if (!parentNotCleaned.contains(e.getKey()) cleanParent(e.getKey(),
e.getValue())) {
cleaned++;
} else {
...
{code}
In the above case, Meta row for region A will contain a serialized version of
B that is not offline. However Meta row for region B will contain a
serialized version of B that is offline (MetaEditor.offlineParentInMeta()
does that). So the deserialized version we put to HashSet and the
deserialized version we query contains() from HashSet are different in the
offline field, thus HRI.equals() fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6415) Add Rat checking to the pre-checkin script.
[ https://issues.apache.org/jira/browse/HBASE-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark resolved HBASE-6415. -- Resolution: Cannot Reproduce Seems to work now. Add Rat checking to the pre-checkin script. --- Key: HBASE-6415 URL: https://issues.apache.org/jira/browse/HBASE-6415 Project: HBase Issue Type: Task Reporter: Elliott Clark Assignee: Elliott Clark -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] s...@hotmail.com updated HBASE-6584: Attachment: patch2.diff Patch to enable debugging of the issue. The code is temporary and will be removed after investigation is complete. A corresponding JIRA will be filed if patch is accepted, to remove the code. Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch, patch2.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6603) RegionMetricsStorage.incrNumericMetric is called too often
[ https://issues.apache.org/jira/browse/HBASE-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6603: - Attachment: 6503-0.96.txt Here's a version of the HBASE-6217 patch for trunk. In an extreme test with Gets of 60.000 columns the time went from about 164ms/iteration to 124ms. RegionMetricsStorage.incrNumericMetric is called too often -- Key: HBASE-6603 URL: https://issues.apache.org/jira/browse/HBASE-6603 Project: HBase Issue Type: Bug Components: performance Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0, 0.94.2 Attachments: 6503-0.96.txt Running an HBase scan load through the profiler revealed that RegionMetricsStorage.incrNumericMetric is called way too often. It turns out that we make this call for *each* KV in StoreScanner.next(...). Incrementing AtomicLong requires expensive memory barriers. The observation here is that StoreScanner.next(...) can maintain a simple long in its internal loop and only update the metric upon exit. Thus the AtomicLong is not updated nearly as often. That cuts about 10% runtime from scan only load (I'll quantify this better soon). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438088#comment-13438088 ] nkeywal commented on HBASE-6584: I'm surprised, the tests are executed in parallel (4 simultaneously), so if multiple tests require the same fixed port, they should get conflicts quite often. Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch, patch2.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5251) Some commands return 0 rows when 0 rows were processed successfully
[ https://issues.apache.org/jira/browse/HBASE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438096#comment-13438096 ] Jesse Yates commented on HBASE-5251: A couple of comments. bq. +#Formatter is now defined at command group level. This is extraneous - comments in the Shell.rb or HIRB should make this clear. Instead, this serves to just reference old code that is no longer present, making it more confusing than helpful. Something better would be a link to the method in Shell that takes a formmatter. bq. AdminFormatter is used for all non row specific operations (command groups) such as version, status etc. What does it actually output for these operations? Otherwise, looks good Sameer. Some commands return 0 rows when 0 rows were processed successfully --- Key: HBASE-5251 URL: https://issues.apache.org/jira/browse/HBASE-5251 Project: HBase Issue Type: Bug Components: shell Affects Versions: 0.90.5 Reporter: David S. Wang Assignee: Sameer Vaishampayan Priority: Minor Labels: noob Attachments: patch7.diff, patch8.diff, patch9.diff From the hbase shell, I see this: hbase(main):049:0 scan 't1' ROW COLUMN+CELL r1 column=f1:c1, timestamp=1327104295560, value=value r1 column=f1:c2, timestamp=1327104330625, value=value 1 row(s) in 0.0300 seconds hbase(main):050:0 deleteall 't1', 'r1' 0 row(s) in 0.0080 seconds == I expected this to read 2 row(s) hbase(main):051:0 scan 't1' ROW COLUMN+CELL 0 row(s) in 0.0090 seconds I expected the deleteall command to return 1 row(s) instead of 0, because 1 row was deleted. Similar behavior for delete and some other commands. Some commands such as put work fine. Looking at the ruby shell code, it seems that formatter.footer() is called even for commands that will not actually increment the number of rows reported, such as deletes. Perhaps there should be another similar function to formatter.footer(), but that will not print out @row_count. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6601) TestImportExport failing against Hadoop 2
[ https://issues.apache.org/jira/browse/HBASE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438095#comment-13438095 ] Scott Forman commented on HBASE-6601: - I am attaching patches HBASE-6601-trunk-changeFunctSign.patch and HBASE-6601-0.94-changeFunctSign.patch to respond to the comments from Andy Purtell. These patches have changed the name of the addConfigurationValues function to copyConfigurationValues, and this function now takes the source and destination Configuration instances. TestImportExport failing against Hadoop 2 - Key: HBASE-6601 URL: https://issues.apache.org/jira/browse/HBASE-6601 Project: HBase Issue Type: Bug Reporter: Scott Forman Attachments: HBASE-6601-0.94.patch, HBASE-6601-trunk.patch TestImportExport.testSimpleCase is failing with the following exception: java.lang.reflect.UndeclaredThrowableException at org.apache.hadoop.yarn.exceptions.impl.pb.YarnRemoteExceptionPBImpl.unwrapAndThrowException(YarnRemoteExceptionPBImpl.java:135) at org.apache.hadoop.yarn.api.impl.pb.client.ClientRMProtocolPBClientImpl.getNewApplication(ClientRMProtocolPBClientImpl.java:134) at org.apache.hadoop.mapred.ResourceMgrDelegate.getNewJobID(ResourceMgrDelegate.java:181) at org.apache.hadoop.mapred.YARNRunner.getNewJobID(YARNRunner.java:214) at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:337) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1216) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1213) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1332) at org.apache.hadoop.mapreduce.Job.submit(Job.java:1213) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1234) at org.apache.hadoop.hbase.mapreduce.TestImportExport.testSimpleCase(TestImportExport.java:114) Caused by: com.google.protobuf.ServiceException: java.net.ConnectException: Call From asurus.iridiant.net/50.23.172.109 to 0.0.0.0:8032 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused The problem is that a connection to the YARN resource manager is being made at the default address (0.0.0.0:8032) instead of the actual address that it is listening on. This test creates two miniclusters, one for map reduce and one for hbase, and each minicluster has its own Configuration. The Configuration for the map reduce minicluster has the correct resource manager address, while the Configuration for the hbase minicluster has the default resource manager address. Since the test is using only the Configuration from the hbase minicluster, it sees the default address for the resource manager, instead of the actual address. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6601) TestImportExport failing against Hadoop 2
[ https://issues.apache.org/jira/browse/HBASE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Forman updated HBASE-6601: Attachment: HBASE-6601-0.94-changeFunctSign.patch patch file for 0.94 branch with new function signature TestImportExport failing against Hadoop 2 - Key: HBASE-6601 URL: https://issues.apache.org/jira/browse/HBASE-6601 Project: HBase Issue Type: Bug Reporter: Scott Forman Attachments: HBASE-6601-0.94-changeFunctSign.patch, HBASE-6601-0.94.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk.patch TestImportExport.testSimpleCase is failing with the following exception: java.lang.reflect.UndeclaredThrowableException at org.apache.hadoop.yarn.exceptions.impl.pb.YarnRemoteExceptionPBImpl.unwrapAndThrowException(YarnRemoteExceptionPBImpl.java:135) at org.apache.hadoop.yarn.api.impl.pb.client.ClientRMProtocolPBClientImpl.getNewApplication(ClientRMProtocolPBClientImpl.java:134) at org.apache.hadoop.mapred.ResourceMgrDelegate.getNewJobID(ResourceMgrDelegate.java:181) at org.apache.hadoop.mapred.YARNRunner.getNewJobID(YARNRunner.java:214) at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:337) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1216) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1213) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1332) at org.apache.hadoop.mapreduce.Job.submit(Job.java:1213) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1234) at org.apache.hadoop.hbase.mapreduce.TestImportExport.testSimpleCase(TestImportExport.java:114) Caused by: com.google.protobuf.ServiceException: java.net.ConnectException: Call From asurus.iridiant.net/50.23.172.109 to 0.0.0.0:8032 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused The problem is that a connection to the YARN resource manager is being made at the default address (0.0.0.0:8032) instead of the actual address that it is listening on. This test creates two miniclusters, one for map reduce and one for hbase, and each minicluster has its own Configuration. The Configuration for the map reduce minicluster has the correct resource manager address, while the Configuration for the hbase minicluster has the default resource manager address. Since the test is using only the Configuration from the hbase minicluster, it sees the default address for the resource manager, instead of the actual address. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6601) TestImportExport failing against Hadoop 2
[ https://issues.apache.org/jira/browse/HBASE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Forman updated HBASE-6601: Attachment: HBASE-6601-trunk-changeFunctSign.patch TestImportExport failing against Hadoop 2 - Key: HBASE-6601 URL: https://issues.apache.org/jira/browse/HBASE-6601 Project: HBase Issue Type: Bug Reporter: Scott Forman Attachments: HBASE-6601-0.94-changeFunctSign.patch, HBASE-6601-0.94.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk.patch TestImportExport.testSimpleCase is failing with the following exception: java.lang.reflect.UndeclaredThrowableException at org.apache.hadoop.yarn.exceptions.impl.pb.YarnRemoteExceptionPBImpl.unwrapAndThrowException(YarnRemoteExceptionPBImpl.java:135) at org.apache.hadoop.yarn.api.impl.pb.client.ClientRMProtocolPBClientImpl.getNewApplication(ClientRMProtocolPBClientImpl.java:134) at org.apache.hadoop.mapred.ResourceMgrDelegate.getNewJobID(ResourceMgrDelegate.java:181) at org.apache.hadoop.mapred.YARNRunner.getNewJobID(YARNRunner.java:214) at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:337) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1216) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1213) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1332) at org.apache.hadoop.mapreduce.Job.submit(Job.java:1213) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1234) at org.apache.hadoop.hbase.mapreduce.TestImportExport.testSimpleCase(TestImportExport.java:114) Caused by: com.google.protobuf.ServiceException: java.net.ConnectException: Call From asurus.iridiant.net/50.23.172.109 to 0.0.0.0:8032 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused The problem is that a connection to the YARN resource manager is being made at the default address (0.0.0.0:8032) instead of the actual address that it is listening on. This test creates two miniclusters, one for map reduce and one for hbase, and each minicluster has its own Configuration. The Configuration for the map reduce minicluster has the correct resource manager address, while the Configuration for the hbase minicluster has the default resource manager address. Since the test is using only the Configuration from the hbase minicluster, it sees the default address for the resource manager, instead of the actual address. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6601) TestImportExport failing against Hadoop 2
[ https://issues.apache.org/jira/browse/HBASE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Forman updated HBASE-6601: Attachment: HBASE-6601-trunk-changeFunctSign.patch TestImportExport failing against Hadoop 2 - Key: HBASE-6601 URL: https://issues.apache.org/jira/browse/HBASE-6601 Project: HBase Issue Type: Bug Reporter: Scott Forman Attachments: HBASE-6601-0.94-changeFunctSign.patch, HBASE-6601-0.94.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk.patch TestImportExport.testSimpleCase is failing with the following exception: java.lang.reflect.UndeclaredThrowableException at org.apache.hadoop.yarn.exceptions.impl.pb.YarnRemoteExceptionPBImpl.unwrapAndThrowException(YarnRemoteExceptionPBImpl.java:135) at org.apache.hadoop.yarn.api.impl.pb.client.ClientRMProtocolPBClientImpl.getNewApplication(ClientRMProtocolPBClientImpl.java:134) at org.apache.hadoop.mapred.ResourceMgrDelegate.getNewJobID(ResourceMgrDelegate.java:181) at org.apache.hadoop.mapred.YARNRunner.getNewJobID(YARNRunner.java:214) at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:337) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1216) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1213) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1332) at org.apache.hadoop.mapreduce.Job.submit(Job.java:1213) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1234) at org.apache.hadoop.hbase.mapreduce.TestImportExport.testSimpleCase(TestImportExport.java:114) Caused by: com.google.protobuf.ServiceException: java.net.ConnectException: Call From asurus.iridiant.net/50.23.172.109 to 0.0.0.0:8032 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused The problem is that a connection to the YARN resource manager is being made at the default address (0.0.0.0:8032) instead of the actual address that it is listening on. This test creates two miniclusters, one for map reduce and one for hbase, and each minicluster has its own Configuration. The Configuration for the map reduce minicluster has the correct resource manager address, while the Configuration for the hbase minicluster has the default resource manager address. Since the test is using only the Configuration from the hbase minicluster, it sees the default address for the resource manager, instead of the actual address. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6601) TestImportExport failing against Hadoop 2
[ https://issues.apache.org/jira/browse/HBASE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438103#comment-13438103 ] Scott Forman commented on HBASE-6601: - The 2 attachments for HBASE-6601-trunk-changeFunctSign.patch are duplicates, so the 2nd attachment can be ignored. TestImportExport failing against Hadoop 2 - Key: HBASE-6601 URL: https://issues.apache.org/jira/browse/HBASE-6601 Project: HBase Issue Type: Bug Reporter: Scott Forman Attachments: HBASE-6601-0.94-changeFunctSign.patch, HBASE-6601-0.94.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk.patch TestImportExport.testSimpleCase is failing with the following exception: java.lang.reflect.UndeclaredThrowableException at org.apache.hadoop.yarn.exceptions.impl.pb.YarnRemoteExceptionPBImpl.unwrapAndThrowException(YarnRemoteExceptionPBImpl.java:135) at org.apache.hadoop.yarn.api.impl.pb.client.ClientRMProtocolPBClientImpl.getNewApplication(ClientRMProtocolPBClientImpl.java:134) at org.apache.hadoop.mapred.ResourceMgrDelegate.getNewJobID(ResourceMgrDelegate.java:181) at org.apache.hadoop.mapred.YARNRunner.getNewJobID(YARNRunner.java:214) at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:337) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1216) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1213) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1332) at org.apache.hadoop.mapreduce.Job.submit(Job.java:1213) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1234) at org.apache.hadoop.hbase.mapreduce.TestImportExport.testSimpleCase(TestImportExport.java:114) Caused by: com.google.protobuf.ServiceException: java.net.ConnectException: Call From asurus.iridiant.net/50.23.172.109 to 0.0.0.0:8032 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused The problem is that a connection to the YARN resource manager is being made at the default address (0.0.0.0:8032) instead of the actual address that it is listening on. This test creates two miniclusters, one for map reduce and one for hbase, and each minicluster has its own Configuration. The Configuration for the map reduce minicluster has the correct resource manager address, while the Configuration for the hbase minicluster has the default resource manager address. Since the test is using only the Configuration from the hbase minicluster, it sees the default address for the resource manager, instead of the actual address. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6025) Expose Hadoop Dynamic Metrics through JSON Rest interface
[ https://issues.apache.org/jira/browse/HBASE-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438102#comment-13438102 ] Hadoop QA commented on HBASE-6025: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12541620/HBASE-6025-3.patch against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. 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. +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile. +1 javadoc. The javadoc tool did not generate any warning messages. -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 6 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.hbase.TestMultiVersions org.apache.hadoop.hbase.master.TestSplitLogManager Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2629//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2629//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2629//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2629//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2629//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2629//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2629//console This message is automatically generated. Expose Hadoop Dynamic Metrics through JSON Rest interface - Key: HBASE-6025 URL: https://issues.apache.org/jira/browse/HBASE-6025 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Assignee: Elliott Clark Attachments: HBASE-6025-0.patch, HBASE-6025-1.patch, HBASE-6025-2.patch, HBASE-6025-3.patch, hbase-jmx2.patch, hbase-jmx.patch, hbase-jmx.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6603) RegionMetricsStorage.incrNumericMetric is called too often
[ https://issues.apache.org/jira/browse/HBASE-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438105#comment-13438105 ] stack commented on HBASE-6603: -- +1 RegionMetricsStorage.incrNumericMetric is called too often -- Key: HBASE-6603 URL: https://issues.apache.org/jira/browse/HBASE-6603 Project: HBase Issue Type: Bug Components: performance Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0, 0.94.2 Attachments: 6503-0.96.txt Running an HBase scan load through the profiler revealed that RegionMetricsStorage.incrNumericMetric is called way too often. It turns out that we make this call for *each* KV in StoreScanner.next(...). Incrementing AtomicLong requires expensive memory barriers. The observation here is that StoreScanner.next(...) can maintain a simple long in its internal loop and only update the metric upon exit. Thus the AtomicLong is not updated nearly as often. That cuts about 10% runtime from scan only load (I'll quantify this better soon). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6436) Netty should be moved off of snapshots.
[ https://issues.apache.org/jira/browse/HBASE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6436: - Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to trunk. Thanks for the patch Elliott. Netty should be moved off of snapshots. --- Key: HBASE-6436 URL: https://issues.apache.org/jira/browse/HBASE-6436 Project: HBase Issue Type: Task Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.96.0 Attachments: HBASE-6436-0.patch Netty is currently at 3.5.0.final-SNAPSHOT the final 3.5.0.Final should be used when possible so that repositories aren't queried when not needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6616) test failure in TestDelayedRpc#testTooManyDelayedRpcs
[ https://issues.apache.org/jira/browse/HBASE-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438124#comment-13438124 ] stack commented on HBASE-6616: -- Ming, what does that fix it? test failure in TestDelayedRpc#testTooManyDelayedRpcs -- Key: HBASE-6616 URL: https://issues.apache.org/jira/browse/HBASE-6616 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.92.1 Reporter: Ming Ma Assignee: Ming Ma Attachments: HBASE-6616.patch java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.hadoop.hbase.ipc.TestDelayedRpc.testTooManyDelayedRpcs(TestDelayedRpc.java:146) assertTrue(listAppender.getMessages().isEmpty()); listAppender.getMessages returned something like [Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting Thread-17, Starting IPC Server listener on 41965, IPC Server Responder: starting, IPC Server listener on 41965: starting, IPC Server handler 0 on 41965: starting] That comes from HBaseServer.java, Reader class LOG.info(Starting + getName()); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6618) Implement FuzzyRowFilter with ranges support
Alex Baranau created HBASE-6618: --- Summary: Implement FuzzyRowFilter with ranges support Key: HBASE-6618 URL: https://issues.apache.org/jira/browse/HBASE-6618 Project: HBase Issue Type: New Feature Components: filters Reporter: Alex Baranau Priority: Minor Apart from current ability to specify fuzzy row filter e.g. for userId_actionId format as _0004 (where 0004 - actionId) it would be great to also have ability to specify the fuzzy range , e.g. _0004, ..., _0099. See initial discussion here: http://search-hadoop.com/m/WVLJdX0Z65 Note: currently it is possible to provide multiple fuzzy row rules to existing FuzzyRowFilter, but in case when the range is big (contains thousands of values) it is not efficient. Filter should perform efficient fast-forwarding during the scan (this is what distinguishes it from regex row filter). While such functionality may seem like a proper fit for custom filter (i.e. not including into standard filter set) it looks like the filter may be very re-useable. We may judge based on the implementation that will hopefully be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6619) Do no unregister and re-register interest ops in RPC
Karthik Ranganathan created HBASE-6619: -- Summary: Do no unregister and re-register interest ops in RPC Key: HBASE-6619 URL: https://issues.apache.org/jira/browse/HBASE-6619 Project: HBase Issue Type: Bug Components: ipc Reporter: Karthik Ranganathan Assignee: Michal Gregorczyk While investigating perf of HBase, Michal noticed that we could cut about 5-40% (depending on number of threads) from the total get time in the RPC on the server side if we eliminated re-registering for interest ops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6524) Hooks for hbase tracing
[ https://issues.apache.org/jira/browse/HBASE-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438135#comment-13438135 ] stack commented on HBASE-6524: -- @Jonathan Sorry for delayed review. Thanks for looking at the findbugs and javac stuff. Probably not you as you figured. On the patch: You change hbase-site.xml license indent. Would suggest you don't do that. I can fix that on commit. Is htrace up in mvn central? Why do we create a new instance of TInfo here rather than just use the one we have (presuming hasTinfo means the request has a TInfo?)? +call = new Call(id, param, this, responder, callSize, new TraceInfo( +request.getTinfo().getTraceId(), request.getTinfo().getParentId())); Should say what a spanReceiverHost is. When I load receivers, what kind of resources are we allocating? Is that all it takes to add tracing? That is pretty sweet. I'd say this patch is close to commit. See comments above. You going to do a bit of a blog w/ fancy tracing pictures?Something we could reference from the refguide? Any more pretty pictures for us? Hooks for hbase tracing --- Key: HBASE-6524 URL: https://issues.apache.org/jira/browse/HBASE-6524 Project: HBase Issue Type: Sub-task Reporter: Jonathan Leavitt Attachments: htracehooks1.diff Includes the hooks that use [htrace|http://www.github.com/cloudera/htrace] library to add dapper-like tracing to hbase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6618) Implement FuzzyRowFilter with ranges support
[ https://issues.apache.org/jira/browse/HBASE-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438134#comment-13438134 ] Alex Baranau commented on HBASE-6618: - Just an idea. May be we should try improve existing FuzzyRowFilter by allowing to specify each fuzzy rule with: * fuzzy key start * fuzzy key end this is currently missing in FuzzyRowFilter * mask This looks flexible enough to me. E.g. one could specify rule (_0001_-_0099_)???(_001-_099), i.e. any 4 bytesany 6 bytes value between _0001_ and _0099_any 3 bytesany 4 bytes value between _001 and _099 with this definition: * _0001_???_001 * _0099_???_099 currently missing * 00111 In this case any sequence of fixed positions treated as one n-bytes value. -- Alternatively, such fuzzy rule can be specified as list of parts, each part being one of: * n fuzzy bytes * start/stop key part range (of the same length) This might be closer to human-readable definition, though the former one could be easier to deal with. Anil, as you expressed willing to work on this, what are your thoughts? May be you have smth different in your mind? Implement FuzzyRowFilter with ranges support Key: HBASE-6618 URL: https://issues.apache.org/jira/browse/HBASE-6618 Project: HBase Issue Type: New Feature Components: filters Reporter: Alex Baranau Priority: Minor Apart from current ability to specify fuzzy row filter e.g. for userId_actionId format as _0004 (where 0004 - actionId) it would be great to also have ability to specify the fuzzy range , e.g. _0004, ..., _0099. See initial discussion here: http://search-hadoop.com/m/WVLJdX0Z65 Note: currently it is possible to provide multiple fuzzy row rules to existing FuzzyRowFilter, but in case when the range is big (contains thousands of values) it is not efficient. Filter should perform efficient fast-forwarding during the scan (this is what distinguishes it from regex row filter). While such functionality may seem like a proper fit for custom filter (i.e. not including into standard filter set) it looks like the filter may be very re-useable. We may judge based on the implementation that will hopefully be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6584) Test flappers due to port 60000 already in use.
[ https://issues.apache.org/jira/browse/HBASE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438136#comment-13438136 ] Hadoop QA commented on HBASE-6584: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12541626/patch2.diff against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile. +1 javadoc. The javadoc tool did not generate any warning messages. -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 6 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.hbase.client.TestFromClientSideWithCoprocessor Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2631//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2631//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2631//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2631//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2631//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2631//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2631//console This message is automatically generated. Test flappers due to port 6 already in use. --- Key: HBASE-6584 URL: https://issues.apache.org/jira/browse/HBASE-6584 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.0 Reporter: s...@hotmail.com Priority: Critical Attachments: HBASE-6584_trunk_2.patch, HBASE-6584_trunk.patch, HBASE-6584_trunk.patch, patch2.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6619) Do no unregister and re-register interest ops in RPC
[ https://issues.apache.org/jira/browse/HBASE-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438137#comment-13438137 ] stack commented on HBASE-6619: -- Sounds nice. Whats an interest op? Do no unregister and re-register interest ops in RPC Key: HBASE-6619 URL: https://issues.apache.org/jira/browse/HBASE-6619 Project: HBase Issue Type: Bug Components: ipc Reporter: Karthik Ranganathan Assignee: Michal Gregorczyk While investigating perf of HBase, Michal noticed that we could cut about 5-40% (depending on number of threads) from the total get time in the RPC on the server side if we eliminated re-registering for interest ops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3996) Support multiple tables and scanners as input to the mapper in map/reduce jobs
[ https://issues.apache.org/jira/browse/HBASE-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438141#comment-13438141 ] stack commented on HBASE-3996: -- Yes, packaging/naming issues. Support multiple tables and scanners as input to the mapper in map/reduce jobs -- Key: HBASE-3996 URL: https://issues.apache.org/jira/browse/HBASE-3996 Project: HBase Issue Type: Improvement Components: mapreduce Reporter: Eran Kutner Assignee: Eran Kutner Fix For: 0.96.0, 0.94.2 Attachments: 3996-v2.txt, 3996-v3.txt, 3996-v4.txt, 3996-v5.txt, 3996-v6.txt, 3996-v7.txt, HBase-3996.patch It seems that in many cases feeding data from multiple tables or multiple scanners on a single table can save a lot of time when running map/reduce jobs. I propose a new MultiTableInputFormat class that would allow doing this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6601) TestImportExport failing against Hadoop 2
[ https://issues.apache.org/jira/browse/HBASE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438144#comment-13438144 ] Hadoop QA commented on HBASE-6601: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12541633/HBASE-6601-trunk-changeFunctSign.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile. +1 javadoc. The javadoc tool did not generate any warning messages. -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 6 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort org.apache.hadoop.hbase.io.encoding.TestUpgradeFromHFileV1ToEncoding Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2632//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2632//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2632//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2632//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2632//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2632//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2632//console This message is automatically generated. TestImportExport failing against Hadoop 2 - Key: HBASE-6601 URL: https://issues.apache.org/jira/browse/HBASE-6601 Project: HBase Issue Type: Bug Reporter: Scott Forman Attachments: HBASE-6601-0.94-changeFunctSign.patch, HBASE-6601-0.94.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk-changeFunctSign.patch, HBASE-6601-trunk.patch TestImportExport.testSimpleCase is failing with the following exception: java.lang.reflect.UndeclaredThrowableException at org.apache.hadoop.yarn.exceptions.impl.pb.YarnRemoteExceptionPBImpl.unwrapAndThrowException(YarnRemoteExceptionPBImpl.java:135) at org.apache.hadoop.yarn.api.impl.pb.client.ClientRMProtocolPBClientImpl.getNewApplication(ClientRMProtocolPBClientImpl.java:134) at org.apache.hadoop.mapred.ResourceMgrDelegate.getNewJobID(ResourceMgrDelegate.java:181) at org.apache.hadoop.mapred.YARNRunner.getNewJobID(YARNRunner.java:214) at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:337) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1216) at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1213) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1332) at org.apache.hadoop.mapreduce.Job.submit(Job.java:1213) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1234) at org.apache.hadoop.hbase.mapreduce.TestImportExport.testSimpleCase(TestImportExport.java:114) Caused by: com.google.protobuf.ServiceException: java.net.ConnectException: Call From asurus.iridiant.net/50.23.172.109 to 0.0.0.0:8032 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused The problem is that a connection to the YARN resource manager is being made at the default address (0.0.0.0:8032) instead of the actual address that it is listening on. This test creates two miniclusters, one for map reduce and one for hbase, and each minicluster has its own Configuration. The Configuration for the map reduce minicluster has the correct resource manager address, while the Configuration for the hbase minicluster has the default resource manager address. Since the test is using only the Configuration from the hbase minicluster, it sees the default
[jira] [Commented] (HBASE-6609) Startcluster fails on windows (references ls)
[
https://issues.apache.org/jira/browse/HBASE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438145#comment-13438145
]
stack commented on HBASE-6609:
--
Seems like issue in hadoop Shell class. You running in a cygwin context? I'd
say close this issue and raise the problem on the list.
Startcluster fails on windows (references ls)
---
Key: HBASE-6609
URL: https://issues.apache.org/jira/browse/HBASE-6609
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.1
Environment: Windows 7 64-bit
Eclipse
Reporter: Archimedes Trajano
When starting up the cluster using
@BeforeClass
public static void setUp() throws Exception {
utility = new HBaseTestingUtility();
utility.startMiniCluster();
}
I get the following stack trace under Windows in Eclipse. Note it is looking
for ls which is not present under Windows.
java.lang.RuntimeException: Error while running command to get file
permissions : java.io.IOException: Cannot run program ls: CreateProcess
error=2, The system cannot find the file specified
at java.lang.ProcessBuilder.start(Unknown Source)
at org.apache.hadoop.util.Shell.runCommand(Shell.java:200)
at org.apache.hadoop.util.Shell.run(Shell.java:182)
at
org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:375)
at org.apache.hadoop.util.Shell.execCommand(Shell.java:461)
at org.apache.hadoop.util.Shell.execCommand(Shell.java:444)
at org.apache.hadoop.fs.FileUtil.execCommand(FileUtil.java:710)
at
org.apache.hadoop.fs.RawLocalFileSystem$RawLocalFileStatus.loadPermissionInfo(RawLocalFileSystem.java:443)
at
org.apache.hadoop.fs.RawLocalFileSystem$RawLocalFileStatus.getPermission(RawLocalFileSystem.java:418)
at
org.apache.hadoop.util.DiskChecker.mkdirsWithExistsAndPermissionCheck(DiskChecker.java:146)
at org.apache.hadoop.util.DiskChecker.checkDir(DiskChecker.java:162)
at
org.apache.hadoop.hdfs.server.datanode.DataNode.makeInstance(DataNode.java:1574)
at
org.apache.hadoop.hdfs.server.datanode.DataNode.instantiateDataNode(DataNode.java:1521)
at
org.apache.hadoop.hdfs.server.datanode.DataNode.instantiateDataNode(DataNode.java:1496)
at
org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes(MiniDFSCluster.java:417)
at org.apache.hadoop.hdfs.MiniDFSCluster.init(MiniDFSCluster.java:280)
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniDFSCluster(HBaseTestingUtility.java:430)
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:598)
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:554)
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:523)
at
net.trajano.nosql.hbase.test.FrameworkTest.setUp(FrameworkTest.java:17)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find
the file specified
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.init(Unknown Source)
at java.lang.ProcessImpl.start(Unknown Source)
... 37 more
at
org.apache.hadoop.fs.RawLocalFileSystem$RawLocalFileStatus.loadPermissionInfo(RawLocalFileSystem.java:468)
at
[jira] [Commented] (HBASE-6618) Implement FuzzyRowFilter with ranges support
[ https://issues.apache.org/jira/browse/HBASE-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438147#comment-13438147 ] Alex Baranau commented on HBASE-6618: - Sorry for the spam, for some reason I cannot edit the comment and JIRA broke formatting for the text pieces of my previous comment (I should have checked that first, sorry). This is how it supposed to look: Just an idea. May be we should try improve existing FuzzyRowFilter by allowing to specify each fuzzy rule with: * fuzzy key start * fuzzy key end this is currently missing in FuzzyRowFilter * mask This looks flexible enough to me. E.g. one could specify rule ?\?\??(0001 - 0999)???(001 - 099), i.e. any 4 bytesany 4 bytes value between 0001 and 0999any 3 bytesany 3 bytes value between 001 and 099 with this definition: * ?\?\??0001???001 * ?\?\??0999???099 currently missing * 111000 In this case any sequence of fixed positions treated as one n-bytes value. Alternatively, such fuzzy rule can be specified as list of parts, each part being one of: * n fuzzy bytes * start/stop key part range (of the same length) This might be closer to human-readable definition, though the former one could be easier to deal with. Anil, as you expressed willing to work on this, what are your thoughts? May be you have smth different in your mind? Implement FuzzyRowFilter with ranges support Key: HBASE-6618 URL: https://issues.apache.org/jira/browse/HBASE-6618 Project: HBase Issue Type: New Feature Components: filters Reporter: Alex Baranau Priority: Minor Apart from current ability to specify fuzzy row filter e.g. for userId_actionId format as _0004 (where 0004 - actionId) it would be great to also have ability to specify the fuzzy range , e.g. _0004, ..., _0099. See initial discussion here: http://search-hadoop.com/m/WVLJdX0Z65 Note: currently it is possible to provide multiple fuzzy row rules to existing FuzzyRowFilter, but in case when the range is big (contains thousands of values) it is not efficient. Filter should perform efficient fast-forwarding during the scan (this is what distinguishes it from regex row filter). While such functionality may seem like a proper fit for custom filter (i.e. not including into standard filter set) it looks like the filter may be very re-useable. We may judge based on the implementation that will hopefully be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6582) Code generation does run under m2eclipse
[ https://issues.apache.org/jira/browse/HBASE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6582: - Resolution: Fixed Fix Version/s: 0.96.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to trunk. Should I put it in 0.94 Michael? Code generation does run under m2eclipse Key: HBASE-6582 URL: https://issues.apache.org/jira/browse/HBASE-6582 Project: HBase Issue Type: Bug Reporter: Michael Drzal Assignee: Michael Drzal Priority: Minor Fix For: 0.96.0 Attachments: HBASE-6582.patch When going through the instructions on http://hbase.apache.org/book/ides.html, the build will fail in eclipse because none of the sources are generated. After looking at our pom and reading http://wiki.eclipse.org/M2E_compatible_maven_plugins, we are telling m2eclipse to ignore the avro and jamon plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6608) Fix for HBASE-6160, META entries from daughters can be deleted before parent entries, shouldn't compare HRegionInfo's
[
https://issues.apache.org/jira/browse/HBASE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438162#comment-13438162
]
Hudson commented on HBASE-6608:
---
Integrated in HBase-0.94 #407 (See
[https://builds.apache.org/job/HBase-0.94/407/])
HBASE-6608 Fix for HBASE-6160, META entries from daughters can be deleted
before parent entries, shouldn't compare HRegionInfo's (Enis) (Revision 1375158)
Result = SUCCESS
tedyu :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java
Fix for HBASE-6160, META entries from daughters can be deleted before parent
entries, shouldn't compare HRegionInfo's
-
Key: HBASE-6608
URL: https://issues.apache.org/jira/browse/HBASE-6608
Project: HBase
Issue Type: Bug
Components: client, regionserver
Affects Versions: 0.92.1, 0.96.0, 0.94.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 0.92.2, 0.96.0, 0.94.2
Attachments: 6608-v2.patch, hbase-6608_v1-0.92+0.94.patch,
hbase-6608_v1.patch
Our nightlies discovered that the patch for HBASE-6160 did not actually fix
the issue of META entries from daughters can be deleted before parent
entries. Instead of reopening the HBASE-6160, it is cleaner to track it
here.
The original issue is:
{quote}
HBASE-5986 fixed and issue, where the client sees the META entry for the
parent, but not the children. However, after the fix, we have seen the
following issue in tests:
Region A is split to - B, C
Region B is split to - D, E
After some time, META entry for B is deleted since it is not needed anymore,
but META entry for Region A stays in META (C still refers it). In this case,
the client throws RegionOfflineException for B.
{quote}
The problem with the fix seems to be that we keep and compare HRegionInfo's
in the HashSet at CatalogJanitor.java#scan(), but HRI that are compared are
not equal.
{code}
HashSetHRegionInfo parentNotCleaned = new HashSetHRegionInfo(); //regions
whose parents are still around
for (Map.EntryHRegionInfo, Result e : splitParents.entrySet()) {
if (!parentNotCleaned.contains(e.getKey()) cleanParent(e.getKey(),
e.getValue())) {
cleaned++;
} else {
...
{code}
In the above case, Meta row for region A will contain a serialized version of
B that is not offline. However Meta row for region B will contain a
serialized version of B that is offline (MetaEditor.offlineParentInMeta()
does that). So the deserialized version we put to HashSet and the
deserialized version we query contains() from HashSet are different in the
offline field, thus HRI.equals() fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6160) META entries from daughters can be deleted before parent entries
[ https://issues.apache.org/jira/browse/HBASE-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438163#comment-13438163 ] Hudson commented on HBASE-6160: --- Integrated in HBase-0.94 #407 (See [https://builds.apache.org/job/HBase-0.94/407/]) HBASE-6608 Fix for HBASE-6160, META entries from daughters can be deleted before parent entries, shouldn't compare HRegionInfo's (Enis) (Revision 1375158) Result = SUCCESS tedyu : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java META entries from daughters can be deleted before parent entries Key: HBASE-6160 URL: https://issues.apache.org/jira/browse/HBASE-6160 Project: HBase Issue Type: Bug Components: client, regionserver Affects Versions: 0.92.2, 0.94.0, 0.96.0 Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.92.2, 0.94.1 Attachments: HBASE-6160_v1.patch, HBASE-6160v2092.txt, HBASE-6160_v2.patch, HBASE-6160_v2.patch HBASE-5986 fixed and issue, where the client sees the META entry for the parent, but not the children. However, after the fix, we have seen the following issue in tests: Region A is split to - B, C Region B is split to - D, E After some time, META entry for B is deleted since it is not needed anymore, but META entry for Region A stays in META (C still refers it). In this case, the client throws RegionOfflineException for B. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6378) the javadoc of setEnabledTable maybe not describe accurately
[
https://issues.apache.org/jira/browse/HBASE-6378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-6378:
-
Resolution: Fixed
Assignee: David S. Wang
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Committed to 0.94 and trunk. Thanks for patch David.
the javadoc of setEnabledTable maybe not describe accurately
--
Key: HBASE-6378
URL: https://issues.apache.org/jira/browse/HBASE-6378
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.94.0
Reporter: zhou wenjian
Assignee: David S. Wang
Fix For: 0.94.2
Attachments: 6378.patch, HBASE-6378.patch, HBASE-6378-trunk.patch
/**
* Sets the ENABLED state in the cache and deletes the zookeeper node. Fails
* silently if the node is not in enabled in zookeeper
*
* @param tableName
* @throws KeeperException
*/
public void setEnabledTable(final String tableName) throws KeeperException {
setTableState(tableName, TableState.ENABLED);
}
When setEnabledTable occours ,It will update the cache and the zookeeper
node,rather than to delete the zk node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6503) HBase Shell Documentation For DROP Is Outdated
[ https://issues.apache.org/jira/browse/HBASE-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6503: - Resolution: Fixed Fix Version/s: 0.94.2 0.92.2 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Applied to 0.92, 0.94, and to trunk. Thanks for the patch Paul. HBase Shell Documentation For DROP Is Outdated -- Key: HBASE-6503 URL: https://issues.apache.org/jira/browse/HBASE-6503 Project: HBase Issue Type: Bug Reporter: Paul Cavallaro Assignee: Paul Cavallaro Priority: Trivial Fix For: 0.92.2, 0.94.2 Attachments: HBASE-6503-example.patch, HBASE-6503.patch HBase Shell help documentation for the drop command says: If table has more than one region, run a major compaction on .META. According to JD this is old news: jdcryans: back in the days when hadoop didn't support durability it was possible to lose .META. data so we were force flushing .META. and major compacting it all the time also we used to have consistency issues that major compacting was solving ahhh the good old days -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3475) MetaScanner and MetaReader are very similar; purge one
[ https://issues.apache.org/jira/browse/HBASE-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-3475: - Tags: noob Labels: noob (was: ) Agree. Making as noob. MetaScanner and MetaReader are very similar; purge one -- Key: HBASE-3475 URL: https://issues.apache.org/jira/browse/HBASE-3475 Project: HBase Issue Type: Improvement Reporter: stack Labels: noob MetaScanner in client package is a little more involved but MetaReader does similar. Both allow you specify a Visitor on .META. and -ROOT-. We should dump one of them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6586) Quarantine Corrupted HFiles
[
https://issues.apache.org/jira/browse/HBASE-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-6586:
--
Attachment: 0001-hbase-6568-hbck-quarantine-v6.patch
v2, adds checks/warning for deleted files.
Quarantine Corrupted HFiles
---
Key: HBASE-6586
URL: https://issues.apache.org/jira/browse/HBASE-6586
Project: HBase
Issue Type: Improvement
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Attachments: 0001-hbase-6568-hbck-quarantine-v6.patch,
hbase-6586.patch
We've encountered a few upgrades from 0.90 hbases + 20.2/1.x hdfs to 0.92
hbases + hdfs 2.x that get stuck. I haven't been able to duplicate the
problem in my dev environment but we suspect this may be related to
HDFS-3731. On the HBase side, it seems reasonable to quarantine what are
most likely truncated hfiles, so that can could later be recovered.
Here's an example of the exception we've encountered:
{code}
2012-07-18 05:55:01,152 ERROR handler.OpenRegionHandler
(OpenRegionHandler.java:openRegion(346)) - Failed open of
region=user_mappings,080112102AA76EF98197605D341B9E6C5824D2BC|1001,1317824890618.eaed0e7abc6d27d28ff0e5a9b49c4c
0d.
java.io.IOException: java.lang.IllegalArgumentException: Invalid HFile
version: 842220600 (expected to be between 1 and 2)
at
org.apache.hadoop.hbase.io.hfile.FixedFileTrailer.readFromStream(FixedFileTrailer.java:306)
at org.apache.hadoop.hbase.io.hfile.HFile.pickReaderVersion(HFile.java:371)
at org.apache.hadoop.hbase.io.hfile.HFile.createReader(HFile.java:387)
at
org.apache.hadoop.hbase.regionserver.StoreFile$Reader.init(StoreFile.java:1026)
at org.apache.hadoop.hbase.regionserver.StoreFile.open(StoreFile.java:485)
at
org.apache.hadoop.hbase.regionserver.StoreFile.createReader(StoreFile.java:566)
at org.apache.hadoop.hbase.regionserver.Store.loadStoreFiles(Store.java:286)
at org.apache.hadoop.hbase.regionserver.Store.init(Store.java:223)
at
org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:2534)
at org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:454)
at
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:3282)
at
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:3230)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:331)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:107)
at org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:169)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: Invalid HFile version:
842220600 (expected to be between 1 and 2)
at org.apache.hadoop.hbase.io.hfile.HFile.checkFormatVersion(HFile.java:515)
at
org.apache.hadoop.hbase.io.hfile.FixedFileTrailer.readFromStream(FixedFileTrailer.java:303)
... 17 more
{code}
Specifically -- the FixedFileTrailer are incorrect, and seemingly missing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6619) Do no unregister and re-register interest ops in RPC
[ https://issues.apache.org/jira/browse/HBASE-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438187#comment-13438187 ] Michal Gregorczyk commented on HBASE-6619: -- It is event for which we are waiting on file descriptor. We do reads in asynchronous way. We have one thread (Listener) waiting on set of file descriptors (connections). Every time there is something to read from connection we first deregister interest in read operation on that descriptor and then pass it to another thread to do read. When read operation is done, the thread parses new data and after queueing new Call object it registers read interest on that descriptor again. It involves calling SelectionKey.interestOps(int) (which according to documentation can block, but does not have to - implementation dependent), and waking up Listener thread. After that we can read from the connection again. To improve performance we can do 2 things: 1. do something not to register and deregister interest in read 2. parse new data in handler thread, instead of thread that performs read operation. Do no unregister and re-register interest ops in RPC Key: HBASE-6619 URL: https://issues.apache.org/jira/browse/HBASE-6619 Project: HBase Issue Type: Bug Components: ipc Reporter: Karthik Ranganathan Assignee: Michal Gregorczyk While investigating perf of HBase, Michal noticed that we could cut about 5-40% (depending on number of threads) from the total get time in the RPC on the server side if we eliminated re-registering for interest ops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6436) Netty should be moved off of snapshots.
[ https://issues.apache.org/jira/browse/HBASE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438203#comment-13438203 ] Hudson commented on HBASE-6436: --- Integrated in HBase-TRUNK #3243 (See [https://builds.apache.org/job/HBase-TRUNK/3243/]) HBASE-6436 Netty should be moved off of snapshots (Revision 1375183) Result = FAILURE stack : Files : * /hbase/trunk/pom.xml Netty should be moved off of snapshots. --- Key: HBASE-6436 URL: https://issues.apache.org/jira/browse/HBASE-6436 Project: HBase Issue Type: Task Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.96.0 Attachments: HBASE-6436-0.patch Netty is currently at 3.5.0.final-SNAPSHOT the final 3.5.0.Final should be used when possible so that repositories aren't queried when not needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438204#comment-13438204 ] Matteo Bertozzi commented on HBASE-5449: @Andrew from a quick look at the generated code doesn't seems that enum has some limitation for extensions, if for extension you mean adding more fields. Also, enums are already used in other protos... @Stack UserTablePermission is not from Gary proto, is the serialized version of the ListMultimap that stores all the permissions for one table (user: [permission]), used by the acl ZooKeeper serialization. Also there's still a toTablePermission() under ProtobufUtil since all the code uses TablePermission class and the toPermission() return a Permission object, maybe this stuff can be cleaned up by flattening the permission hierarchy. Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6378) the javadoc of setEnabledTable maybe not describe accurately
[
https://issues.apache.org/jira/browse/HBASE-6378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438211#comment-13438211
]
David S. Wang commented on HBASE-6378:
--
Actually, I did not make the original patch; I just suggested a grammatical
change.
the javadoc of setEnabledTable maybe not describe accurately
--
Key: HBASE-6378
URL: https://issues.apache.org/jira/browse/HBASE-6378
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.94.0
Reporter: zhou wenjian
Assignee: David S. Wang
Fix For: 0.94.2
Attachments: 6378.patch, HBASE-6378.patch, HBASE-6378-trunk.patch
/**
* Sets the ENABLED state in the cache and deletes the zookeeper node. Fails
* silently if the node is not in enabled in zookeeper
*
* @param tableName
* @throws KeeperException
*/
public void setEnabledTable(final String tableName) throws KeeperException {
setTableState(tableName, TableState.ENABLED);
}
When setEnabledTable occours ,It will update the cache and the zookeeper
node,rather than to delete the zk node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438212#comment-13438212 ] Andrew Purtell commented on HBASE-5449: --- No I don't mean adding a new field, I mean using a new integer value for the enum. Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438214#comment-13438214 ] Andrew Purtell commented on HBASE-5449: --- Otherwise wouldn't we find ourselves having an Action field plus something like ExtendedAction or the MS-ism ActionEx? Maybe enums should be considered harmful? Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6556) Avoid ssh to localhost in startup scripts
[ https://issues.apache.org/jira/browse/HBASE-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang resolved HBASE-6556. --- Resolution: Duplicate Avoid ssh to localhost in startup scripts - Key: HBASE-6556 URL: https://issues.apache.org/jira/browse/HBASE-6556 Project: HBase Issue Type: Improvement Components: scripts Environment: Mac OSX Mountain Lion, HBase 89-fb Reporter: Ramkumar Vadali Priority: Trivial The use of ssh in scripts like zookeepers.sh and regionservers.sh for a single node setup is not necessary. We can execute the command directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6555) Avoid ssh to localhost in startup scripts
[ https://issues.apache.org/jira/browse/HBASE-6555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438216#comment-13438216 ] Liyin Tang commented on HBASE-6555: --- Hi Ramkumar, I have resolved the 6556,6557 and 6558 as duplicated jiras. Avoid ssh to localhost in startup scripts - Key: HBASE-6555 URL: https://issues.apache.org/jira/browse/HBASE-6555 Project: HBase Issue Type: Improvement Components: scripts Environment: Mac OSX Mountain Lion, HBase 89-fb Reporter: Ramkumar Vadali Priority: Trivial The use of ssh in scripts like zookeepers.sh and regionservers.sh for a single node setup is not necessary. We can execute the command directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6558) Avoid ssh to localhost in single node setup.
[ https://issues.apache.org/jira/browse/HBASE-6558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang resolved HBASE-6558. --- Resolution: Duplicate Avoid ssh to localhost in single node setup. - Key: HBASE-6558 URL: https://issues.apache.org/jira/browse/HBASE-6558 Project: HBase Issue Type: Improvement Components: scripts Environment: mac osx mountain lion, hbase 89-fb Reporter: Ramkumar Vadali Priority: Trivial Original Estimate: 24h Remaining Estimate: 24h The use of ssh in scripts like zookeepers.sh and regionservers.sh for a single node setup is not necessary. We can execute the command directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6557) Avoid ssh to localhost in single node setup.
[ https://issues.apache.org/jira/browse/HBASE-6557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang resolved HBASE-6557. --- Resolution: Duplicate Avoid ssh to localhost in single node setup. - Key: HBASE-6557 URL: https://issues.apache.org/jira/browse/HBASE-6557 Project: HBase Issue Type: Improvement Components: scripts Environment: mac osx mountain lion, hbase 89-fb Reporter: Ramkumar Vadali Priority: Trivial The use of ssh in scripts like zookeepers.sh and regionservers.sh for a single node setup is not necessary. We can execute the command directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[
https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438220#comment-13438220
]
Matteo Bertozzi commented on HBASE-5449:
@Andrew sorry, maybe I still don't get what you mean but the proto enum doesn't
match with the real enum. basically you convert the proto enum in the real
one with something like
{code}
switch (proto.getMyEnumValue()) {
case Proto.MY_ENUM_FIELD_1: return Real.MY_ENUM_FIELD_1;
case Proto.MY_ENUM_FIELD_1: return Real.MY_ENUM_FIELD_2;
}
{code}
this means that you can change the value of the real enum whenever you want,
while keeping the protobuf enum the same.
Support for wire-compatible security functionality
--
Key: HBASE-5449
URL: https://issues.apache.org/jira/browse/HBASE-5449
Project: HBase
Issue Type: Sub-task
Components: ipc, master, migration, regionserver
Reporter: Todd Lipcon
Assignee: Matteo Bertozzi
Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch,
HBASE-5449-v1.patch
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438224#comment-13438224 ] Andrew Purtell commented on HBASE-5449: --- So how do you update the Action message for a new action time? Will Action's with the new enum case be backwards compatible with earlier clients? Or will they throw some kind of exception? If old clients can ignore new enum values then I don't care. Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438224#comment-13438224 ] Andrew Purtell edited comment on HBASE-5449 at 8/21/12 8:23 AM: So how do you update the Action message for a new action item? Will Action's with the new enum case be backwards compatible with earlier clients? Or will they throw some kind of exception? If old clients can ignore new enum values then I don't care. Edit: Fix typo. was (Author: apurtell): So how do you update the Action message for a new action time? Will Action's with the new enum case be backwards compatible with earlier clients? Or will they throw some kind of exception? If old clients can ignore new enum values then I don't care. Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5714) Add write permissions check before any hbck run that modifies hdfs.
[ https://issues.apache.org/jira/browse/HBASE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438228#comment-13438228 ] Jonathan Hsieh commented on HBASE-5714: --- Thanks liang xie! Looks good to me. I'm committing (with minor tweaks to port to 0.94/0.92/0.90). Thanks for the review stack. Add write permissions check before any hbck run that modifies hdfs. --- Key: HBASE-5714 URL: https://issues.apache.org/jira/browse/HBASE-5714 Project: HBase Issue Type: Sub-task Components: hbck Affects Versions: 0.90.6, 0.92.2, 0.94.0, 0.96.0 Reporter: Jonathan Hsieh Attachments: HBASE-5628.patch, HBASE-5628.patch.v2 We encoutered a situation where hbck was run by an under-privileged user that was unable to write/modify/merge regions due to hdfs perms. Unfortunately, this user was alerted of this after several minutes of read-only operations. hbck should fail early by having a write perm check and providing actionable advice to the hbase admin. Maybe something like: Current user yy does not have write perms to hbase home. Please run hbck as hdfs user xxx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5714) Add write permissions check before any hbck run that modifies hdfs.
[ https://issues.apache.org/jira/browse/HBASE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-5714: -- Issue Type: Improvement (was: Sub-task) Parent: (was: HBASE-5628) Add write permissions check before any hbck run that modifies hdfs. --- Key: HBASE-5714 URL: https://issues.apache.org/jira/browse/HBASE-5714 Project: HBase Issue Type: Improvement Components: hbck Affects Versions: 0.90.6, 0.92.2, 0.94.0, 0.96.0 Reporter: Jonathan Hsieh Attachments: HBASE-5628.patch, HBASE-5628.patch.v2 We encoutered a situation where hbck was run by an under-privileged user that was unable to write/modify/merge regions due to hdfs perms. Unfortunately, this user was alerted of this after several minutes of read-only operations. hbck should fail early by having a write perm check and providing actionable advice to the hbase admin. Maybe something like: Current user yy does not have write perms to hbase home. Please run hbck as hdfs user xxx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-5714) Add write permissions check before any hbck run that modifies hdfs.
[ https://issues.apache.org/jira/browse/HBASE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh reassigned HBASE-5714: - Assignee: liang xie Add write permissions check before any hbck run that modifies hdfs. --- Key: HBASE-5714 URL: https://issues.apache.org/jira/browse/HBASE-5714 Project: HBase Issue Type: Improvement Components: hbck Affects Versions: 0.90.6, 0.92.2, 0.94.0, 0.96.0 Reporter: Jonathan Hsieh Assignee: liang xie Attachments: HBASE-5628.patch, HBASE-5628.patch.v2 We encoutered a situation where hbck was run by an under-privileged user that was unable to write/modify/merge regions due to hdfs perms. Unfortunately, this user was alerted of this after several minutes of read-only operations. hbck should fail early by having a write perm check and providing actionable advice to the hbase admin. Maybe something like: Current user yy does not have write perms to hbase home. Please run hbck as hdfs user xxx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5169) Group of Region Server, a subtask of issue 4120
[ https://issues.apache.org/jira/browse/HBASE-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438230#comment-13438230 ] Vandana Ayyalasomayajula commented on HBASE-5169: - The patch attached to this jira no longer applies cleanly to the trunk. Also, we are interested in this feature for 0.94 branch and trunk. Is there any approximate timeline when this patch will be finished ? If required, I am willing to help with the work. Group of Region Server, a subtask of issue 4120 - Key: HBASE-5169 URL: https://issues.apache.org/jira/browse/HBASE-5169 Project: HBase Issue Type: Sub-task Components: master Reporter: Liu Jia Assignee: Liu Jia Fix For: 0.96.0 Attachments: GroupOfRegionServer_v1.patch, GroupOfRegionServer_v2.patch This is a subtask of issue 4120,this patch provides the region server group feature of HBase. With this patch, region servers can be divided into groups,one table could belong to one or more groups while the region server can only belong to one group. Work load in defferent groups will not affect each other. This patch provides table level and group level load balance,the default load balance and region assignments will consider the group configuration and assign regions to their corresponding groups. More information, please check out the documents of issue 4120. There is a web tool of this patch providing operations of group managements like add/delete group, move in/out servers,change table's group attribute ,balance groups, balance tables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438235#comment-13438235 ] Matteo Bertozzi commented on HBASE-5449: The current implementation throws an exception if the enum doesn't match... but I think that we can skip the exception and the permission. e.g. 0.96 has READ, WRITE, CREATE, ADMIN 0.98 has READ, WRITE, CREATE, ADMIN, SUPER_POWER The 0.96 can just skip the SUPER_POWER permission since doesn't make sense in 0.96. Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5449) Support for wire-compatible security functionality
[ https://issues.apache.org/jira/browse/HBASE-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438236#comment-13438236 ] Andrew Purtell commented on HBASE-5449: --- I'm not clear what happens inside protobuf deserialization if a message with action = SUPER_POWER is received by a 0.96 client or server. Will it blow up? I don't think we should assume that a PB enum is going to enumerate everything we'll ever think of from one major release cycle to the next. Support for wire-compatible security functionality -- Key: HBASE-5449 URL: https://issues.apache.org/jira/browse/HBASE-5449 Project: HBase Issue Type: Sub-task Components: ipc, master, migration, regionserver Reporter: Todd Lipcon Assignee: Matteo Bertozzi Attachments: AccessControl_protos.patch, HBASE-5449-v0.patch, HBASE-5449-v1.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5714) Add write permissions check before any hbck run that modifies hdfs.
[ https://issues.apache.org/jira/browse/HBASE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-5714: -- Attachment: hbase-5714-94.patch hbase-5714-92.patch hbase-5714-90.patch Diffs of the backports. Add write permissions check before any hbck run that modifies hdfs. --- Key: HBASE-5714 URL: https://issues.apache.org/jira/browse/HBASE-5714 Project: HBase Issue Type: Improvement Components: hbck Affects Versions: 0.90.6, 0.92.2, 0.94.0, 0.96.0 Reporter: Jonathan Hsieh Assignee: liang xie Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.2 Attachments: HBASE-5628.patch, HBASE-5628.patch.v2, hbase-5714-90.patch, hbase-5714-92.patch, hbase-5714-94.patch We encoutered a situation where hbck was run by an under-privileged user that was unable to write/modify/merge regions due to hdfs perms. Unfortunately, this user was alerted of this after several minutes of read-only operations. hbck should fail early by having a write perm check and providing actionable advice to the hbase admin. Maybe something like: Current user yy does not have write perms to hbase home. Please run hbck as hdfs user xxx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-5714) Add write permissions check before any hbck run that modifies hdfs.
[ https://issues.apache.org/jira/browse/HBASE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh resolved HBASE-5714. --- Resolution: Fixed Fix Version/s: 0.94.2 0.96.0 0.92.2 0.90.7 Hadoop Flags: Reviewed Add write permissions check before any hbck run that modifies hdfs. --- Key: HBASE-5714 URL: https://issues.apache.org/jira/browse/HBASE-5714 Project: HBase Issue Type: Improvement Components: hbck Affects Versions: 0.90.6, 0.92.2, 0.94.0, 0.96.0 Reporter: Jonathan Hsieh Assignee: liang xie Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.2 Attachments: HBASE-5628.patch, HBASE-5628.patch.v2, hbase-5714-90.patch, hbase-5714-92.patch, hbase-5714-94.patch We encoutered a situation where hbck was run by an under-privileged user that was unable to write/modify/merge regions due to hdfs perms. Unfortunately, this user was alerted of this after several minutes of read-only operations. hbck should fail early by having a write perm check and providing actionable advice to the hbase admin. Maybe something like: Current user yy does not have write perms to hbase home. Please run hbck as hdfs user xxx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6608) Fix for HBASE-6160, META entries from daughters can be deleted before parent entries, shouldn't compare HRegionInfo's
[
https://issues.apache.org/jira/browse/HBASE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438240#comment-13438240
]
Hudson commented on HBASE-6608:
---
Integrated in HBase-0.92 #508 (See
[https://builds.apache.org/job/HBase-0.92/508/])
HBASE-6608 Fix for HBASE-6160, META entries from daughters can be deleted
before parent entries, shouldn't compare HRegionInfo's (Enis) (Revision 1375159)
Result = SUCCESS
tedyu :
Files :
*
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java
*
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java
Fix for HBASE-6160, META entries from daughters can be deleted before parent
entries, shouldn't compare HRegionInfo's
-
Key: HBASE-6608
URL: https://issues.apache.org/jira/browse/HBASE-6608
Project: HBase
Issue Type: Bug
Components: client, regionserver
Affects Versions: 0.92.1, 0.96.0, 0.94.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 0.92.2, 0.96.0, 0.94.2
Attachments: 6608-v2.patch, hbase-6608_v1-0.92+0.94.patch,
hbase-6608_v1.patch
Our nightlies discovered that the patch for HBASE-6160 did not actually fix
the issue of META entries from daughters can be deleted before parent
entries. Instead of reopening the HBASE-6160, it is cleaner to track it
here.
The original issue is:
{quote}
HBASE-5986 fixed and issue, where the client sees the META entry for the
parent, but not the children. However, after the fix, we have seen the
following issue in tests:
Region A is split to - B, C
Region B is split to - D, E
After some time, META entry for B is deleted since it is not needed anymore,
but META entry for Region A stays in META (C still refers it). In this case,
the client throws RegionOfflineException for B.
{quote}
The problem with the fix seems to be that we keep and compare HRegionInfo's
in the HashSet at CatalogJanitor.java#scan(), but HRI that are compared are
not equal.
{code}
HashSetHRegionInfo parentNotCleaned = new HashSetHRegionInfo(); //regions
whose parents are still around
for (Map.EntryHRegionInfo, Result e : splitParents.entrySet()) {
if (!parentNotCleaned.contains(e.getKey()) cleanParent(e.getKey(),
e.getValue())) {
cleaned++;
} else {
...
{code}
In the above case, Meta row for region A will contain a serialized version of
B that is not offline. However Meta row for region B will contain a
serialized version of B that is offline (MetaEditor.offlineParentInMeta()
does that). So the deserialized version we put to HashSet and the
deserialized version we query contains() from HashSet are different in the
offline field, thus HRI.equals() fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6160) META entries from daughters can be deleted before parent entries
[ https://issues.apache.org/jira/browse/HBASE-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438241#comment-13438241 ] Hudson commented on HBASE-6160: --- Integrated in HBase-0.92 #508 (See [https://builds.apache.org/job/HBase-0.92/508/]) HBASE-6608 Fix for HBASE-6160, META entries from daughters can be deleted before parent entries, shouldn't compare HRegionInfo's (Enis) (Revision 1375159) Result = SUCCESS tedyu : Files : * /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java * /hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java META entries from daughters can be deleted before parent entries Key: HBASE-6160 URL: https://issues.apache.org/jira/browse/HBASE-6160 Project: HBase Issue Type: Bug Components: client, regionserver Affects Versions: 0.92.2, 0.94.0, 0.96.0 Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.92.2, 0.94.1 Attachments: HBASE-6160_v1.patch, HBASE-6160v2092.txt, HBASE-6160_v2.patch, HBASE-6160_v2.patch HBASE-5986 fixed and issue, where the client sees the META entry for the parent, but not the children. However, after the fix, we have seen the following issue in tests: Region A is split to - B, C Region B is split to - D, E After some time, META entry for B is deleted since it is not needed anymore, but META entry for Region A stays in META (C still refers it). In this case, the client throws RegionOfflineException for B. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-6607) NullPointerException when accessing master web ui while master is initializing
[
https://issues.apache.org/jira/browse/HBASE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang reassigned HBASE-6607:
--
Assignee: Jimmy Xiang
NullPointerException when accessing master web ui while master is initializing
--
Key: HBASE-6607
URL: https://issues.apache.org/jira/browse/HBASE-6607
Project: HBase
Issue Type: Bug
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
Labels: noob
Probably I tried to check the master web ui too soon. I got some internal
error page. In the master log, there is such exception:
{noformat}
2012-08-17 16:06:25,146 ERROR org.mortbay.log: /master-status
java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.HMaster.isCatalogJanitorEnabled(HMaster.java:1213)
at
org.apache.hadoop.hbase.master.MasterStatusServlet.doGet(MasterStatusServlet.java:72)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
at
org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:835)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6378) the javadoc of setEnabledTable maybe not describe accurately
[
https://issues.apache.org/jira/browse/HBASE-6378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438253#comment-13438253
]
Hudson commented on HBASE-6378:
---
Integrated in HBase-TRUNK #3244 (See
[https://builds.apache.org/job/HBase-TRUNK/3244/])
HBASE-6378 the javadoc of setEnabledTable maybe not describe accurately
(Revision 1375200)
Result = SUCCESS
stack :
Files :
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKTable.java
the javadoc of setEnabledTable maybe not describe accurately
--
Key: HBASE-6378
URL: https://issues.apache.org/jira/browse/HBASE-6378
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.94.0
Reporter: zhou wenjian
Assignee: David S. Wang
Fix For: 0.94.2
Attachments: 6378.patch, HBASE-6378.patch, HBASE-6378-trunk.patch
/**
* Sets the ENABLED state in the cache and deletes the zookeeper node. Fails
* silently if the node is not in enabled in zookeeper
*
* @param tableName
* @throws KeeperException
*/
public void setEnabledTable(final String tableName) throws KeeperException {
setTableState(tableName, TableState.ENABLED);
}
When setEnabledTable occours ,It will update the cache and the zookeeper
node,rather than to delete the zk node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6503) HBase Shell Documentation For DROP Is Outdated
[ https://issues.apache.org/jira/browse/HBASE-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438254#comment-13438254 ] Hudson commented on HBASE-6503: --- Integrated in HBase-TRUNK #3244 (See [https://builds.apache.org/job/HBase-TRUNK/3244/]) HBASE-6503 HBase Shell Documentation For DROP Is Outdated (Revision 1375205) Result = SUCCESS stack : Files : * /hbase/trunk/hbase-server/src/main/ruby/shell/commands/drop.rb HBase Shell Documentation For DROP Is Outdated -- Key: HBASE-6503 URL: https://issues.apache.org/jira/browse/HBASE-6503 Project: HBase Issue Type: Bug Reporter: Paul Cavallaro Assignee: Paul Cavallaro Priority: Trivial Fix For: 0.92.2, 0.94.2 Attachments: HBASE-6503-example.patch, HBASE-6503.patch HBase Shell help documentation for the drop command says: If table has more than one region, run a major compaction on .META. According to JD this is old news: jdcryans: back in the days when hadoop didn't support durability it was possible to lose .META. data so we were force flushing .META. and major compacting it all the time also we used to have consistency issues that major compacting was solving ahhh the good old days -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6582) Code generation does run under m2eclipse
[ https://issues.apache.org/jira/browse/HBASE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438255#comment-13438255 ] Hudson commented on HBASE-6582: --- Integrated in HBase-TRUNK #3244 (See [https://builds.apache.org/job/HBase-TRUNK/3244/]) HBASE-6582 Code generation does run under m2eclipse (Revision 1375198) Result = SUCCESS stack : Files : * /hbase/trunk/hbase-server/pom.xml Code generation does run under m2eclipse Key: HBASE-6582 URL: https://issues.apache.org/jira/browse/HBASE-6582 Project: HBase Issue Type: Bug Reporter: Michael Drzal Assignee: Michael Drzal Priority: Minor Fix For: 0.96.0 Attachments: HBASE-6582.patch When going through the instructions on http://hbase.apache.org/book/ides.html, the build will fail in eclipse because none of the sources are generated. After looking at our pom and reading http://wiki.eclipse.org/M2E_compatible_maven_plugins, we are telling m2eclipse to ignore the avro and jamon plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5169) Group of Region Server, a subtask of issue 4120
[ https://issues.apache.org/jira/browse/HBASE-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438261#comment-13438261 ] Zhihong Ted Yu commented on HBASE-5169: --- This task has been idle for 5 months. @Vandana: What do you think of the current design ? It would be nice if you can continue with this feature. Group of Region Server, a subtask of issue 4120 - Key: HBASE-5169 URL: https://issues.apache.org/jira/browse/HBASE-5169 Project: HBase Issue Type: Sub-task Components: master Reporter: Liu Jia Assignee: Liu Jia Fix For: 0.96.0 Attachments: GroupOfRegionServer_v1.patch, GroupOfRegionServer_v2.patch This is a subtask of issue 4120,this patch provides the region server group feature of HBase. With this patch, region servers can be divided into groups,one table could belong to one or more groups while the region server can only belong to one group. Work load in defferent groups will not affect each other. This patch provides table level and group level load balance,the default load balance and region assignments will consider the group configuration and assign regions to their corresponding groups. More information, please check out the documents of issue 4120. There is a web tool of this patch providing operations of group managements like add/delete group, move in/out servers,change table's group attribute ,balance groups, balance tables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6503) HBase Shell Documentation For DROP Is Outdated
[ https://issues.apache.org/jira/browse/HBASE-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438267#comment-13438267 ] Hudson commented on HBASE-6503: --- Integrated in HBase-0.94 #408 (See [https://builds.apache.org/job/HBase-0.94/408/]) HBASE-6503 HBase Shell Documentation For DROP Is Outdated (Revision 1375206) Result = SUCCESS stack : Files : * /hbase/branches/0.94/src/main/ruby/shell/commands/drop.rb HBase Shell Documentation For DROP Is Outdated -- Key: HBASE-6503 URL: https://issues.apache.org/jira/browse/HBASE-6503 Project: HBase Issue Type: Bug Reporter: Paul Cavallaro Assignee: Paul Cavallaro Priority: Trivial Fix For: 0.92.2, 0.94.2 Attachments: HBASE-6503-example.patch, HBASE-6503.patch HBase Shell help documentation for the drop command says: If table has more than one region, run a major compaction on .META. According to JD this is old news: jdcryans: back in the days when hadoop didn't support durability it was possible to lose .META. data so we were force flushing .META. and major compacting it all the time also we used to have consistency issues that major compacting was solving ahhh the good old days -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
