[jira] [Commented] (HBASE-10595) HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed
[ https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915541#comment-13915541 ] Feng Honghua commented on HBASE-10595: -- Thanks [~enis] for comment! sorry for the late reply bq.Going to NN for checking whether table dir exists basically means that we should not be using the cache at all. Users are expected to not delete the table directory from the file system, which will cause further inconsistencies. Why do you think this is a problem? # You meant HMaster when saying 'NN', right? # In the time interval that after table dir is moved to tmp folder and before it's removed from table descriptor cache, the results of listTables and getTableDescriptor contradict, don't you think it's a kind of inconsistency? # Users are surely NOT expected to delete table directory on purpose, but if they do delete table directory by accident, we should still ensure queries on HBase states get consistent results, right? Actually some HBCK unit tests aim for ensuring consistency under such corruption from user. HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed -- Key: HBASE-10595 URL: https://issues.apache.org/jira/browse/HBASE-10595 Project: HBase Issue Type: Sub-task Components: master, util Reporter: Feng Honghua Assignee: Feng Honghua Attachments: HBASE-10595-trunk_v1.patch, HBASE-10595-trunk_v2.patch, HBASE-10595-trunk_v3.patch When a table dir (in hdfs) is removed(by outside), HMaster will still return the cached TableDescriptor to client for getTableDescriptor request. On the contrary, HBaseAdmin.listTables() is handled correctly in current implementation, for a table whose table dir in hdfs is removed by outside, getTableDescriptor can still retrieve back a valid (old) table descriptor, while listTables says it doesn't exist, this is inconsistent The reason for this bug is because HMaster (via FSTableDescriptors) doesn't check if the table dir exists for getTableDescriptor() request, (while it lists all existing table dirs(not firstly respects cache) and returns accordingly for listTables() request) When a table is deleted via deleteTable, the cache will be cleared after the table dir and tableInfo file is removed, listTables/getTableDescriptor inconsistency should be transient(though still exists, when table dir is removed while cache is not cleared) and harder to expose -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10624) Fix 2 new findbugs warnings
[
https://issues.apache.org/jira/browse/HBASE-10624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915557#comment-13915557
]
Hadoop QA commented on HBASE-10624:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631667/10624-v4.txt
against trunk revision .
ATTACHMENT ID: 12631667
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8846//console
This message is automatically generated.
Fix 2 new findbugs warnings
---
Key: HBASE-10624
URL: https://issues.apache.org/jira/browse/HBASE-10624
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10624-v1.txt, 10624-v2.txt, 10624-v3.txt, 10624-v4.txt
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp;
locked 66% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp
Synchronized 66% of the time
{code}
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp;
locked 62% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp
Synchronized 62% of the time
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-9708) Improve Snapshot Name Error Message
[
https://issues.apache.org/jira/browse/HBASE-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-9708:
---
Status: Patch Available (was: Open)
Improve Snapshot Name Error Message
---
Key: HBASE-9708
URL: https://issues.apache.org/jira/browse/HBASE-9708
Project: HBase
Issue Type: Bug
Components: snapshots
Affects Versions: 0.94.2
Reporter: Jesse Anderson
Priority: Minor
Attachments: HBASE-9708.1.patch
The output for snapshots when you enter an invalid snapshot name talks about
User-space table names instead of Snapshot names. The error message
should say Snapshot names can only contain
Here is an example of the output:
{noformat}
hbase(main):001:0 snapshot 'user', 'asdf asdf'
ERROR: java.lang.IllegalArgumentException: Illegal character 32 at 4.
User-space table names can only contain 'word characters': i.e.
[a-zA-Z_0-9-.]: asdf asdf
Here is some help for this command:
Take a snapshot of specified table. Examples:
hbase snapshot 'sourceTable', 'snapshotName'
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-10631: Resolution: Fixed Fix Version/s: 0.94.18 0.99.0 0.98.1 0.96.2 Status: Resolved (was: Patch Available) Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
[ https://issues.apache.org/jira/browse/HBASE-10531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915605#comment-13915605 ] ramkrishna.s.vasudevan commented on HBASE-10531: Ping !!! Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo Key: HBASE-10531 URL: https://issues.apache.org/jira/browse/HBASE-10531 Project: HBase Issue Type: Sub-task Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.99.0 Attachments: HBASE-10531.patch, HBASE-10531_1.patch Currently the byte[] key passed to HFileScanner.seekTo and HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts. And the caller forms this by using kv.getBuffer, which is actually deprecated. So see how this can be achieved considering kv.getBuffer is removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10603) Deprecate RegionSplitter CLI tool
[ https://issues.apache.org/jira/browse/HBASE-10603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915638#comment-13915638 ] Anoop Sam John commented on HBASE-10603: Yes Shell uses this. Ideally Shell should work with out hbase server side jars(?) This class is in hbase-server package. Deprecate RegionSplitter CLI tool - Key: HBASE-10603 URL: https://issues.apache.org/jira/browse/HBASE-10603 Project: HBase Issue Type: Improvement Components: util Reporter: Nick Dimiduk Priority: Minor Labels: noob Fix For: 0.99.0 RegionSplitter is a utility for partitioning a table based on some split algorithm. Those same algorithms are exposed via the shell create command. There's no value in having two ways to access the same functionality. Ensure the main method doesn't provide any functionality absent from the shell and remove it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10622) Improve log and Exceptions in Export Snapshot
[
https://issues.apache.org/jira/browse/HBASE-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-10622:
Attachment: HBASE-10622-v1.patch
job.getStatus().getFailureInfo() is not present in all the version, so when you
end up getting this.
I've added a TODO, and I'll skip it for now
{code}
java.lang.NoSuchMethodError:
org.apache.hadoop.mapreduce.Job.getStatus()Lorg/apache/hadoop/mapreduce/JobStatus
{code}
Improve log and Exceptions in Export Snapshot
--
Key: HBASE-10622
URL: https://issues.apache.org/jira/browse/HBASE-10622
Project: HBase
Issue Type: Bug
Components: snapshots
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Fix For: 0.99.0
Attachments: HBASE-10622-v0.patch, HBASE-10622-v1.patch
from the logs of export snapshot is not really clear what's going on,
adding some extra information useful to debug, and in some places the real
exception can be thrown
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-9708) Improve Snapshot Name Error Message
[
https://issues.apache.org/jira/browse/HBASE-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915664#comment-13915664
]
Hadoop QA commented on HBASE-9708:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631595/HBASE-9708.1.patch
against trunk revision .
ATTACHMENT ID: 12631595
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ throw new IllegalArgumentException(isSnapshot ? Snapshot : Table
+ qualifier must not be empty);
+ at 0. Namespaces can only
start with alphanumeric +
+ characters': i.e. [a-zA-Z_0-9]:
+ Bytes.toString(qualifierName));
+ . + (isSnapshot ? snapshot :
User-space table) + qualifiers can only contain +
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8847//console
This message is automatically generated.
Improve Snapshot Name Error Message
---
Key: HBASE-9708
URL: https://issues.apache.org/jira/browse/HBASE-9708
Project: HBase
Issue Type: Bug
Components: snapshots
Affects Versions: 0.94.2
Reporter: Jesse Anderson
Priority: Minor
Attachments: HBASE-9708.1.patch
The output for snapshots when you enter an invalid snapshot name talks about
User-space table names instead of Snapshot names. The error message
should say Snapshot names can only contain
Here is an example of the output:
{noformat}
hbase(main):001:0 snapshot 'user', 'asdf asdf'
ERROR: java.lang.IllegalArgumentException: Illegal character 32 at 4.
User-space table names can only contain 'word characters': i.e.
[a-zA-Z_0-9-.]: asdf asdf
Here is some help for this command:
Take a snapshot of specified table. Examples:
hbase snapshot 'sourceTable', 'snapshotName'
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915676#comment-13915676 ] Hudson commented on HBASE-10631: SUCCESS: Integrated in HBase-0.94-security #426 (See [https://builds.apache.org/job/HBase-0.94-security/426/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572892) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10637) rpcClient: Setup the iostream when doing the write
Nicolas Liochon created HBASE-10637: --- Summary: rpcClient: Setup the iostream when doing the write Key: HBASE-10637 URL: https://issues.apache.org/jira/browse/HBASE-10637 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 0.99.0 This helps as we can be interrupted there as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10637) rpcClient: Setup the iostream when doing the write
[ https://issues.apache.org/jira/browse/HBASE-10637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-10637: Attachment: 10637.v1.patch rpcClient: Setup the iostream when doing the write -- Key: HBASE-10637 URL: https://issues.apache.org/jira/browse/HBASE-10637 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 0.99.0 Attachments: 10637.v1.patch This helps as we can be interrupted there as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10619) Don't allow user to disable/drop NS table
[
https://issues.apache.org/jira/browse/HBASE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915705#comment-13915705
]
Hadoop QA commented on HBASE-10619:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631703/HBASE-10619_V2.patch
against trunk revision .
ATTACHMENT ID: 12631703
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithACL
org.apache.hadoop.hbase.mapreduce.TestSecureLoadIncrementalHFiles
org.apache.hadoop.hbase.security.access.TestTablePermissions
org.apache.hadoop.hbase.security.access.TestAccessControlFilter
org.apache.hadoop.hbase.client.TestAdmin
org.apache.hadoop.hbase.mapreduce.TestSecureLoadIncrementalHFilesSplitRecovery
org.apache.hadoop.hbase.TestNamespace
org.apache.hadoop.hbase.security.access.TestAccessController
org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8848//console
This message is automatically generated.
Don't allow user to disable/drop NS table
-
Key: HBASE-10619
URL: https://issues.apache.org/jira/browse/HBASE-10619
Project: HBase
Issue Type: Bug
Reporter: Anoop Sam John
Assignee: Anoop Sam John
Attachments: HBASE-10619.patch, HBASE-10619_V2.patch
We should treat NS table just like META table, which is having checks so that
user can not disable/drop.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10594) Speed up TestRestoreSnapshotFromClient a bit
[ https://issues.apache.org/jira/browse/HBASE-10594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915708#comment-13915708 ] Hudson commented on HBASE-10594: SUCCESS: Integrated in HBase-0.98 #191 (See [https://builds.apache.org/job/HBase-0.98/191/]) HBASE-10594 Revert due to test instability (larsh: rev 1572438) * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestRestoreSnapshotFromClient.java Speed up TestRestoreSnapshotFromClient a bit Key: HBASE-10594 URL: https://issues.apache.org/jira/browse/HBASE-10594 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Priority: Minor Attachments: 10594-0.94.txt, 10594-trunk.txt Looking through the longest running test in 0.94 I noticed that TestRestoreSnapshotFromClient runs for over 10 minutes on the jenkins boxes (264s on my local box). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915709#comment-13915709 ] Hudson commented on HBASE-10631: SUCCESS: Integrated in HBase-0.98 #191 (See [https://builds.apache.org/job/HBase-0.98/191/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572890) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10637) rpcClient: Setup the iostream when doing the write
[ https://issues.apache.org/jira/browse/HBASE-10637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-10637: Status: Patch Available (was: Open) rpcClient: Setup the iostream when doing the write -- Key: HBASE-10637 URL: https://issues.apache.org/jira/browse/HBASE-10637 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.99.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 0.99.0 Attachments: 10637.v1.patch This helps as we can be interrupted there as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915716#comment-13915716 ] Hudson commented on HBASE-10631: FAILURE: Integrated in HBase-0.94-JDK7 #68 (See [https://builds.apache.org/job/HBase-0.94-JDK7/68/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572892) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915719#comment-13915719 ] Hudson commented on HBASE-10631: FAILURE: Integrated in hbase-0.96 #320 (See [https://builds.apache.org/job/hbase-0.96/320/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572891) * /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915720#comment-13915720 ] Hudson commented on HBASE-10631: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #179 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/179/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572890) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915726#comment-13915726 ] Hudson commented on HBASE-10631: FAILURE: Integrated in HBase-TRUNK #4965 (See [https://builds.apache.org/job/HBase-TRUNK/4965/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572889) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10595) HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed
[ https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feng Honghua updated HBASE-10595: - Attachment: HBASE-10595-trunk_v4.patch HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed -- Key: HBASE-10595 URL: https://issues.apache.org/jira/browse/HBASE-10595 Project: HBase Issue Type: Sub-task Components: master, util Reporter: Feng Honghua Assignee: Feng Honghua Attachments: HBASE-10595-trunk_v1.patch, HBASE-10595-trunk_v2.patch, HBASE-10595-trunk_v3.patch, HBASE-10595-trunk_v4.patch When a table dir (in hdfs) is removed(by outside), HMaster will still return the cached TableDescriptor to client for getTableDescriptor request. On the contrary, HBaseAdmin.listTables() is handled correctly in current implementation, for a table whose table dir in hdfs is removed by outside, getTableDescriptor can still retrieve back a valid (old) table descriptor, while listTables says it doesn't exist, this is inconsistent The reason for this bug is because HMaster (via FSTableDescriptors) doesn't check if the table dir exists for getTableDescriptor() request, (while it lists all existing table dirs(not firstly respects cache) and returns accordingly for listTables() request) When a table is deleted via deleteTable, the cache will be cleared after the table dir and tableInfo file is removed, listTables/getTableDescriptor inconsistency should be transient(though still exists, when table dir is removed while cache is not cleared) and harder to expose -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915731#comment-13915731 ] Hudson commented on HBASE-10631: FAILURE: Integrated in HBase-0.94 #1304 (See [https://builds.apache.org/job/HBase-0.94/1304/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572892) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[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=13915732#comment-13915732 ] Igor Kuzmitshov commented on HBASE-6618: Looking at the description above that rule (0001 - 0999) means any 4 bytesany 4 bytes value between 0001 and 0999, I thought that the value in the fixed part is checked as whole, but the code actually checks its bytes in isolation, so the rule is actually 0(0 - 9)(0 - 9)(1 - 9). It's fine for ranges like this, but let's take another: ??(53 - 97). I would expect aa68 to satisfy the rule, but in the proposed implementation it doesn't (because bytes are checked in isolation and 8 is outside the range \[3, 7\]). Could you clarify if this is the intended behaviour? If yes, i.e. aa68 should not satisfy rule ??(53 - 97): It would be nice to make it more clear in the description that all bytes are checked in isolation and there are actually no n-bytes values. In this case, there is a bug: for rule ??(50 - 97) and value MM58 (where M is max byte \xFF), satisfies() returns SatisfiesCode.NO_NEXT because nextRowKeyCandidateExists is only updated for non-fixed positions. It should return NEXT_EXISTS, because MM60 should be the next key. If no, i.e. aa68 should satisfy rule ??(53 - 97): In this case, satisfy() should be fixed. I made a patch with the fix and can add it if needed. It also has a small optimisation when there is no need to check less significant bytes. For example: for range \[120, 500\] and key 345, it will compare the first byte (3) only, as it's clear that the whole value is in the range. In any case, tests might include testing satisfy() with ranges (the current patch only adds tests for getNextForFuzzyRule() with ranges). 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 Assignee: Alex Baranau Priority: Minor Fix For: 0.99.0 Attachments: HBASE-6618-algo-desc-bits.png, HBASE-6618-algo.patch, HBASE-6618.patch, HBASE-6618_2.path, HBASE-6618_3.path 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 was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10622) Improve log and Exceptions in Export Snapshot
[ https://issues.apache.org/jira/browse/HBASE-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-10622: Attachment: HBASE-10622-v2.patch Improve log and Exceptions in Export Snapshot -- Key: HBASE-10622 URL: https://issues.apache.org/jira/browse/HBASE-10622 Project: HBase Issue Type: Bug Components: snapshots Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Fix For: 0.99.0 Attachments: HBASE-10622-v0.patch, HBASE-10622-v1.patch, HBASE-10622-v2.patch from the logs of export snapshot is not really clear what's going on, adding some extra information useful to debug, and in some places the real exception can be thrown -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10622) Improve log and Exceptions in Export Snapshot
[
https://issues.apache.org/jira/browse/HBASE-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915738#comment-13915738
]
Hadoop QA commented on HBASE-10622:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631707/HBASE-10622-v1.patch
against trunk revision .
ATTACHMENT ID: 12631707
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8849//console
This message is automatically generated.
Improve log and Exceptions in Export Snapshot
--
Key: HBASE-10622
URL: https://issues.apache.org/jira/browse/HBASE-10622
Project: HBase
Issue Type: Bug
Components: snapshots
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Fix For: 0.99.0
Attachments: HBASE-10622-v0.patch, HBASE-10622-v1.patch
from the logs of export snapshot is not really clear what's going on,
adding some extra information useful to debug, and in some places the real
exception can be thrown
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915779#comment-13915779 ] Hudson commented on HBASE-10631: SUCCESS: Integrated in hbase-0.96-hadoop2 #220 (See [https://builds.apache.org/job/hbase-0.96-hadoop2/220/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572891) * /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10637) rpcClient: Setup the iostream when doing the write
[
https://issues.apache.org/jira/browse/HBASE-10637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915798#comment-13915798
]
Hadoop QA commented on HBASE-10637:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631724/10637.v1.patch
against trunk revision .
ATTACHMENT ID: 12631724
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.security.token.TestZKSecretWatcher
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8850//console
This message is automatically generated.
rpcClient: Setup the iostream when doing the write
--
Key: HBASE-10637
URL: https://issues.apache.org/jira/browse/HBASE-10637
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 0.99.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Fix For: 0.99.0
Attachments: 10637.v1.patch
This helps as we can be interrupted there as well.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10631) Avoid extra seek on FileLink open
[ https://issues.apache.org/jira/browse/HBASE-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915749#comment-13915749 ] Hudson commented on HBASE-10631: FAILURE: Integrated in HBase-0.94-on-Hadoop-2 #36 (See [https://builds.apache.org/job/HBase-0.94-on-Hadoop-2/36/]) HBASE-10631 Avoid extra seek on FileLink open (mbertozzi: rev 1572892) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/FileLink.java Avoid extra seek on FileLink open - Key: HBASE-10631 URL: https://issues.apache.org/jira/browse/HBASE-10631 Project: HBase Issue Type: Bug Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Minor Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18 Attachments: HBASE-10631-v0.patch There is an extra seek(0) on FileLink open, that we can skip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10619) Don't allow user to disable/drop NS table
[ https://issues.apache.org/jira/browse/HBASE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915827#comment-13915827 ] Anoop Sam John commented on HBASE-10619: TestAccessController#createTableInSystemNamespace() The test creates a table in system NS and asserts successful creation. Is it fine to change this behaviour now? Don't allow user to disable/drop NS table - Key: HBASE-10619 URL: https://issues.apache.org/jira/browse/HBASE-10619 Project: HBase Issue Type: Bug Reporter: Anoop Sam John Assignee: Anoop Sam John Attachments: HBASE-10619.patch, HBASE-10619_V2.patch We should treat NS table just like META table, which is having checks so that user can not disable/drop. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10595) HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed
[
https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915847#comment-13915847
]
Hadoop QA commented on HBASE-10595:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631729/HBASE-10595-trunk_v4.patch
against trunk revision .
ATTACHMENT ID: 12631729
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8851//console
This message is automatically generated.
HBaseAdmin.getTableDescriptor can wrongly get the previous table's
TableDescriptor even after the table dir in hdfs is removed
--
Key: HBASE-10595
URL: https://issues.apache.org/jira/browse/HBASE-10595
Project: HBase
Issue Type: Sub-task
Components: master, util
Reporter: Feng Honghua
Assignee: Feng Honghua
Attachments: HBASE-10595-trunk_v1.patch, HBASE-10595-trunk_v2.patch,
HBASE-10595-trunk_v3.patch, HBASE-10595-trunk_v4.patch
When a table dir (in hdfs) is removed(by outside), HMaster will still return
the cached TableDescriptor to client for getTableDescriptor request.
On the contrary, HBaseAdmin.listTables() is handled correctly in current
implementation, for a table whose table dir in hdfs is removed by outside,
getTableDescriptor can still retrieve back a valid (old) table descriptor,
while listTables says it doesn't exist, this is inconsistent
The reason for this bug is because HMaster (via FSTableDescriptors) doesn't
check if the table dir exists for getTableDescriptor() request, (while it
lists all existing table dirs(not firstly respects cache) and returns
accordingly for listTables() request)
When a table is deleted via deleteTable, the cache will be cleared after the
table dir and tableInfo file is removed, listTables/getTableDescriptor
inconsistency should be transient(though still exists, when table dir is
removed while cache is not cleared) and harder to expose
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10619) Don't allow user to disable/drop NS table
[ https://issues.apache.org/jira/browse/HBASE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-10619: --- Attachment: HBASE-10619_V3.patch Don't allow user to disable/drop NS table - Key: HBASE-10619 URL: https://issues.apache.org/jira/browse/HBASE-10619 Project: HBase Issue Type: Bug Reporter: Anoop Sam John Assignee: Anoop Sam John Attachments: HBASE-10619.patch, HBASE-10619_V2.patch, HBASE-10619_V3.patch We should treat NS table just like META table, which is having checks so that user can not disable/drop. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10622) Improve log and Exceptions in Export Snapshot
[
https://issues.apache.org/jira/browse/HBASE-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915899#comment-13915899
]
Hadoop QA commented on HBASE-10622:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631733/HBASE-10622-v2.patch
against trunk revision .
ATTACHMENT ID: 12631733
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8852//console
This message is automatically generated.
Improve log and Exceptions in Export Snapshot
--
Key: HBASE-10622
URL: https://issues.apache.org/jira/browse/HBASE-10622
Project: HBase
Issue Type: Bug
Components: snapshots
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Fix For: 0.99.0
Attachments: HBASE-10622-v0.patch, HBASE-10622-v1.patch,
HBASE-10622-v2.patch
from the logs of export snapshot is not really clear what's going on,
adding some extra information useful to debug, and in some places the real
exception can be thrown
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10595) HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed
[ https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915909#comment-13915909 ] Feng Honghua commented on HBASE-10595: -- To align with listTables() for which table is deemed nonexistent whenever its table dir is nonexistent, getTableDescriptor now gets TableNotFoundException whenever its table dir is nonexistent without regard to the table descriptor cache. During deleting table: table dir is renamed(moved) to tmp dir = archive all region data = remove table dir = clear table descriptor cache = remove from RegionStates = remove from ZKTable = execute postDeleteTable coprocessor By this patch, client now thinks deleting table succeeds after table dir is renamed(nonexistent), rather than after clearing the table descriptor cache, so some unit tests assuming states such as regions have been removed from RegionStates, postDeleteTable coprocessor has been executed now are more possible to fail (since archiving region data / removing table dir in tmp dir takes more time), that's why I add Threads.sleep() for some unit-tests in this patch -- Why these cases can pass before this patch is not by design, but by chance, because it takes much less time from clearing table descriptor cache to removing from RegionStates / executing postDeleteTable coprocessor(when without archiving table data / removing table dir), and they do fail when I add some extra sleep(it equals to scenario where HMaster could suddenly run slowly) after clearing table descriptor cache without this patch... The root cause of above test failure is another bug : HBaseAdmin.deleteTable is not really synchronous(some cleanups in HMaster are likely not done yet *after* HBaseAdmin.deleteTable() returns). HBase-10636 is created for this bug. We can remove the added Threads.sleep() once HBase-10636 is done, and personally I think this patch can be resolved independently. Any opinion? HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed -- Key: HBASE-10595 URL: https://issues.apache.org/jira/browse/HBASE-10595 Project: HBase Issue Type: Sub-task Components: master, util Reporter: Feng Honghua Assignee: Feng Honghua Attachments: HBASE-10595-trunk_v1.patch, HBASE-10595-trunk_v2.patch, HBASE-10595-trunk_v3.patch, HBASE-10595-trunk_v4.patch When a table dir (in hdfs) is removed(by outside), HMaster will still return the cached TableDescriptor to client for getTableDescriptor request. On the contrary, HBaseAdmin.listTables() is handled correctly in current implementation, for a table whose table dir in hdfs is removed by outside, getTableDescriptor can still retrieve back a valid (old) table descriptor, while listTables says it doesn't exist, this is inconsistent The reason for this bug is because HMaster (via FSTableDescriptors) doesn't check if the table dir exists for getTableDescriptor() request, (while it lists all existing table dirs(not firstly respects cache) and returns accordingly for listTables() request) When a table is deleted via deleteTable, the cache will be cleared after the table dir and tableInfo file is removed, listTables/getTableDescriptor inconsistency should be transient(though still exists, when table dir is removed while cache is not cleared) and harder to expose -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10623) Add ability to read a row after applying a RowMutation
[ https://issues.apache.org/jira/browse/HBASE-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915930#comment-13915930 ] Michael Webster commented on HBASE-10623: - I have a write once read many situation inside a service. I want to be able to apply relatively infrequent changes to an entity and then cache the new state of that entity in my service to hand out to readers. I could apply all of the updates at a specific timestamp, but that requires a second read which I would prefer to avoid. I hope that description is clear. Add ability to read a row after applying a RowMutation -- Key: HBASE-10623 URL: https://issues.apache.org/jira/browse/HBASE-10623 Project: HBase Issue Type: Improvement Reporter: Michael Webster Priority: Minor It would be useful to be able to return a row to the user after all of the mutations in a RowMutation operation has been applied. This would be similar to transactions in Redis where the result of executing an operation is returned to the user. However, since RowMutations only affect a single row, only the final result would need to be returned. This could allow for a snapshot view of the row without requiring any timestamp manipulation, or a second read by the client. Looking at the implementation of RowMutations, it seems like the Get could be done after the write has been committed but before the row locks are released. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10638) Improve error message when there is no region server available for move
Ted Yu created HBASE-10638:
--
Summary: Improve error message when there is no region server
available for move
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10638) Improve error message when there is no region server available for move
[
https://issues.apache.org/jira/browse/HBASE-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10638:
---
Status: Patch Available (was: Open)
Improve error message when there is no region server available for move
---
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10638) Improve error message when there is no region server available for move
[
https://issues.apache.org/jira/browse/HBASE-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10638:
---
Attachment: 10638-v1.txt
Improve error message when there is no region server available for move
---
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10638) Improve error message when there is no region server available for move
[
https://issues.apache.org/jira/browse/HBASE-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915935#comment-13915935
]
Ted Yu commented on HBASE-10638:
Here is sample output from the script with patch:
{code}
2014-02-28 04:38:05,383 INFO [main] zookeeper.ZooKeeper: Client
environment:user.name=hbase
2014-02-28 04:38:05,383 INFO [main] zookeeper.ZooKeeper: Client
environment:user.home=/home/hbase
2014-02-28 04:38:05,384 INFO [main] zookeeper.ZooKeeper: Client
environment:user.dir=/home/hbase
2014-02-28 04:38:05,385 INFO [main] zookeeper.ZooKeeper: Initiating client
connection, connectString=c6401.ambari.apache.org:2181 sessionTimeout=3
watcher=hconnection-0x3bbc58a7, quorum=c6401.ambari.apache.org:2181,
baseZNode=/hbase-unsecure
2014-02-28 04:38:05,421 INFO [main] zookeeper.RecoverableZooKeeper: Process
identifier=hconnection-0x3bbc58a7 connecting to ZooKeeper
ensemble=c6401.ambari.apache.org:2181
2014-02-28 04:38:05,433 INFO [main-SendThread(c6401.ambari.apache.org:2181)]
zookeeper.ClientCnxn: Opening socket connection to server
c6401.ambari.apache.org/192.168.64.101:2181. Will not attempt to authenticate
using SASL (unknown error)
2014-02-28 04:38:05,441 INFO [main-SendThread(c6401.ambari.apache.org:2181)]
zookeeper.ClientCnxn: Socket connection established to
c6401.ambari.apache.org/192.168.64.101:2181, initiating session
2014-02-28 04:38:05,471 INFO [main-SendThread(c6401.ambari.apache.org:2181)]
zookeeper.ClientCnxn: Session establishment complete on server
c6401.ambari.apache.org/192.168.64.101:2181, sessionid = 0x1446c174f56005e,
negotiated timeout = 3
Valid region move targets:
No regions were moved - there was no server available
{code}
Improve error message when there is no region server available for move
---
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10624) Fix 2 new findbugs warnings
[
https://issues.apache.org/jira/browse/HBASE-10624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10624:
---
Attachment: (was: 10624-v3.txt)
Fix 2 new findbugs warnings
---
Key: HBASE-10624
URL: https://issues.apache.org/jira/browse/HBASE-10624
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10624-v1.txt, 10624-v2.txt, 10624-v4.txt
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp;
locked 66% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp
Synchronized 66% of the time
{code}
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp;
locked 62% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp
Synchronized 62% of the time
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10638) Improve error message when there is no region server available for move
[
https://issues.apache.org/jira/browse/HBASE-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915947#comment-13915947
]
Matteo Bertozzi commented on HBASE-10638:
-
+1
Improve error message when there is no region server available for move
---
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10451) Enable back Tag compression on HFiles
[ https://issues.apache.org/jira/browse/HBASE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-10451: --- Status: Patch Available (was: Open) Enable back Tag compression on HFiles - Key: HBASE-10451 URL: https://issues.apache.org/jira/browse/HBASE-10451 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Critical Fix For: 0.98.1, 0.99.0 Attachments: HBASE-10451.patch, HBASE-10451_V2.patch, HBASE-10451_V3.patch, HBASE-10451_V4.patch, HBASE-10451_V5.patch, HBASE-10451_V6.patch HBASE-10443 disables tag compression on HFiles. This Jira is to fix the issues we have found out in HBASE-10443 and enable it back. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10451) Enable back Tag compression on HFiles
[ https://issues.apache.org/jira/browse/HBASE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-10451: --- Status: Open (was: Patch Available) Enable back Tag compression on HFiles - Key: HBASE-10451 URL: https://issues.apache.org/jira/browse/HBASE-10451 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Critical Fix For: 0.98.1, 0.99.0 Attachments: HBASE-10451.patch, HBASE-10451_V2.patch, HBASE-10451_V3.patch, HBASE-10451_V4.patch, HBASE-10451_V5.patch, HBASE-10451_V6.patch HBASE-10443 disables tag compression on HFiles. This Jira is to fix the issues we have found out in HBASE-10443 and enable it back. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10451) Enable back Tag compression on HFiles
[ https://issues.apache.org/jira/browse/HBASE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-10451: --- Attachment: (was: HBASE-10451_V6.patch) Enable back Tag compression on HFiles - Key: HBASE-10451 URL: https://issues.apache.org/jira/browse/HBASE-10451 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Critical Fix For: 0.98.1, 0.99.0 Attachments: HBASE-10451.patch, HBASE-10451_V2.patch, HBASE-10451_V3.patch, HBASE-10451_V4.patch, HBASE-10451_V5.patch, HBASE-10451_V6.patch HBASE-10443 disables tag compression on HFiles. This Jira is to fix the issues we have found out in HBASE-10443 and enable it back. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10451) Enable back Tag compression on HFiles
[ https://issues.apache.org/jira/browse/HBASE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-10451: --- Attachment: HBASE-10451_V6.patch Enable back Tag compression on HFiles - Key: HBASE-10451 URL: https://issues.apache.org/jira/browse/HBASE-10451 Project: HBase Issue Type: Bug Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Priority: Critical Fix For: 0.98.1, 0.99.0 Attachments: HBASE-10451.patch, HBASE-10451_V2.patch, HBASE-10451_V3.patch, HBASE-10451_V4.patch, HBASE-10451_V5.patch, HBASE-10451_V6.patch HBASE-10443 disables tag compression on HFiles. This Jira is to fix the issues we have found out in HBASE-10443 and enable it back. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10619) Don't allow user to disable/drop NS table
[
https://issues.apache.org/jira/browse/HBASE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916035#comment-13916035
]
Hadoop QA commented on HBASE-10619:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631762/HBASE-10619_V3.patch
against trunk revision .
ATTACHMENT ID: 12631762
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8853//console
This message is automatically generated.
Don't allow user to disable/drop NS table
-
Key: HBASE-10619
URL: https://issues.apache.org/jira/browse/HBASE-10619
Project: HBase
Issue Type: Bug
Reporter: Anoop Sam John
Assignee: Anoop Sam John
Attachments: HBASE-10619.patch, HBASE-10619_V2.patch,
HBASE-10619_V3.patch
We should treat NS table just like META table, which is having checks so that
user can not disable/drop.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10638) Improve error message when there is no region server available for move
[
https://issues.apache.org/jira/browse/HBASE-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10638:
---
Fix Version/s: 0.99.0
0.98.1
Hadoop Flags: Reviewed
Improve error message when there is no region server available for move
---
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Fix For: 0.98.1, 0.99.0
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10627:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch, Shaohui.
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HBASE-10639) Unload script displays wrong counts (off by one) when unloading regions
Srikanth Srungarapu created HBASE-10639: --- Summary: Unload script displays wrong counts (off by one) when unloading regions Key: HBASE-10639 URL: https://issues.apache.org/jira/browse/HBASE-10639 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.17 Reporter: Srikanth Srungarapu Priority: Trivial -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10639) Unload script displays wrong counts (off by one) when unloading regions
[ https://issues.apache.org/jira/browse/HBASE-10639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-10639: Description: Upon running an unload command, such as: hbase org.jruby.Main /usr/lib/hbase/bin/region_mover.rb unload `hostname`, the region counter is indexed at 0 and hence, when the regions are being moved, regions are being counted from 0 instead of 1. Unload script displays wrong counts (off by one) when unloading regions Key: HBASE-10639 URL: https://issues.apache.org/jira/browse/HBASE-10639 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.17 Reporter: Srikanth Srungarapu Priority: Trivial Upon running an unload command, such as: hbase org.jruby.Main /usr/lib/hbase/bin/region_mover.rb unload `hostname`, the region counter is indexed at 0 and hence, when the regions are being moved, regions are being counted from 0 instead of 1. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10638) Improve error message when there is no region server available for move
[
https://issues.apache.org/jira/browse/HBASE-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916110#comment-13916110
]
Hadoop QA commented on HBASE-10638:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631769/10638-v1.txt
against trunk revision .
ATTACHMENT ID: 12631769
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8854//console
This message is automatically generated.
Improve error message when there is no region server available for move
---
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Fix For: 0.98.1, 0.99.0
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916131#comment-13916131
]
Himanshu Vashishtha commented on HBASE-10627:
-
+1
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10595) HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed
[
https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916130#comment-13916130
]
Himanshu Vashishtha commented on HBASE-10595:
-
Looking at the patch,
bq. +if (!fs.exists(getTableDir(tablename))) {
This is a call to NN, and this patch would invoke it for every get request.
If a user deletes a table dir, wouldn't there be other (and more severe)
consistencies such as meta being hosed, etc. What is the use case where a user
is deleting the table dir behind the curtain ?
HBaseAdmin.getTableDescriptor can wrongly get the previous table's
TableDescriptor even after the table dir in hdfs is removed
--
Key: HBASE-10595
URL: https://issues.apache.org/jira/browse/HBASE-10595
Project: HBase
Issue Type: Sub-task
Components: master, util
Reporter: Feng Honghua
Assignee: Feng Honghua
Attachments: HBASE-10595-trunk_v1.patch, HBASE-10595-trunk_v2.patch,
HBASE-10595-trunk_v3.patch, HBASE-10595-trunk_v4.patch
When a table dir (in hdfs) is removed(by outside), HMaster will still return
the cached TableDescriptor to client for getTableDescriptor request.
On the contrary, HBaseAdmin.listTables() is handled correctly in current
implementation, for a table whose table dir in hdfs is removed by outside,
getTableDescriptor can still retrieve back a valid (old) table descriptor,
while listTables says it doesn't exist, this is inconsistent
The reason for this bug is because HMaster (via FSTableDescriptors) doesn't
check if the table dir exists for getTableDescriptor() request, (while it
lists all existing table dirs(not firstly respects cache) and returns
accordingly for listTables() request)
When a table is deleted via deleteTable, the cache will be cleared after the
table dir and tableInfo file is removed, listTables/getTableDescriptor
inconsistency should be transient(though still exists, when table dir is
removed while cache is not cleared) and harder to expose
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10601: --- Attachment: 0.98-hadoop-2.3.out Here is mvn output when building 0.98 with -Dhadoop.profile=2.3 Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10601: --- Status: Patch Available (was: Open) Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10601: --- Attachment: 10601-0.98-v2.txt Here is patch v2 that adds 2.3 hadoop profile for 0.98 Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10601: --- Attachment: (was: 10601-v1.txt) Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10601: --- Attachment: 10601-v1.txt Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10640) Add compilation step in QA run against hadoop 2.2.0
Ted Yu created HBASE-10640: -- Summary: Add compilation step in QA run against hadoop 2.2.0 Key: HBASE-10640 URL: https://issues.apache.org/jira/browse/HBASE-10640 Project: HBase Issue Type: Sub-task Reporter: Ted Yu As Andrew pointed out: https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911869#comment-13911869 bq. Yes, now that trunk has moved to 2.3.0 by default but 0.96 and 0.98 still use 2.2.0. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10632) Region lost in limbo after ArrayIndexOutOfBoundsException during assignment
[
https://issues.apache.org/jira/browse/HBASE-10632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916174#comment-13916174
]
Enis Soztutar commented on HBASE-10632:
---
This should affect 0.98 and 0.96 code lines as well.
Region lost in limbo after ArrayIndexOutOfBoundsException during assignment
---
Key: HBASE-10632
URL: https://issues.apache.org/jira/browse/HBASE-10632
Project: HBase
Issue Type: Bug
Components: Region Assignment
Affects Versions: hbase-10070
Reporter: Nick Dimiduk
Assignee: Enis Soztutar
Fix For: 0.96.2, 0.98.1, 0.99.0, hbase-10070
Attachments: hbase-10632_v1.patch
Discovered while running IntegrationTestBigLinkedList. Region
24d68aa7239824e42390a77b7212fcbf is scheduled for move from hor13n19 to
hor13n13. During the process an exception is thrown.
{noformat}
2014-02-25 15:30:42,613 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
master.RegionStates: Transitioning {24d68aa7239824e42390a77b7212fcbf
state=OPENING, ts=1393342207107,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552} will be handled by SSH
for hor13n19.gq1.ygridcore.net,60020,1393341563552
2014-02-25 15:30:42,613 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
handler.ServerShutdownHandler: Reassigning 7 region(s) that
hor13n19.gq1.ygridcore.net,60020,1393341563552 was carrying (and 0 regions(s)
that were opening on this server)
2014-02-25 15:30:42,613 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
handler.ServerShutdownHandler: Reassigning region with rs =
{24d68aa7239824e42390a77b7212fcbf state=OPENING, ts=1393342207107,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552} and deleting zk node
if exists
2014-02-25 15:30:42,623 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
master.RegionStates: Transitioned {24d68aa7239824e42390a77b7212fcbf
state=OPENING, ts=1393342207107,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552} to
{24d68aa7239824e42390a77b7212fcbf state=OFFLINE, ts=1393342242623,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552}
2014-02-25 15:30:42,623 DEBUG [AM.ZK.Worker-pool2-t46]
master.AssignmentManager: Znode
IntegrationTestBigLinkedList,\x80\x06\x1A,1393342105093.24d68aa7239824e42390a77b7212fcbf.
deleted, state: {24d68aa7239824e42390a77b7212fcbf state=OFFLINE,
ts=1393342242623, server=hor13n19.gq1.ygridcore.net,60020,1393341563552}
...
2014-02-25 15:30:43,993 ERROR [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
executor.EventHandler: Caught throwable while processing event
M_SERVER_SHUTDOWN
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.hadoop.hbase.master.balancer.BaseLoadBalancer$Cluster.init(BaseLoadBalancer.java:250)
at
org.apache.hadoop.hbase.master.balancer.BaseLoadBalancer.createCluster(BaseLoadBalancer.java:921)
at
org.apache.hadoop.hbase.master.balancer.BaseLoadBalancer.roundRobinAssignment(BaseLoadBalancer.java:860)
at
org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:2482)
at
org.apache.hadoop.hbase.master.handler.ServerShutdownHandler.process(ServerShutdownHandler.java:282)
at
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
After that, region is left in limbo and is never reassigned.
{noformat}
2014-02-25 15:35:11,581 INFO [FifoRpcScheduler.handler1-thread-6]
master.HMaster: Client=hrt_qa//68.142.246.29 move
hri=IntegrationTestBigLinkedList,\x80\x06\x1A,1393342105093.24d68aa7239824e42390a77b7212fcbf.,
src=hor13n19.gq1.ygridcore.net,60020,1393341563552,
dest=hor13n13.gq1.ygridcore.net,60020,139334275, running balancer
2014-02-25 15:35:11,581 INFO [FifoRpcScheduler.handler1-thread-6]
master.AssignmentManager: Ignored moving region not assigned: {ENCODED =
24d68aa7239824e42390a77b7212fcbf, NAME =
'IntegrationTestBigLinkedList,\x80\x06\x1A,1393342105093.24d68aa7239824e42390a77b7212fcbf.',
STARTKEY = '\x80\x06\x1A', ENDKEY = ''}, {24d68aa7239824e42390a77b7212fcbf
state=OFFLINE, ts=1393342242623,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552}
...
2014-02-25 15:35:26,586 DEBUG
[hor13n12.gq1.ygridcore.net,6,1393341917402-BalancerChore]
master.HMaster: Not running balancer because 1 region(s) in transition:
{24d68aa7239824e42390a77b7212fcbf={24d68aa7239824e42390a77b7212fcbf
state=OFFLINE, ts=1393342242623,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552}}
...
2014-02-25 15:35:51,945 DEBUG [FifoRpcScheduler.handler1-thread-16]
[jira] [Commented] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916171#comment-13916171 ] Enis Soztutar commented on HBASE-10601: --- Can we do this without profiles? If we can compile trunk/0.98/0.96 with just providing -Dhadoop.version=2.3.0 that will be simpler. I do not want to end up with profiles for 2.2, 2.3, 2.4, etc if they are all source compatible. Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10632) Region lost in limbo after ArrayIndexOutOfBoundsException during assignment
[
https://issues.apache.org/jira/browse/HBASE-10632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-10632:
--
Fix Version/s: 0.98.1
0.96.2
Region lost in limbo after ArrayIndexOutOfBoundsException during assignment
---
Key: HBASE-10632
URL: https://issues.apache.org/jira/browse/HBASE-10632
Project: HBase
Issue Type: Bug
Components: Region Assignment
Affects Versions: hbase-10070
Reporter: Nick Dimiduk
Assignee: Enis Soztutar
Fix For: 0.96.2, 0.98.1, 0.99.0, hbase-10070
Attachments: hbase-10632_v1.patch
Discovered while running IntegrationTestBigLinkedList. Region
24d68aa7239824e42390a77b7212fcbf is scheduled for move from hor13n19 to
hor13n13. During the process an exception is thrown.
{noformat}
2014-02-25 15:30:42,613 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
master.RegionStates: Transitioning {24d68aa7239824e42390a77b7212fcbf
state=OPENING, ts=1393342207107,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552} will be handled by SSH
for hor13n19.gq1.ygridcore.net,60020,1393341563552
2014-02-25 15:30:42,613 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
handler.ServerShutdownHandler: Reassigning 7 region(s) that
hor13n19.gq1.ygridcore.net,60020,1393341563552 was carrying (and 0 regions(s)
that were opening on this server)
2014-02-25 15:30:42,613 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
handler.ServerShutdownHandler: Reassigning region with rs =
{24d68aa7239824e42390a77b7212fcbf state=OPENING, ts=1393342207107,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552} and deleting zk node
if exists
2014-02-25 15:30:42,623 INFO [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
master.RegionStates: Transitioned {24d68aa7239824e42390a77b7212fcbf
state=OPENING, ts=1393342207107,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552} to
{24d68aa7239824e42390a77b7212fcbf state=OFFLINE, ts=1393342242623,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552}
2014-02-25 15:30:42,623 DEBUG [AM.ZK.Worker-pool2-t46]
master.AssignmentManager: Znode
IntegrationTestBigLinkedList,\x80\x06\x1A,1393342105093.24d68aa7239824e42390a77b7212fcbf.
deleted, state: {24d68aa7239824e42390a77b7212fcbf state=OFFLINE,
ts=1393342242623, server=hor13n19.gq1.ygridcore.net,60020,1393341563552}
...
2014-02-25 15:30:43,993 ERROR [MASTER_SERVER_OPERATIONS-hor13n12:6-4]
executor.EventHandler: Caught throwable while processing event
M_SERVER_SHUTDOWN
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.hadoop.hbase.master.balancer.BaseLoadBalancer$Cluster.init(BaseLoadBalancer.java:250)
at
org.apache.hadoop.hbase.master.balancer.BaseLoadBalancer.createCluster(BaseLoadBalancer.java:921)
at
org.apache.hadoop.hbase.master.balancer.BaseLoadBalancer.roundRobinAssignment(BaseLoadBalancer.java:860)
at
org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:2482)
at
org.apache.hadoop.hbase.master.handler.ServerShutdownHandler.process(ServerShutdownHandler.java:282)
at
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
After that, region is left in limbo and is never reassigned.
{noformat}
2014-02-25 15:35:11,581 INFO [FifoRpcScheduler.handler1-thread-6]
master.HMaster: Client=hrt_qa//68.142.246.29 move
hri=IntegrationTestBigLinkedList,\x80\x06\x1A,1393342105093.24d68aa7239824e42390a77b7212fcbf.,
src=hor13n19.gq1.ygridcore.net,60020,1393341563552,
dest=hor13n13.gq1.ygridcore.net,60020,139334275, running balancer
2014-02-25 15:35:11,581 INFO [FifoRpcScheduler.handler1-thread-6]
master.AssignmentManager: Ignored moving region not assigned: {ENCODED =
24d68aa7239824e42390a77b7212fcbf, NAME =
'IntegrationTestBigLinkedList,\x80\x06\x1A,1393342105093.24d68aa7239824e42390a77b7212fcbf.',
STARTKEY = '\x80\x06\x1A', ENDKEY = ''}, {24d68aa7239824e42390a77b7212fcbf
state=OFFLINE, ts=1393342242623,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552}
...
2014-02-25 15:35:26,586 DEBUG
[hor13n12.gq1.ygridcore.net,6,1393341917402-BalancerChore]
master.HMaster: Not running balancer because 1 region(s) in transition:
{24d68aa7239824e42390a77b7212fcbf={24d68aa7239824e42390a77b7212fcbf
state=OFFLINE, ts=1393342242623,
server=hor13n19.gq1.ygridcore.net,60020,1393341563552}}
...
2014-02-25 15:35:51,945 DEBUG [FifoRpcScheduler.handler1-thread-16]
master.HMaster: Client=hrt_qa//68.142.246.29 unassign
[jira] [Commented] (HBASE-10595) HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed
[ https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916180#comment-13916180 ] Enis Soztutar commented on HBASE-10595: --- bq. You meant HMaster when saying 'NN', right? I meant NameNode, not HMaster. bq. In the time interval that after table dir is moved to tmp folder and before it's removed from table descriptor cache, the results of listTables and getTableDescriptor contradict, don't you think it's a kind of inconsistency? That is an inconsistency. But completely making the cache useless is not the way to solve it I think. bq. Users are surely NOT expected to delete table directory on purpose, but if they do delete table directory by accident, we should still ensure queries on HBase states get consistent results, right? Actually some HBCK unit tests aim for ensuring consistency under such corruption from user. That is the job of HBCK. There is no guarantees expected from the master if the user deletes dirs under it. HBaseAdmin.getTableDescriptor can wrongly get the previous table's TableDescriptor even after the table dir in hdfs is removed -- Key: HBASE-10595 URL: https://issues.apache.org/jira/browse/HBASE-10595 Project: HBase Issue Type: Sub-task Components: master, util Reporter: Feng Honghua Assignee: Feng Honghua Attachments: HBASE-10595-trunk_v1.patch, HBASE-10595-trunk_v2.patch, HBASE-10595-trunk_v3.patch, HBASE-10595-trunk_v4.patch When a table dir (in hdfs) is removed(by outside), HMaster will still return the cached TableDescriptor to client for getTableDescriptor request. On the contrary, HBaseAdmin.listTables() is handled correctly in current implementation, for a table whose table dir in hdfs is removed by outside, getTableDescriptor can still retrieve back a valid (old) table descriptor, while listTables says it doesn't exist, this is inconsistent The reason for this bug is because HMaster (via FSTableDescriptors) doesn't check if the table dir exists for getTableDescriptor() request, (while it lists all existing table dirs(not firstly respects cache) and returns accordingly for listTables() request) When a table is deleted via deleteTable, the cache will be cleared after the table dir and tableInfo file is removed, listTables/getTableDescriptor inconsistency should be transient(though still exists, when table dir is removed while cache is not cleared) and harder to expose -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916184#comment-13916184 ] Lars Hofhansl commented on HBASE-10601: --- I'd say stick with profiles in 0.94, 0.96, and 0.98. Can rethink things for 0.99. Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[
https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916188#comment-13916188
]
Ted Yu commented on HBASE-10601:
I tried the following command in 0.98 :
{code}
mvn clean -Dhadoop.profile=2.0 -Dhadoop-two.version=2.3.0 package -DskipTests
{code}
I got:
{code}
[ERROR] The build could not read 1 project - [Help 1]
[ERROR]
[ERROR] The project org.apache.hbase:hbase:0.98.1-SNAPSHOT
(/Users/tyu/98/pom.xml) has 2 errors
[ERROR] 'dependencyManagement.dependencies.dependency.artifactId' for
org.apache.hbase:${compat.module}:jar with value '${compat.module}' does not
match a valid id pattern. @ line 997, column 21
[ERROR] 'dependencyManagement.dependencies.dependency.artifactId' for
org.apache.hbase:${compat.module}:test-jar with value '${compat.module}' does
not match a valid id pattern. @ line 1002, column 21
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
{code}
This was due to hadoop.profile=2.0 being the default profile in 0.98 (and trunk)
Upgrade hadoop to 2.3.0 release
---
Key: HBASE-10601
URL: https://issues.apache.org/jira/browse/HBASE-10601
Project: HBase
Issue Type: Task
Reporter: Ted Yu
Assignee: Ted Yu
Fix For: 0.99.0
Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt,
10601-0.98.txt, 10601-v1.txt
Apache Hadoop 2.3.0 has been released.
This issue is to upgrade hadoop dependency to 2.3.0
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916192#comment-13916192 ] Ted Yu commented on HBASE-10601: The command given above works for 0.96 : mvn clean -Dhadoop.profile=2.0 -Dhadoop-two.version=2.3.0 package -DskipTests Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916195#comment-13916195 ] Enis Soztutar commented on HBASE-10601: --- It is because our pom.xml fails if you give the default profile in hadoop.profile. Meaning, if you want to compile 0.98 and trunk with hadoop2, you should NOT specify a profile, while in 0.96 you SHOULD provide the hadoop.profile parameter. That is unfortunate but it is how it works for now. Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10451) Enable back Tag compression on HFiles
[
https://issues.apache.org/jira/browse/HBASE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916198#comment-13916198
]
Hadoop QA commented on HBASE-10451:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631788/HBASE-10451_V6.patch
against trunk revision .
ATTACHMENT ID: 12631788
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8855//console
This message is automatically generated.
Enable back Tag compression on HFiles
-
Key: HBASE-10451
URL: https://issues.apache.org/jira/browse/HBASE-10451
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
Priority: Critical
Fix For: 0.98.1, 0.99.0
Attachments: HBASE-10451.patch, HBASE-10451_V2.patch,
HBASE-10451_V3.patch, HBASE-10451_V4.patch, HBASE-10451_V5.patch,
HBASE-10451_V6.patch
HBASE-10443 disables tag compression on HFiles. This Jira is to fix the
issues we have found out in HBASE-10443 and enable it back.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916210#comment-13916210
]
Hudson commented on HBASE-10627:
SUCCESS: Integrated in HBase-0.94-security #427 (See
[https://builds.apache.org/job/HBase-0.94-security/427/])
HBASE-10627 A logic mistake in HRegionServer isHealthy (Shaohui) (tedyu: rev
1573016)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916254#comment-13916254
]
Hudson commented on HBASE-10627:
FAILURE: Integrated in HBase-0.94-on-Hadoop-2 #37 (See
[https://builds.apache.org/job/HBase-0.94-on-Hadoop-2/37/])
HBASE-10627 A logic mistake in HRegionServer isHealthy (Shaohui) (tedyu: rev
1573016)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10624) Fix 2 new findbugs warnings
[
https://issues.apache.org/jira/browse/HBASE-10624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916272#comment-13916272
]
Lars Hofhansl commented on HBASE-10624:
---
Hmm... I'd be happier if we had synchronized writers and the members involved
declared volatile.
The atomics are at least as expensive as a volatile.
Fix 2 new findbugs warnings
---
Key: HBASE-10624
URL: https://issues.apache.org/jira/browse/HBASE-10624
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10624-v1.txt, 10624-v2.txt, 10624-v4.txt
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp;
locked 66% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp
Synchronized 66% of the time
{code}
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp;
locked 62% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp
Synchronized 62% of the time
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10634) Multiget doesn't fully work
[ https://issues.apache.org/jira/browse/HBASE-10634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10634: - Attachment: HBASE-10634.patch Here's patch. There is one bug with how dec counters is called, I fixed it. It would dec counters even if someone else already set the result. Although I'm not sure if it's actually what's happening. Does seem to be coming from trySetResultSimple, so might be the case. Also added logging and assert before it goes into negative. Is it possible to get client logs with this patch? Is this integration test committed? Multiget doesn't fully work --- Key: HBASE-10634 URL: https://issues.apache.org/jira/browse/HBASE-10634 Project: HBase Issue Type: Sub-task Reporter: Devaraj Das Assignee: Sergey Shelukhin Fix For: hbase-10070 Attachments: 10634-1.txt, HBASE-10634.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10641) Configurable Bucket Sizes in bucketCache
Biju Nair created HBASE-10641: - Summary: Configurable Bucket Sizes in bucketCache Key: HBASE-10641 URL: https://issues.apache.org/jira/browse/HBASE-10641 Project: HBase Issue Type: Improvement Components: Admin Reporter: Biju Nair Priority: Minor In the current implementation of BucketCache, the sizes of buckets created for different blocksizes is fixed. Given that the all the blocksizes will not be used, it would be good to have the bucketCache configurable. The block sizes for which buckets need to be created and the size of the buckets for each block size should be configurable. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10641) Configurable Bucket Sizes in bucketCache
[ https://issues.apache.org/jira/browse/HBASE-10641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-10641: -- Priority: Major (was: Minor) Configurable Bucket Sizes in bucketCache Key: HBASE-10641 URL: https://issues.apache.org/jira/browse/HBASE-10641 Project: HBase Issue Type: Improvement Components: Admin Reporter: Biju Nair Labels: cache In the current implementation of BucketCache, the sizes of buckets created for different blocksizes is fixed. Given that the all the blocksizes will not be used, it would be good to have the bucketCache configurable. The block sizes for which buckets need to be created and the size of the buckets for each block size should be configurable. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10247) Client promises about timestamps
[ https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916298#comment-13916298 ] Lars Hofhansl commented on HBASE-10247: --- This would also help with: * scanning: If we scan files in creation order (starting with the memstore) we can stop when we've seen a key (we know there cannot be a newer one in a later file) * compactions: we can remove delete markers if we compact a tail (again in time order) of the HFiles. * probably many more optimization that will pop up Client promises about timestamps Key: HBASE-10247 URL: https://issues.apache.org/jira/browse/HBASE-10247 Project: HBase Issue Type: Brainstorming Reporter: Lars Hofhansl Priority: Minor This is to start a discussion about timestamp promises declared per table of CF. For example if a client promises only monotonically increasing timestamps (or no custom set timestamps) and VERSIONS=1, we can aggressively and easily remove old versions of the same row/fam/col from the memstore before we flush, just by supplying a comparator that ignores the timestamp (i.e. two KV just differing by TS would be considered equal). That would increase the performance of counters significantly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10622) Improve log and Exceptions in Export Snapshot
[ https://issues.apache.org/jira/browse/HBASE-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916308#comment-13916308 ] Jerry He commented on HBASE-10622: -- Hi, Matteo Are you reversing HBASE-9060 in the code by putting the path inthe Also, do you want to put a '%' charactor after: (totalBytesWritten/(float)inputFileSize) * 100.0f Improve log and Exceptions in Export Snapshot -- Key: HBASE-10622 URL: https://issues.apache.org/jira/browse/HBASE-10622 Project: HBase Issue Type: Bug Components: snapshots Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Fix For: 0.99.0 Attachments: HBASE-10622-v0.patch, HBASE-10622-v1.patch, HBASE-10622-v2.patch from the logs of export snapshot is not really clear what's going on, adding some extra information useful to debug, and in some places the real exception can be thrown -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10642) Add M/R over snapshots sample code to 0.94
Lars Hofhansl created HBASE-10642: - Summary: Add M/R over snapshots sample code to 0.94 Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-10642: -- Attachment: SnapshotInputFormat.java Parking here what we're (or would be) using. Will fix up packages and imports in a bit. Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 Attachments: SnapshotInputFormat.java I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10643) Failure in RS when using large size bucketcache
Biju Nair created HBASE-10643: - Summary: Failure in RS when using large size bucketcache Key: HBASE-10643 URL: https://issues.apache.org/jira/browse/HBASE-10643 Project: HBase Issue Type: Bug Components: regionserver Reporter: Biju Nair When RS is brought up with XX:MaxDirectMemorySize of 22GB or higher, RS fails after a successful start. From the RS logs it looks like the bucketCache memory allocation is taking more time makes the RS considered dead by ZK. One option to fix the problem would be to allocate the bucketCache before registering with ZK. 2014-02-28 18:54:42,967 WARN [regionserver60020.compactionChecker] util.Sleeper: We slept 33496ms instead of 1ms, this is likely due to a long garbage collecting pause and it's usually bad, see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired 2014-02-28 18:54:42,967 WARN [regionserver60020.periodicFlusher] util.Sleeper: We slept 33496ms instead of 1ms, this is likely due to a long garbage collecting pause and it's usually bad, see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired 2014-02-28 18:54:42,967 WARN [JvmPauseMonitor] util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 23988ms GC pool 'ParNew' had collection(s): count=1 time=24432ms 2014-02-28 18:54:43,006 FATAL [regionserver60020] regionserver.HRegionServer: ABORTING region server bbg-master2.bbg-test.hdp,60020,1393628951236: org.apache.hadoop.hbase.YouAreDeadException: Server REPORT rejected; currently processing bbg-master2.bbg-test.hdp,60020,1393628951236 as dead server at org.apache.hadoop.hbase.master.ServerManager.checkIsDead(ServerManager.java:341) at org.apache.hadoop.hbase.master.ServerManager.regionServerReport(ServerManager.java:254) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916316#comment-13916316 ] Nick Dimiduk commented on HBASE-10642: -- bq. I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. +1. I think this will make operations much happier. We should consider ways for jobs to selectively retrieve post-snapshot data from the online API with the bulk of data movement going through HDFS. Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 Attachments: SnapshotInputFormat.java, TestSnapshotInputFormatScan.java I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-10642: -- Attachment: TestSnapshotInputFormatScan.java And the test. Patch coming soon. Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 Attachments: SnapshotInputFormat.java, TestSnapshotInputFormatScan.java I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10643) Failure in RS when using large size bucketcache
[ https://issues.apache.org/jira/browse/HBASE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-10643: - Affects Version/s: 0.98.0 0.96.0 Failure in RS when using large size bucketcache --- Key: HBASE-10643 URL: https://issues.apache.org/jira/browse/HBASE-10643 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.98.0, 0.96.0 Reporter: Biju Nair Labels: bucketCache, regionserver When RS is brought up with XX:MaxDirectMemorySize of 22GB or higher, RS fails after a successful start. From the RS logs it looks like the bucketCache memory allocation is taking more time makes the RS considered dead by ZK. One option to fix the problem would be to allocate the bucketCache before registering with ZK. 2014-02-28 18:54:42,967 WARN [regionserver60020.compactionChecker] util.Sleeper: We slept 33496ms instead of 1ms, this is likely due to a long garbage collecting pause and it's usually bad, see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired 2014-02-28 18:54:42,967 WARN [regionserver60020.periodicFlusher] util.Sleeper: We slept 33496ms instead of 1ms, this is likely due to a long garbage collecting pause and it's usually bad, see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired 2014-02-28 18:54:42,967 WARN [JvmPauseMonitor] util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 23988ms GC pool 'ParNew' had collection(s): count=1 time=24432ms 2014-02-28 18:54:43,006 FATAL [regionserver60020] regionserver.HRegionServer: ABORTING region server bbg-master2.bbg-test.hdp,60020,1393628951236: org.apache.hadoop.hbase.YouAreDeadException: Server REPORT rejected; currently processing bbg-master2.bbg-test.hdp,60020,1393628951236 as dead server at org.apache.hadoop.hbase.master.ServerManager.checkIsDead(ServerManager.java:341) at org.apache.hadoop.hbase.master.ServerManager.regionServerReport(ServerManager.java:254) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916319#comment-13916319 ] Lars Hofhansl commented on HBASE-10642: --- [~stack], what we had discussed yesterday. Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 Attachments: SnapshotInputFormat.java, TestSnapshotInputFormatScan.java I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10622) Improve log and Exceptions in Export Snapshot
[ https://issues.apache.org/jira/browse/HBASE-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916318#comment-13916318 ] Jerry He commented on HBASE-10622: -- bq. Are you reversing HBASE-9060 in the code by putting the path inthe Are you reversing HBASE-9060 in the code by putting the path in the format? Improve log and Exceptions in Export Snapshot -- Key: HBASE-10622 URL: https://issues.apache.org/jira/browse/HBASE-10622 Project: HBase Issue Type: Bug Components: snapshots Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Fix For: 0.99.0 Attachments: HBASE-10622-v0.patch, HBASE-10622-v1.patch, HBASE-10622-v2.patch from the logs of export snapshot is not really clear what's going on, adding some extra information useful to debug, and in some places the real exception can be thrown -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916320#comment-13916320 ] Lars Hofhansl commented on HBASE-10642: --- And of course, this is almost identical to [~enis]'s original patch. Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 Attachments: SnapshotInputFormat.java, TestSnapshotInputFormatScan.java I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10624) Fix 2 new findbugs warnings
[
https://issues.apache.org/jira/browse/HBASE-10624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916323#comment-13916323
]
Ted Yu commented on HBASE-10624:
@Lars:
Do you prefer patch v2 ?
Fix 2 new findbugs warnings
---
Key: HBASE-10624
URL: https://issues.apache.org/jira/browse/HBASE-10624
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 10624-v1.txt, 10624-v2.txt, 10624-v4.txt
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp;
locked 66% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.maximumTimestamp
Synchronized 66% of the time
{code}
Inconsistent synchronization of
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp;
locked 62% of time
{code}
In class org.apache.hadoop.hbase.regionserver.TimeRangeTracker
Field org.apache.hadoop.hbase.regionserver.TimeRangeTracker.minimumTimestamp
Synchronized 62% of the time
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916327#comment-13916327
]
Hudson commented on HBASE-10627:
FAILURE: Integrated in hbase-0.96 #321 (See
[https://builds.apache.org/job/hbase-0.96/321/])
HBASE-10627 A logic mistake in HRegionServer isHealthy (Shaohui) (tedyu: rev
1573015)
*
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[
https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916332#comment-13916332
]
Hadoop QA commented on HBASE-10601:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631807/10601-v1.txt
against trunk revision .
ATTACHMENT ID: 12631807
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8856//console
This message is automatically generated.
Upgrade hadoop to 2.3.0 release
---
Key: HBASE-10601
URL: https://issues.apache.org/jira/browse/HBASE-10601
Project: HBase
Issue Type: Task
Reporter: Ted Yu
Assignee: Ted Yu
Fix For: 0.99.0
Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt,
10601-0.98.txt, 10601-v1.txt
Apache Hadoop 2.3.0 has been released.
This issue is to upgrade hadoop dependency to 2.3.0
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10622) Improve log and Exceptions in Export Snapshot
[ https://issues.apache.org/jira/browse/HBASE-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-10622: Attachment: HBASE-10622-v3.patch [~jerryhe] thanks for the catch, I forgot that that last part of the string was done on purpose... btw now the result looks like this, from the TT page: copied 52.2 M/410.1 M (12.7%) from ... copied 410.1 M/410.1 M (100.0%) from ... Improve log and Exceptions in Export Snapshot -- Key: HBASE-10622 URL: https://issues.apache.org/jira/browse/HBASE-10622 Project: HBase Issue Type: Bug Components: snapshots Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Fix For: 0.99.0 Attachments: HBASE-10622-v0.patch, HBASE-10622-v1.patch, HBASE-10622-v2.patch, HBASE-10622-v3.patch from the logs of export snapshot is not really clear what's going on, adding some extra information useful to debug, and in some places the real exception can be thrown -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916346#comment-13916346
]
Hudson commented on HBASE-10627:
FAILURE: Integrated in HBase-TRUNK #4966 (See
[https://builds.apache.org/job/HBase-TRUNK/4966/])
HBASE-10627 A logic mistake in HRegionServer isHealthy (Shaohui) (tedyu: rev
1573012)
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10638) Improve error message when there is no region server available for move
[
https://issues.apache.org/jira/browse/HBASE-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916347#comment-13916347
]
Hudson commented on HBASE-10638:
FAILURE: Integrated in HBase-TRUNK #4966 (See
[https://builds.apache.org/job/HBase-TRUNK/4966/])
HBASE-10638 Improve error message when there is no region server available for
move (tedyu: rev 1573010)
* /hbase/trunk/bin/region_mover.rb
Improve error message when there is no region server available for move
---
Key: HBASE-10638
URL: https://issues.apache.org/jira/browse/HBASE-10638
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Ted Yu
Fix For: 0.98.1, 0.99.0
Attachments: 10638-v1.txt
When there is no region server available to move regions to, we would see:
{code}
Valid region move targets:
TypeError: can't convert nil into String
__for__ at /usr/lib/hbase/bin/region_mover.rb:336
call at org/jruby/RubyProc.java:270
call at org/jruby/RubyProc.java:220
each at
file:/usr/lib/hbase/lib/jruby-complete-1.6.5.jar!/builtin/java/java.util.rb:7
unloadRegions at /usr/lib/hbase/bin/region_mover.rb:333
(root) at /usr/lib/hbase/bin/region_mover.rb:471
{code}
Better error message / exit code should be provided.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10247) Client promises about timestamps
[ https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916397#comment-13916397 ] Enis Soztutar commented on HBASE-10247: --- HBASE-9905 contains some discussions related to this. The modes proposed there is similar because they were borrowed from Lars's ideas in the first place. Client promises about timestamps Key: HBASE-10247 URL: https://issues.apache.org/jira/browse/HBASE-10247 Project: HBase Issue Type: Brainstorming Reporter: Lars Hofhansl Priority: Minor This is to start a discussion about timestamp promises declared per table of CF. For example if a client promises only monotonically increasing timestamps (or no custom set timestamps) and VERSIONS=1, we can aggressively and easily remove old versions of the same row/fam/col from the memstore before we flush, just by supplying a comparator that ignores the timestamp (i.e. two KV just differing by TS would be considered equal). That would increase the performance of counters significantly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10601: --- Attachment: 10601-v1.txt Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10601) Upgrade hadoop to 2.3.0 release
[ https://issues.apache.org/jira/browse/HBASE-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10601: --- Attachment: (was: 10601-v1.txt) Upgrade hadoop to 2.3.0 release --- Key: HBASE-10601 URL: https://issues.apache.org/jira/browse/HBASE-10601 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Fix For: 0.99.0 Attachments: 0.98-hadoop-2.3.out, 10601-0.94.txt, 10601-0.98-v2.txt, 10601-0.98.txt, 10601-v1.txt Apache Hadoop 2.3.0 has been released. This issue is to upgrade hadoop dependency to 2.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916403#comment-13916403 ] Enis Soztutar commented on HBASE-10642: --- Didn't Jesse had a patch for this I had reviewed some time ago? This only contains the IF ? Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 Attachments: SnapshotInputFormat.java, TestSnapshotInputFormatScan.java I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916401#comment-13916401
]
Hudson commented on HBASE-10627:
FAILURE: Integrated in HBase-0.94-JDK7 #69 (See
[https://builds.apache.org/job/HBase-0.94-JDK7/69/])
HBASE-10627 A logic mistake in HRegionServer isHealthy (Shaohui) (tedyu: rev
1573016)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10596) Remove deprecated Filter#getNextKeyHint(KeyValue) method
[ https://issues.apache.org/jira/browse/HBASE-10596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10596: --- Priority: Minor (was: Trivial) Remove deprecated Filter#getNextKeyHint(KeyValue) method Key: HBASE-10596 URL: https://issues.apache.org/jira/browse/HBASE-10596 Project: HBase Issue Type: Task Reporter: Ted Yu Assignee: Ted Yu Priority: Minor Fix For: 0.99.0 Filter#getNextKeyHint(KeyValue) is deprecated. Filter#getNextCellHint(Cell) should be used instead. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10627) A logic mistake in HRegionServer isHealthy
[
https://issues.apache.org/jira/browse/HBASE-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916414#comment-13916414
]
Hudson commented on HBASE-10627:
FAILURE: Integrated in HBase-0.94 #1305 (See
[https://builds.apache.org/job/HBase-0.94/1305/])
HBASE-10627 A logic mistake in HRegionServer isHealthy (Shaohui) (tedyu: rev
1573016)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
A logic mistake in HRegionServer isHealthy
--
Key: HBASE-10627
URL: https://issues.apache.org/jira/browse/HBASE-10627
Project: HBase
Issue Type: Bug
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18
Attachments: HBASE-10627-0.94-v1.diff, HBASE-10627-trunk-v1.diff
After visiting the isHealthy in HRegionServer, I think there is a logic
mistake.
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()) logic wrong here
this.periodicFlusher.isAlive()) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
which should be
{code}
// Verify that all threads are alive
if (!(leases.isAlive()
cacheFlusher.isAlive() hlogRoller.isAlive()
this.compactionChecker.isAlive()
this.periodicFlusher.isAlive())) {
stop(One or more threads are no longer alive -- stop);
return false;
}
{code}
Please finger out if i am wrong. Thx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10634) Multiget doesn't fully work
[ https://issues.apache.org/jira/browse/HBASE-10634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10634: - Attachment: HBASE-10634.patch instead of logging a lot, add long exception message Multiget doesn't fully work --- Key: HBASE-10634 URL: https://issues.apache.org/jira/browse/HBASE-10634 Project: HBase Issue Type: Sub-task Reporter: Devaraj Das Assignee: Sergey Shelukhin Fix For: hbase-10070 Attachments: 10634-1.txt, HBASE-10634.patch, HBASE-10634.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-10642: -- Attachment: (was: TestSnapshotInputFormatScan.java) Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-10642: -- Attachment: (was: SnapshotInputFormat.java) Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10642) Add M/R over snapshots sample code to 0.94
[ https://issues.apache.org/jira/browse/HBASE-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-10642: -- Attachment: 10642-0.94.txt Here's it all in form of a patch. Changes to existing HBase are trivial (just add a way to trigger snapshot M/R to TableMapReduceUtil). Add M/R over snapshots sample code to 0.94 -- Key: HBASE-10642 URL: https://issues.apache.org/jira/browse/HBASE-10642 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.94.18 Attachments: 10642-0.94.txt I think we want drive towards all (or most) M/R over HBase to be against snapshots and HDFS directly. Adopting a simple input format (even if just as a sample) as part of HBase will allow us to direct users this way. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
