[jira] [Updated] (HBASE-4676) Prefix Compression - Trie data block encoding
[ https://issues.apache.org/jira/browse/HBASE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Corgan updated HBASE-4676: --- Attachment: HBASE-4676-prefix-tree-trunk-v5.patch HBASE-4676-prefix-tree-trunk-v5.patch puts a debug message in the NPE thrown by the previous patch. The test in question passes locally. Prefix Compression - Trie data block encoding - Key: HBASE-4676 URL: https://issues.apache.org/jira/browse/HBASE-4676 Project: HBase Issue Type: New Feature Components: io, Performance, regionserver Affects Versions: 0.96.0 Reporter: Matt Corgan Assignee: Matt Corgan Attachments: HBASE-4676-0.94-v1.patch, HBASE-4676-prefix-tree-trunk-v1.patch, HBASE-4676-prefix-tree-trunk-v2.patch, HBASE-4676-prefix-tree-trunk-v3.patch, HBASE-4676-prefix-tree-trunk-v4.patch, HBASE-4676-prefix-tree-trunk-v5.patch, hbase-prefix-trie-0.1.jar, PrefixTrie_Format_v1.pdf, PrefixTrie_Performance_v1.pdf, SeeksPerSec by blockSize.png The HBase data block format has room for 2 significant improvements for applications that have high block cache hit ratios. First, there is no prefix compression, and the current KeyValue format is somewhat metadata heavy, so there can be tremendous memory bloat for many common data layouts, specifically those with long keys and short values. Second, there is no random access to KeyValues inside data blocks. This means that every time you double the datablock size, average seek time (or average cpu consumption) goes up by a factor of 2. The standard 64KB block size is ~10x slower for random seeks than a 4KB block size, but block sizes as small as 4KB cause problems elsewhere. Using block sizes of 256KB or 1MB or more may be more efficient from a disk access and block-cache perspective in many big-data applications, but doing so is infeasible from a random seek perspective. The PrefixTrie block encoding format attempts to solve both of these problems. Some features: * trie format for row key encoding completely eliminates duplicate row keys and encodes similar row keys into a standard trie structure which also saves a lot of space * the column family is currently stored once at the beginning of each block. this could easily be modified to allow multiple family names per block * all qualifiers in the block are stored in their own trie format which caters nicely to wide rows. duplicate qualifers between rows are eliminated. the size of this trie determines the width of the block's qualifier fixed-width-int * the minimum timestamp is stored at the beginning of the block, and deltas are calculated from that. the maximum delta determines the width of the block's timestamp fixed-width-int The block is structured with metadata at the beginning, then a section for the row trie, then the column trie, then the timestamp deltas, and then then all the values. Most work is done in the row trie, where every leaf node (corresponding to a row) contains a list of offsets/references corresponding to the cells in that row. Each cell is fixed-width to enable binary searching and is represented by [1 byte operationType, X bytes qualifier offset, X bytes timestamp delta offset]. If all operation types are the same for a block, there will be zero per-cell overhead. Same for timestamps. Same for qualifiers when i get a chance. So, the compression aspect is very strong, but makes a few small sacrifices on VarInt size to enable faster binary searches in trie fan-out nodes. A more compressed but slower version might build on this by also applying further (suffix, etc) compression on the trie nodes at the cost of slower write speed. Even further compression could be obtained by using all VInts instead of FInts with a sacrifice on random seek speed (though not huge). One current drawback is the current write speed. While programmed with good constructs like TreeMaps, ByteBuffers, binary searches, etc, it's not programmed with the same level of optimization as the read path. Work will need to be done to optimize the data structures used for encoding and could probably show a 10x increase. It will still be slower than delta encoding, but with a much higher decode speed. I have not yet created a thorough benchmark for write speed nor sequential read speed. Though the trie is reaching a point where it is internally very efficient (probably within half or a quarter of its max read speed) the way that hbase currently uses it is far from optimal. The KeyValueScanner and related classes that iterate through the trie will eventually need to be smarter and have methods to do things like skipping to the next row of results without scanning every cell in between. When
[jira] [Updated] (HBASE-6642) enable_all,disable_all,drop_all can call list command with regex directly.
[
https://issues.apache.org/jira/browse/HBASE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-6642:
--
Summary: enable_all,disable_all,drop_all can call list command with regex
directly. (was: disable_all '*' is not performing disable operation.)
enable_all,disable_all,drop_all can call list command with regex directly.
Key: HBASE-6642
URL: https://issues.apache.org/jira/browse/HBASE-6642
Project: HBase
Issue Type: Bug
Components: shell
Reporter: Y. SREENIVASULU REDDY
Assignee: rajeshbabu
created few tables. then performing disable_all operation in shell prompt.
but it is not performing operation successfully.
{noformat}
hbase(main):043:0 disable_all '*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y/
3 tables successfully disabled
just it is showing the message but operation is not success.
but the following way only performing successfully
hbase(main):043:0 disable_all '*.*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y
3 tables successfully disabled
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6642) enable_all,disable_all,drop_all can call list command with regex directly.
[
https://issues.apache.org/jira/browse/HBASE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-6642:
--
Attachment: HBASE-6642_trunk.patch
Patch for trunk. If its ok I will upload patch for 94,92.
enable_all,disable_all,drop_all can call list command with regex directly.
Key: HBASE-6642
URL: https://issues.apache.org/jira/browse/HBASE-6642
Project: HBase
Issue Type: Bug
Components: shell
Reporter: Y. SREENIVASULU REDDY
Assignee: rajeshbabu
Attachments: HBASE-6642_trunk.patch
created few tables. then performing disable_all operation in shell prompt.
but it is not performing operation successfully.
{noformat}
hbase(main):043:0 disable_all '*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y/
3 tables successfully disabled
just it is showing the message but operation is not success.
but the following way only performing successfully
hbase(main):043:0 disable_all '*.*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y
3 tables successfully disabled
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6642) enable_all,disable_all,drop_all can call list command with regex directly.
[
https://issues.apache.org/jira/browse/HBASE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-6642:
--
Fix Version/s: 0.96.0
0.94.3
0.92.3
Affects Version/s: 0.92.2
0.94.0
Status: Patch Available (was: Open)
enable_all,disable_all,drop_all can call list command with regex directly.
Key: HBASE-6642
URL: https://issues.apache.org/jira/browse/HBASE-6642
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 0.94.0, 0.92.2
Reporter: Y. SREENIVASULU REDDY
Assignee: rajeshbabu
Fix For: 0.92.3, 0.94.3, 0.96.0
Attachments: HBASE-6642_trunk.patch
created few tables. then performing disable_all operation in shell prompt.
but it is not performing operation successfully.
{noformat}
hbase(main):043:0 disable_all '*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y/
3 tables successfully disabled
just it is showing the message but operation is not success.
but the following way only performing successfully
hbase(main):043:0 disable_all '*.*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y
3 tables successfully disabled
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493828#comment-13493828 ] Varun Sharma commented on HBASE-4583: - In the spirit of HBASE-7051 which fixes the race condition between put and checkAndPut for both 0.94 and 0.96 - I think we should at least fix the race condition for 0.94 for Append and Increment operations, like we did for checkAndPut. I would also be in favour of fixing the entire issue for 0.94, now that we have a very elegant and clear patch for 0.96. Unless, there are strong objections, I can help replicate this patch for 0.94 ? Integrate RWCC with Append and Increment operations --- Key: HBASE-4583 URL: https://issues.apache.org/jira/browse/HBASE-4583 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0 Attachments: 4583-mixed.txt, 4583-mixed-v2.txt, 4583-mixed-v4.txt, 4583-trunk-less-radical.txt, 4583-trunk-less-radical-v2.txt, 4583-trunk-less-radical-v3.txt, 4583-trunk-less-radical-v4.txt, 4583-trunk-less-radical-v5.txt, 4583-trunk-less-radical-v6.txt, 4583-trunk-radical.txt, 4583-trunk-radical_v2.txt, 4583-trunk-v3.txt, 4583.txt, 4583-v2.txt, 4583-v3.txt, 4583-v4.txt Currently Increment and Append operations do not work with RWCC and hence a client could see the results of multiple such operation mixed in the same Get/Scan. The semantics might be a bit more interesting here as upsert adds and removes to and from the memstore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6642) enable_all,disable_all,drop_all can call list command with regex directly.
[
https://issues.apache.org/jira/browse/HBASE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493830#comment-13493830
]
ramkrishna.s.vasudevan commented on HBASE-6642:
---
Pls check the same with other expressions? If things are fine then its ok..
enable_all,disable_all,drop_all can call list command with regex directly.
Key: HBASE-6642
URL: https://issues.apache.org/jira/browse/HBASE-6642
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 0.92.2, 0.94.0
Reporter: Y. SREENIVASULU REDDY
Assignee: rajeshbabu
Fix For: 0.92.3, 0.94.3, 0.96.0
Attachments: HBASE-6642_trunk.patch
created few tables. then performing disable_all operation in shell prompt.
but it is not performing operation successfully.
{noformat}
hbase(main):043:0 disable_all '*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y/
3 tables successfully disabled
just it is showing the message but operation is not success.
but the following way only performing successfully
hbase(main):043:0 disable_all '*.*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y
3 tables successfully disabled
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4676) Prefix Compression - Trie data block encoding
[
https://issues.apache.org/jira/browse/HBASE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493840#comment-13493840
]
Hadoop QA commented on HBASE-4676:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552792/HBASE-4676-prefix-tree-trunk-v5.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 142
new or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
103 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 58 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 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.io.hfile.TestForceCacheImportantBlocks
org.apache.hadoop.hbase.TestDrainingServer
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3286//console
This message is automatically generated.
Prefix Compression - Trie data block encoding
-
Key: HBASE-4676
URL: https://issues.apache.org/jira/browse/HBASE-4676
Project: HBase
Issue Type: New Feature
Components: io, Performance, regionserver
Affects Versions: 0.96.0
Reporter: Matt Corgan
Assignee: Matt Corgan
Attachments: HBASE-4676-0.94-v1.patch,
HBASE-4676-prefix-tree-trunk-v1.patch, HBASE-4676-prefix-tree-trunk-v2.patch,
HBASE-4676-prefix-tree-trunk-v3.patch, HBASE-4676-prefix-tree-trunk-v4.patch,
HBASE-4676-prefix-tree-trunk-v5.patch, hbase-prefix-trie-0.1.jar,
PrefixTrie_Format_v1.pdf, PrefixTrie_Performance_v1.pdf, SeeksPerSec by
blockSize.png
The HBase data block format has room for 2 significant improvements for
applications that have high block cache hit ratios.
First, there is no prefix compression, and the current KeyValue format is
somewhat metadata heavy, so there can be tremendous memory bloat for many
common data layouts, specifically those with long keys and short values.
Second, there is no random access to KeyValues inside data blocks. This
means that every time you double the datablock size, average seek time (or
average cpu consumption) goes up by a factor of 2. The standard 64KB block
size is ~10x slower for random seeks than a 4KB block size, but block sizes
as small as 4KB cause problems elsewhere. Using block sizes of 256KB or 1MB
or more may be more efficient from a disk access and block-cache perspective
in many big-data applications, but doing so is infeasible from a random seek
perspective.
The PrefixTrie block encoding format attempts to solve both of these
problems. Some features:
* trie format for row key encoding completely eliminates duplicate row keys
and encodes similar row keys into a standard trie structure which also saves
a lot of space
* the column family is currently stored once at the beginning of each block.
this could easily be modified to allow multiple family names per block
* all qualifiers in the block are stored in their own trie format which
caters nicely to wide rows. duplicate qualifers between rows are eliminated.
the size of this
[jira] [Commented] (HBASE-6642) enable_all,disable_all,drop_all can call list command with regex directly.
[
https://issues.apache.org/jira/browse/HBASE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493847#comment-13493847
]
Hadoop QA commented on HBASE-6642:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552795/HBASE-6642_trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3287//console
This message is automatically generated.
enable_all,disable_all,drop_all can call list command with regex directly.
Key: HBASE-6642
URL: https://issues.apache.org/jira/browse/HBASE-6642
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 0.92.2, 0.94.0
Reporter: Y. SREENIVASULU REDDY
Assignee: rajeshbabu
Fix For: 0.92.3, 0.94.3, 0.96.0
Attachments: HBASE-6642_trunk.patch
created few tables. then performing disable_all operation in shell prompt.
but it is not performing operation successfully.
{noformat}
hbase(main):043:0 disable_all '*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y/
3 tables successfully disabled
just it is showing the message but operation is not success.
but the following way only performing successfully
hbase(main):043:0 disable_all '*.*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y
3 tables successfully disabled
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6642) enable_all,disable_all,drop_all can call list command with regex directly.
[
https://issues.apache.org/jira/browse/HBASE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493848#comment-13493848
]
rajeshbabu commented on HBASE-6642:
---
@Ram
tested with some basic regular expressions like t.*,.*,[t].*,'t\d\d\d','table'
and some more also. Its working fine.
enable_all,disable_all,drop_all can call list command with regex directly.
Key: HBASE-6642
URL: https://issues.apache.org/jira/browse/HBASE-6642
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 0.92.2, 0.94.0
Reporter: Y. SREENIVASULU REDDY
Assignee: rajeshbabu
Fix For: 0.92.3, 0.94.3, 0.96.0
Attachments: HBASE-6642_trunk.patch
created few tables. then performing disable_all operation in shell prompt.
but it is not performing operation successfully.
{noformat}
hbase(main):043:0 disable_all '*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y/
3 tables successfully disabled
just it is showing the message but operation is not success.
but the following way only performing successfully
hbase(main):043:0 disable_all '*.*'
table12
zk0113
zk0114
Disable the above 3 tables (y/n)?
y
3 tables successfully disabled
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6356) printStackTrace in FSUtils
[
https://issues.apache.org/jira/browse/HBASE-6356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493873#comment-13493873
]
nkeywal commented on HBASE-6356:
I was wondering what Path#toString() exactly returns. There is no javadoc (at
least in version 1.1), but I checked the source code, and yes, it returns the
full patch, so I think it's ok to use it as you did.
printStackTrace in FSUtils
--
Key: HBASE-6356
URL: https://issues.apache.org/jira/browse/HBASE-6356
Project: HBase
Issue Type: Bug
Components: Client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal
Priority: Trivial
Labels: noob
This is bad...
{noformat}
public boolean accept(Path p) {
boolean isValid = false;
try {
if (HConstants.HBASE_NON_USER_TABLE_DIRS.contains(p.toString())) {
isValid = false;
} else {
isValid = this.fs.getFileStatus(p).isDir();
}
} catch (IOException e) {
e.printStackTrace();
}
return isValid;
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7137) Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays
Hiroshi Ikeda created HBASE-7137: Summary: Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays Key: HBASE-7137 URL: https://issues.apache.org/jira/browse/HBASE-7137 Project: HBase Issue Type: Improvement Reporter: Hiroshi Ikeda Priority: Minor Inside HBase, it seems that there is the implicit assumption that byte buffers have backed arrays and are not read-only, and we can freely call ByteBuffer.array() and arrayOffset() without runtime exceptions. But some classes, including Bytes, are supposed to be used by users from outside of HBase, and we should think the possibility that methods receive byte buffers which don't hold the assumption. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7137) Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays
[ https://issues.apache.org/jira/browse/HBASE-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroshi Ikeda updated HBASE-7137: - Attachment: HBASE-7137.patch Added a patch. Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays Key: HBASE-7137 URL: https://issues.apache.org/jira/browse/HBASE-7137 Project: HBase Issue Type: Improvement Reporter: Hiroshi Ikeda Priority: Minor Attachments: HBASE-7137.patch Inside HBase, it seems that there is the implicit assumption that byte buffers have backed arrays and are not read-only, and we can freely call ByteBuffer.array() and arrayOffset() without runtime exceptions. But some classes, including Bytes, are supposed to be used by users from outside of HBase, and we should think the possibility that methods receive byte buffers which don't hold the assumption. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7137) Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays
[ https://issues.apache.org/jira/browse/HBASE-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroshi Ikeda updated HBASE-7137: - Status: Patch Available (was: Open) Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays Key: HBASE-7137 URL: https://issues.apache.org/jira/browse/HBASE-7137 Project: HBase Issue Type: Improvement Reporter: Hiroshi Ikeda Priority: Minor Attachments: HBASE-7137.patch Inside HBase, it seems that there is the implicit assumption that byte buffers have backed arrays and are not read-only, and we can freely call ByteBuffer.array() and arrayOffset() without runtime exceptions. But some classes, including Bytes, are supposed to be used by users from outside of HBase, and we should think the possibility that methods receive byte buffers which don't hold the assumption. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7138) RegionSplitter's rollingSplit terminated with / by zero, and the _balancedSplit file was not deleted properly
Davey Yan created HBASE-7138:
Summary: RegionSplitter's rollingSplit terminated with / by
zero, and the _balancedSplit file was not deleted properly
Key: HBASE-7138
URL: https://issues.apache.org/jira/browse/HBASE-7138
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.94.1
Environment: Ubuntu Server 10.04, Hadoop 1.0.3
Reporter: Davey Yan
Priority: Minor
The 'splitCount' in this line is zero in some scenario, then throw
ArithmeticException: / by zero, and the '_balancedSplit' file was not deleted:
{code:java}
LOG.debug(Avg Time / Split =
+ org.apache.hadoop.util.StringUtils.formatTime(tDiff / splitCount));
{code}
Steps to reproduce:
{code}
shell create 'test2', 'i'
shell for i in 'a'..'z' do for j in 'a'..'z' do put 'test2', #{i}#{j},
i:#{j}, #{j} end end
{code}
{noformat}
$ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 test2
HexStringSplit
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:zookeeper.version=3.4.3-1240972, built on 02/06/2012 10:48 GMT
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client environment:host.name=dev-vm0
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.version=1.6.0_29
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client environment:java.vendor=Sun
Microsystems Inc.
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.home=/usr/lib/jvm/jdk1.6.0_29/jre
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.class.path=/opt/hbase/bin/../conf:/usr/lib/jvm/default-java/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../hbase-0.94.1.jar:/opt/hbase/bin/../hbase-0.94.1-tests.jar:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/avro-1.5.3.jar:/opt/hbase/bin/../lib/avro-ipc-1.5.3.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.4.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.1.jar:/opt/hbase/bin/../lib/commons-lang-2.5.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.1.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/guava-11.0.2.jar:/opt/hbase/bin/../lib/hadoop-core-1.0.3.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/httpclient-4.1.2.jar:/opt/hbase/bin/../lib/httpcore-4.1.3.jar:/opt/hbase/bin/../lib/jackson-core-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-jaxrs-1.8.8.jar:/opt/hbase/bin/../lib/jackson-mapper-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-xc-1.8.8.jar:/opt/hbase/bin/../lib/jamon-runtime-2.3.1.jar:/opt/hbase/bin/../lib/jasper-compiler-5.5.23.jar:/opt/hbase/bin/../lib/jasper-runtime-5.5.23.jar:/opt/hbase/bin/../lib/jaxb-api-2.1.jar:/opt/hbase/bin/../lib/jaxb-impl-2.2.3-1.jar:/opt/hbase/bin/../lib/jersey-core-1.8.jar:/opt/hbase/bin/../lib/jersey-json-1.8.jar:/opt/hbase/bin/../lib/jersey-server-1.8.jar:/opt/hbase/bin/../lib/jettison-1.1.jar:/opt/hbase/bin/../lib/jetty-6.1.26.jar:/opt/hbase/bin/../lib/jetty-util-6.1.26.jar:/opt/hbase/bin/../lib/jruby-complete-1.6.5.jar:/opt/hbase/bin/../lib/jsp-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsp-api-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsr305-1.3.9.jar:/opt/hbase/bin/../lib/junit-4.10-HBASE-1.jar:/opt/hbase/bin/../lib/libthrift-0.8.0.jar:/opt/hbase/bin/../lib/log4j-1.2.16.jar:/opt/hbase/bin/../lib/metrics-core-2.1.2.jar:/opt/hbase/bin/../lib/netty-3.2.4.Final.jar:/opt/hbase/bin/../lib/protobuf-java-2.4.0a.jar:/opt/hbase/bin/../lib/servlet-api-2.5-6.1.14.jar:/opt/hbase/bin/../lib/slf4j-api-1.4.3.jar:/opt/hbase/bin/../lib/slf4j-log4j12-1.4.3.jar:/opt/hbase/bin/../lib/snappy-java-1.0.3.2.jar:/opt/hbase/bin/../lib/stax-api-1.0.1.jar:/opt/hbase/bin/../lib/velocity-1.7.jar:/opt/hbase/bin/../lib/xmlenc-0.52.jar:/opt/hbase/bin/../lib/zookeeper-3.4.3.jar:/opt/hbase/bin/../libextra/mybk-commons-cc.jar:/opt/hbase/bin/../libextra/hbase.jar:/opt/hbase/bin/../libextra/sfdcloud-hbase.jar:
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.library.path=/opt/hbase/bin/../lib/native/Linux-i386-32
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.io.tmpdir=/tmp
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.compiler=NA
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client environment:os.name=Linux
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client environment:os.arch=i386
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:os.version=2.6.32-33-generic
12/11/08 19:20:40 INFO
[jira] [Updated] (HBASE-6317) Master clean start up and Partially enabled tables make region assignment inconsistent.
[
https://issues.apache.org/jira/browse/HBASE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-6317:
--
Attachment: HBASE-6317_94_4.patch
Patch for 94. Please review and provide comments/suggestions.
@Lars,@Ram
Sorry for delay.
Master clean start up and Partially enabled tables make region assignment
inconsistent.
---
Key: HBASE-6317
URL: https://issues.apache.org/jira/browse/HBASE-6317
Project: HBase
Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
Assignee: rajeshbabu
Fix For: 0.92.3, 0.96.0, 0.94.4
Attachments: HBASE-6317_94_3.patch, HBASE-6317_94_4.patch,
HBASE-6317_94.patch, HBASE-6317_trunk_2.patch, HBASE-6317_trunk_3.patch,
HBASE-6317_trunk_4.patch, HBASE-6317_trunk_5.patch
If we have a table in partially enabled state (ENABLING) then on HMaster
restart we treat it as a clean cluster start up and do a bulk assign.
Currently in 0.94 bulk assign will not handle ALREADY_OPENED scenarios and it
leads to region assignment problems. Analysing more on this we found that we
have better way to handle these scenarios.
{code}
if (false == checkIfRegionBelongsToDisabled(regionInfo)
false == checkIfRegionsBelongsToEnabling(regionInfo)) {
synchronized (this.regions) {
regions.put(regionInfo, regionLocation);
addToServers(regionLocation, regionInfo);
}
{code}
We dont add to regions map so that enable table handler can handle it. But
as nothing is added to regions map we think it as a clean cluster start up.
Will come up with a patch tomorrow.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7138) RegionSplitter's rollingSplit terminated with / by zero, and the _balancedSplit file was not deleted properly
[
https://issues.apache.org/jira/browse/HBASE-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davey Yan updated HBASE-7138:
-
Attachment: RegionSplitter_HBASE-7138-0.94.patch
RegionSplitter_HBASE-7138.patch
RegionSplitter's rollingSplit terminated with / by zero, and the
_balancedSplit file was not deleted properly
---
Key: HBASE-7138
URL: https://issues.apache.org/jira/browse/HBASE-7138
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.94.1
Environment: Ubuntu Server 10.04, Hadoop 1.0.3
Reporter: Davey Yan
Priority: Minor
Attachments: RegionSplitter_HBASE-7138-0.94.patch,
RegionSplitter_HBASE-7138.patch
The 'splitCount' in this line is zero in some scenario, then throw
ArithmeticException: / by zero, and the '_balancedSplit' file was not deleted:
{code:java}
LOG.debug(Avg Time / Split =
+ org.apache.hadoop.util.StringUtils.formatTime(tDiff /
splitCount));
{code}
Steps to reproduce:
{code}
shell create 'test2', 'i'
shell for i in 'a'..'z' do for j in 'a'..'z' do put 'test2', #{i}#{j},
i:#{j}, #{j} end end
{code}
{noformat}
$ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 test2
HexStringSplit
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:zookeeper.version=3.4.3-1240972, built on 02/06/2012 10:48 GMT
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:host.name=dev-vm0
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.version=1.6.0_29
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.vendor=Sun Microsystems Inc.
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.home=/usr/lib/jvm/jdk1.6.0_29/jre
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.class.path=/opt/hbase/bin/../conf:/usr/lib/jvm/default-java/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../hbase-0.94.1.jar:/opt/hbase/bin/../hbase-0.94.1-tests.jar:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/avro-1.5.3.jar:/opt/hbase/bin/../lib/avro-ipc-1.5.3.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.4.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.1.jar:/opt/hbase/bin/../lib/commons-lang-2.5.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.1.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/guava-11.0.2.jar:/opt/hbase/bin/../lib/hadoop-core-1.0.3.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/httpclient-4.1.2.jar:/opt/hbase/bin/../lib/httpcore-4.1.3.jar:/opt/hbase/bin/../lib/jackson-core-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-jaxrs-1.8.8.jar:/opt/hbase/bin/../lib/jackson-mapper-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-xc-1.8.8.jar:/opt/hbase/bin/../lib/jamon-runtime-2.3.1.jar:/opt/hbase/bin/../lib/jasper-compiler-5.5.23.jar:/opt/hbase/bin/../lib/jasper-runtime-5.5.23.jar:/opt/hbase/bin/../lib/jaxb-api-2.1.jar:/opt/hbase/bin/../lib/jaxb-impl-2.2.3-1.jar:/opt/hbase/bin/../lib/jersey-core-1.8.jar:/opt/hbase/bin/../lib/jersey-json-1.8.jar:/opt/hbase/bin/../lib/jersey-server-1.8.jar:/opt/hbase/bin/../lib/jettison-1.1.jar:/opt/hbase/bin/../lib/jetty-6.1.26.jar:/opt/hbase/bin/../lib/jetty-util-6.1.26.jar:/opt/hbase/bin/../lib/jruby-complete-1.6.5.jar:/opt/hbase/bin/../lib/jsp-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsp-api-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsr305-1.3.9.jar:/opt/hbase/bin/../lib/junit-4.10-HBASE-1.jar:/opt/hbase/bin/../lib/libthrift-0.8.0.jar:/opt/hbase/bin/../lib/log4j-1.2.16.jar:/opt/hbase/bin/../lib/metrics-core-2.1.2.jar:/opt/hbase/bin/../lib/netty-3.2.4.Final.jar:/opt/hbase/bin/../lib/protobuf-java-2.4.0a.jar:/opt/hbase/bin/../lib/servlet-api-2.5-6.1.14.jar:/opt/hbase/bin/../lib/slf4j-api-1.4.3.jar:/opt/hbase/bin/../lib/slf4j-log4j12-1.4.3.jar:/opt/hbase/bin/../lib/snappy-java-1.0.3.2.jar:/opt/hbase/bin/../lib/stax-api-1.0.1.jar:/opt/hbase/bin/../lib/velocity-1.7.jar:/opt/hbase/bin/../lib/xmlenc-0.52.jar:/opt/hbase/bin/../lib/zookeeper-3.4.3.jar:/opt/hbase/bin/../libextra/mybk-commons-cc.jar:/opt/hbase/bin/../libextra/hbase.jar:/opt/hbase/bin/../libextra/sfdcloud-hbase.jar:
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.library.path=/opt/hbase/bin/../lib/native/Linux-i386-32
[jira] [Created] (HBASE-7139) RegionSplitter's rollingSplit cannot split empty table or region
Davey Yan created HBASE-7139:
Summary: RegionSplitter's rollingSplit cannot split empty table or
region
Key: HBASE-7139
URL: https://issues.apache.org/jira/browse/HBASE-7139
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.94.1
Environment: Ubuntu Server 10.04, Hadoop 1.0.3
Reporter: Davey Yan
Execute rollingSplit on empty table or region will cause original region in
SPLITTING state, and will be not out of transition list unless unassigning it
(with forse) in shell.
Steps to reproduce:
{code}
shell create 'test2', 'i'
{code}
{noformat}
$ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 test2
HexStringSplit
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:zookeeper.version=3.4.3-1240972, built on 02/06/2012 10:48 GMT
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:host.name=dev-vm0
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.version=1.6.0_29
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:java.vendor=Sun
Microsystems Inc.
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.home=/usr/lib/jvm/jdk1.6.0_29/jre
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.class.path=/opt/hbase/bin/../conf:/usr/lib/jvm/default-java/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../hbase-0.94.1.jar:/opt/hbase/bin/../hbase-0.94.1-tests.jar:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/avro-1.5.3.jar:/opt/hbase/bin/../lib/avro-ipc-1.5.3.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.4.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.1.jar:/opt/hbase/bin/../lib/commons-lang-2.5.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.1.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/guava-11.0.2.jar:/opt/hbase/bin/../lib/hadoop-core-1.0.3.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/httpclient-4.1.2.jar:/opt/hbase/bin/../lib/httpcore-4.1.3.jar:/opt/hbase/bin/../lib/jackson-core-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-jaxrs-1.8.8.jar:/opt/hbase/bin/../lib/jackson-mapper-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-xc-1.8.8.jar:/opt/hbase/bin/../lib/jamon-runtime-2.3.1.jar:/opt/hbase/bin/../lib/jasper-compiler-5.5.23.jar:/opt/hbase/bin/../lib/jasper-runtime-5.5.23.jar:/opt/hbase/bin/../lib/jaxb-api-2.1.jar:/opt/hbase/bin/../lib/jaxb-impl-2.2.3-1.jar:/opt/hbase/bin/../lib/jersey-core-1.8.jar:/opt/hbase/bin/../lib/jersey-json-1.8.jar:/opt/hbase/bin/../lib/jersey-server-1.8.jar:/opt/hbase/bin/../lib/jettison-1.1.jar:/opt/hbase/bin/../lib/jetty-6.1.26.jar:/opt/hbase/bin/../lib/jetty-util-6.1.26.jar:/opt/hbase/bin/../lib/jruby-complete-1.6.5.jar:/opt/hbase/bin/../lib/jsp-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsp-api-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsr305-1.3.9.jar:/opt/hbase/bin/../lib/junit-4.10-HBASE-1.jar:/opt/hbase/bin/../lib/libthrift-0.8.0.jar:/opt/hbase/bin/../lib/log4j-1.2.16.jar:/opt/hbase/bin/../lib/metrics-core-2.1.2.jar:/opt/hbase/bin/../lib/netty-3.2.4.Final.jar:/opt/hbase/bin/../lib/protobuf-java-2.4.0a.jar:/opt/hbase/bin/../lib/servlet-api-2.5-6.1.14.jar:/opt/hbase/bin/../lib/slf4j-api-1.4.3.jar:/opt/hbase/bin/../lib/slf4j-log4j12-1.4.3.jar:/opt/hbase/bin/../lib/snappy-java-1.0.3.2.jar:/opt/hbase/bin/../lib/stax-api-1.0.1.jar:/opt/hbase/bin/../lib/velocity-1.7.jar:/opt/hbase/bin/../lib/xmlenc-0.52.jar:/opt/hbase/bin/../lib/zookeeper-3.4.3.jar:/opt/hbase/bin/../libextra/mybk-commons-cc.jar:/opt/hbase/bin/../libextra/hbase.jar:/opt/hbase/bin/../libextra/sfdcloud-hbase.jar:
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.library.path=/opt/hbase/bin/../lib/native/Linux-i386-32
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.io.tmpdir=/tmp
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.compiler=NA
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:os.name=Linux
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:os.arch=i386
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:os.version=2.6.32-33-generic
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:user.name=pcer
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:user.home=/home/pcer
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:user.dir=/opt/hbase-0.94.1
12/11/09 16:24:57 INFO zookeeper.ZooKeeper:
[jira] [Updated] (HBASE-7139) RegionSplitter's rollingSplit cannot split empty table or region
[
https://issues.apache.org/jira/browse/HBASE-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davey Yan updated HBASE-7139:
-
Description:
Execute rollingSplit on empty table or region will cause original region in
SPLITTING state, and will be not out of transition list unless unassigning it
(with forse) in shell.
Steps to reproduce:
{code}
shell create 'test2', 'i'
{code}
{noformat}
$ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 test2
HexStringSplit
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:zookeeper.version=3.4.3-1240972, built on 02/06/2012 10:48 GMT
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:host.name=dev-vm0
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.version=1.6.0_29
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:java.vendor=Sun
Microsystems Inc.
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.home=/usr/lib/jvm/jdk1.6.0_29/jre
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.class.path=/opt/hbase/bin/../conf:/usr/lib/jvm/default-java/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../hbase-0.94.1.jar:/opt/hbase/bin/../hbase-0.94.1-tests.jar:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/avro-1.5.3.jar:/opt/hbase/bin/../lib/avro-ipc-1.5.3.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.4.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.1.jar:/opt/hbase/bin/../lib/commons-lang-2.5.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.1.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/guava-11.0.2.jar:/opt/hbase/bin/../lib/hadoop-core-1.0.3.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/httpclient-4.1.2.jar:/opt/hbase/bin/../lib/httpcore-4.1.3.jar:/opt/hbase/bin/../lib/jackson-core-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-jaxrs-1.8.8.jar:/opt/hbase/bin/../lib/jackson-mapper-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-xc-1.8.8.jar:/opt/hbase/bin/../lib/jamon-runtime-2.3.1.jar:/opt/hbase/bin/../lib/jasper-compiler-5.5.23.jar:/opt/hbase/bin/../lib/jasper-runtime-5.5.23.jar:/opt/hbase/bin/../lib/jaxb-api-2.1.jar:/opt/hbase/bin/../lib/jaxb-impl-2.2.3-1.jar:/opt/hbase/bin/../lib/jersey-core-1.8.jar:/opt/hbase/bin/../lib/jersey-json-1.8.jar:/opt/hbase/bin/../lib/jersey-server-1.8.jar:/opt/hbase/bin/../lib/jettison-1.1.jar:/opt/hbase/bin/../lib/jetty-6.1.26.jar:/opt/hbase/bin/../lib/jetty-util-6.1.26.jar:/opt/hbase/bin/../lib/jruby-complete-1.6.5.jar:/opt/hbase/bin/../lib/jsp-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsp-api-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsr305-1.3.9.jar:/opt/hbase/bin/../lib/junit-4.10-HBASE-1.jar:/opt/hbase/bin/../lib/libthrift-0.8.0.jar:/opt/hbase/bin/../lib/log4j-1.2.16.jar:/opt/hbase/bin/../lib/metrics-core-2.1.2.jar:/opt/hbase/bin/../lib/netty-3.2.4.Final.jar:/opt/hbase/bin/../lib/protobuf-java-2.4.0a.jar:/opt/hbase/bin/../lib/servlet-api-2.5-6.1.14.jar:/opt/hbase/bin/../lib/slf4j-api-1.4.3.jar:/opt/hbase/bin/../lib/slf4j-log4j12-1.4.3.jar:/opt/hbase/bin/../lib/snappy-java-1.0.3.2.jar:/opt/hbase/bin/../lib/stax-api-1.0.1.jar:/opt/hbase/bin/../lib/velocity-1.7.jar:/opt/hbase/bin/../lib/xmlenc-0.52.jar:/opt/hbase/bin/../lib/zookeeper-3.4.3.jar:/opt/hbase/bin/../libextra/mybk-commons-cc.jar:/opt/hbase/bin/../libextra/hbase.jar:/opt/hbase/bin/../libextra/sfdcloud-hbase.jar:
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.library.path=/opt/hbase/bin/../lib/native/Linux-i386-32
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.io.tmpdir=/tmp
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:java.compiler=NA
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:os.name=Linux
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:os.arch=i386
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:os.version=2.6.32-33-generic
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client environment:user.name=pcer
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:user.home=/home/pcer
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Client
environment:user.dir=/opt/hbase-0.94.1
12/11/09 16:24:57 INFO zookeeper.ZooKeeper: Initiating client connection,
connectString=dev-vm0:2181 sessionTimeout=6 watcher=hconnection
12/11/09 16:24:57 INFO zookeeper.ClientCnxn: Opening socket connection to
server /172.16.20.140:2181
12/11/09 16:24:57 INFO zookeeper.RecoverableZooKeeper:
[jira] [Commented] (HBASE-7137) Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays
[
https://issues.apache.org/jira/browse/HBASE-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493932#comment-13493932
]
Hadoop QA commented on HBASE-7137:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552808/HBASE-7137.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3288//console
This message is automatically generated.
Improve Bytes to accept byte buffers which don't allow us to directly access
thier backed arrays
Key: HBASE-7137
URL: https://issues.apache.org/jira/browse/HBASE-7137
Project: HBase
Issue Type: Improvement
Reporter: Hiroshi Ikeda
Priority: Minor
Attachments: HBASE-7137.patch
Inside HBase, it seems that there is the implicit assumption that byte
buffers have backed arrays and are not read-only, and we can freely call
ByteBuffer.array() and arrayOffset() without runtime exceptions.
But some classes, including Bytes, are supposed to be used by users from
outside of HBase, and we should think the possibility that methods receive
byte buffers which don't hold the assumption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7138) RegionSplitter's rollingSplit terminated with / by zero, and the _balancedSplit file was not deleted properly
[
https://issues.apache.org/jira/browse/HBASE-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davey Yan updated HBASE-7138:
-
Status: Patch Available (was: Open)
RegionSplitter's rollingSplit terminated with / by zero, and the
_balancedSplit file was not deleted properly
---
Key: HBASE-7138
URL: https://issues.apache.org/jira/browse/HBASE-7138
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.94.1
Environment: Ubuntu Server 10.04, Hadoop 1.0.3
Reporter: Davey Yan
Priority: Minor
Attachments: RegionSplitter_HBASE-7138-0.94.patch,
RegionSplitter_HBASE-7138.patch
The 'splitCount' in this line is zero in some scenario, then throw
ArithmeticException: / by zero, and the '_balancedSplit' file was not deleted:
{code:java}
LOG.debug(Avg Time / Split =
+ org.apache.hadoop.util.StringUtils.formatTime(tDiff /
splitCount));
{code}
Steps to reproduce:
{code}
shell create 'test2', 'i'
shell for i in 'a'..'z' do for j in 'a'..'z' do put 'test2', #{i}#{j},
i:#{j}, #{j} end end
{code}
{noformat}
$ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 test2
HexStringSplit
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:zookeeper.version=3.4.3-1240972, built on 02/06/2012 10:48 GMT
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:host.name=dev-vm0
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.version=1.6.0_29
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.vendor=Sun Microsystems Inc.
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.home=/usr/lib/jvm/jdk1.6.0_29/jre
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.class.path=/opt/hbase/bin/../conf:/usr/lib/jvm/default-java/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../hbase-0.94.1.jar:/opt/hbase/bin/../hbase-0.94.1-tests.jar:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/avro-1.5.3.jar:/opt/hbase/bin/../lib/avro-ipc-1.5.3.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.4.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.1.jar:/opt/hbase/bin/../lib/commons-lang-2.5.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.1.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/guava-11.0.2.jar:/opt/hbase/bin/../lib/hadoop-core-1.0.3.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/httpclient-4.1.2.jar:/opt/hbase/bin/../lib/httpcore-4.1.3.jar:/opt/hbase/bin/../lib/jackson-core-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-jaxrs-1.8.8.jar:/opt/hbase/bin/../lib/jackson-mapper-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-xc-1.8.8.jar:/opt/hbase/bin/../lib/jamon-runtime-2.3.1.jar:/opt/hbase/bin/../lib/jasper-compiler-5.5.23.jar:/opt/hbase/bin/../lib/jasper-runtime-5.5.23.jar:/opt/hbase/bin/../lib/jaxb-api-2.1.jar:/opt/hbase/bin/../lib/jaxb-impl-2.2.3-1.jar:/opt/hbase/bin/../lib/jersey-core-1.8.jar:/opt/hbase/bin/../lib/jersey-json-1.8.jar:/opt/hbase/bin/../lib/jersey-server-1.8.jar:/opt/hbase/bin/../lib/jettison-1.1.jar:/opt/hbase/bin/../lib/jetty-6.1.26.jar:/opt/hbase/bin/../lib/jetty-util-6.1.26.jar:/opt/hbase/bin/../lib/jruby-complete-1.6.5.jar:/opt/hbase/bin/../lib/jsp-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsp-api-2.1-6.1.14.jar:/opt/hbase/bin/../lib/jsr305-1.3.9.jar:/opt/hbase/bin/../lib/junit-4.10-HBASE-1.jar:/opt/hbase/bin/../lib/libthrift-0.8.0.jar:/opt/hbase/bin/../lib/log4j-1.2.16.jar:/opt/hbase/bin/../lib/metrics-core-2.1.2.jar:/opt/hbase/bin/../lib/netty-3.2.4.Final.jar:/opt/hbase/bin/../lib/protobuf-java-2.4.0a.jar:/opt/hbase/bin/../lib/servlet-api-2.5-6.1.14.jar:/opt/hbase/bin/../lib/slf4j-api-1.4.3.jar:/opt/hbase/bin/../lib/slf4j-log4j12-1.4.3.jar:/opt/hbase/bin/../lib/snappy-java-1.0.3.2.jar:/opt/hbase/bin/../lib/stax-api-1.0.1.jar:/opt/hbase/bin/../lib/velocity-1.7.jar:/opt/hbase/bin/../lib/xmlenc-0.52.jar:/opt/hbase/bin/../lib/zookeeper-3.4.3.jar:/opt/hbase/bin/../libextra/mybk-commons-cc.jar:/opt/hbase/bin/../libextra/hbase.jar:/opt/hbase/bin/../libextra/sfdcloud-hbase.jar:
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.library.path=/opt/hbase/bin/../lib/native/Linux-i386-32
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
[jira] [Commented] (HBASE-7138) RegionSplitter's rollingSplit terminated with / by zero, and the _balancedSplit file was not deleted properly
[
https://issues.apache.org/jira/browse/HBASE-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493939#comment-13493939
]
Hadoop QA commented on HBASE-7138:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552817/RegionSplitter_HBASE-7138-0.94.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3289//console
This message is automatically generated.
RegionSplitter's rollingSplit terminated with / by zero, and the
_balancedSplit file was not deleted properly
---
Key: HBASE-7138
URL: https://issues.apache.org/jira/browse/HBASE-7138
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.94.1
Environment: Ubuntu Server 10.04, Hadoop 1.0.3
Reporter: Davey Yan
Priority: Minor
Attachments: RegionSplitter_HBASE-7138-0.94.patch,
RegionSplitter_HBASE-7138.patch
The 'splitCount' in this line is zero in some scenario, then throw
ArithmeticException: / by zero, and the '_balancedSplit' file was not deleted:
{code:java}
LOG.debug(Avg Time / Split =
+ org.apache.hadoop.util.StringUtils.formatTime(tDiff /
splitCount));
{code}
Steps to reproduce:
{code}
shell create 'test2', 'i'
shell for i in 'a'..'z' do for j in 'a'..'z' do put 'test2', #{i}#{j},
i:#{j}, #{j} end end
{code}
{noformat}
$ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 test2
HexStringSplit
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:zookeeper.version=3.4.3-1240972, built on 02/06/2012 10:48 GMT
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:host.name=dev-vm0
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.version=1.6.0_29
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.vendor=Sun Microsystems Inc.
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.home=/usr/lib/jvm/jdk1.6.0_29/jre
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
[jira] [Commented] (HBASE-7046) Fix resource leak in TestHLogSplit#testOldRecoveredEditsFileSidelined
[ https://issues.apache.org/jira/browse/HBASE-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493951#comment-13493951 ] Hudson commented on HBASE-7046: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #254 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/254/]) HBASE-7046 Fix resource leak in TestHLogSplit#testOldRecoveredEditsFileSidelined (Himanshu) (Revision 1407363) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java Fix resource leak in TestHLogSplit#testOldRecoveredEditsFileSidelined - Key: HBASE-7046 URL: https://issues.apache.org/jira/browse/HBASE-7046 Project: HBase Issue Type: Bug Components: wal Affects Versions: 0.96.0 Reporter: Himanshu Vashishtha Assignee: Himanshu Vashishtha Fix For: 0.96.0 Attachments: HBASE-7046.patch This method creates a writer but never closes one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6356) printStackTrace in FSUtils
[
https://issues.apache.org/jira/browse/HBASE-6356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gustavo Anatoly updated HBASE-6356:
---
Attachment: HBASE-6356.patch
Hi, Nicolas.
Thanks for reply. I've attached the patch for review.
printStackTrace in FSUtils
--
Key: HBASE-6356
URL: https://issues.apache.org/jira/browse/HBASE-6356
Project: HBase
Issue Type: Bug
Components: Client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal
Priority: Trivial
Labels: noob
Attachments: HBASE-6356.patch
This is bad...
{noformat}
public boolean accept(Path p) {
boolean isValid = false;
try {
if (HConstants.HBASE_NON_USER_TABLE_DIRS.contains(p.toString())) {
isValid = false;
} else {
isValid = this.fs.getFileStatus(p).isDir();
}
} catch (IOException e) {
e.printStackTrace();
}
return isValid;
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7138) RegionSplitter's rollingSplit terminated with / by zero, and the _balancedSplit file was not deleted properly
[
https://issues.apache.org/jira/browse/HBASE-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494021#comment-13494021
]
ramkrishna.s.vasudevan commented on HBASE-7138:
---
{code}
if (conf.getBoolean(split.verify, true)) {
{code}
If this property is set to false still the splitcount will be 0. So should we
addresss that also?
RegionSplitter's rollingSplit terminated with / by zero, and the
_balancedSplit file was not deleted properly
---
Key: HBASE-7138
URL: https://issues.apache.org/jira/browse/HBASE-7138
Project: HBase
Issue Type: Bug
Components: util
Affects Versions: 0.94.1
Environment: Ubuntu Server 10.04, Hadoop 1.0.3
Reporter: Davey Yan
Priority: Minor
Attachments: RegionSplitter_HBASE-7138-0.94.patch,
RegionSplitter_HBASE-7138.patch
The 'splitCount' in this line is zero in some scenario, then throw
ArithmeticException: / by zero, and the '_balancedSplit' file was not deleted:
{code:java}
LOG.debug(Avg Time / Split =
+ org.apache.hadoop.util.StringUtils.formatTime(tDiff /
splitCount));
{code}
Steps to reproduce:
{code}
shell create 'test2', 'i'
shell for i in 'a'..'z' do for j in 'a'..'z' do put 'test2', #{i}#{j},
i:#{j}, #{j} end end
{code}
{noformat}
$ bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 test2
HexStringSplit
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:zookeeper.version=3.4.3-1240972, built on 02/06/2012 10:48 GMT
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:host.name=dev-vm0
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.version=1.6.0_29
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.vendor=Sun Microsystems Inc.
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
environment:java.home=/usr/lib/jvm/jdk1.6.0_29/jre
12/11/08 19:20:40 INFO zookeeper.ZooKeeper: Client
[jira] [Commented] (HBASE-7103) Need to fail split if SPLIT znode is deleted even before the split is completed.
[ https://issues.apache.org/jira/browse/HBASE-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494025#comment-13494025 ] ramkrishna.s.vasudevan commented on HBASE-7103: --- @Lars HBASE-6088 added the new journal entry. Because previously the STARTED_SPLITTING was never added. So what happened was once we try to write the data RS_ZK_SPLITTING after creating the node and if that fails then on rollback we don take action and so subsequent splitting never happened. bq.can't we keep dictionary keyed by region of currently splitting regions in the RS? But the clearing of the dictionary should be done properly after the transition is done. Chances of race between the time we remove and the time we check if already present. May be we need to cross verify with the online regions list in the RS side. Need to fail split if SPLIT znode is deleted even before the split is completed. Key: HBASE-7103 URL: https://issues.apache.org/jira/browse/HBASE-7103 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.3, 0.96.0 Attachments: HBASE-7103_testcase.patch This came up after the following mail in dev list 'infinite loop of RS_ZK_REGION_SPLIT on .94.2'. The following is the reason for the problem The following steps happen - Initially the parent region P1 starts splitting. - The split is going on normally. - Another split starts at the same time for the same region P1. (Not sure why this started). - Rollback happens seeing an already existing node. - This node gets deleted in rollback and nodeDeleted Event starts. - In nodeDeleted event the RIT for the region P1 gets deleted. - Because of this there is no region in RIT. - Now the first split gets over. Here the problem is we try to transit the node to SPLITTING to SPLIT. But the node even does not exist. But we don take any action on this. We think it is successful. - Because of this SplitRegionHandler never gets invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7137) Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays
[ https://issues.apache.org/jira/browse/HBASE-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494026#comment-13494026 ] Ted Yu commented on HBASE-7137: --- Patch makes sense. Improve Bytes to accept byte buffers which don't allow us to directly access thier backed arrays Key: HBASE-7137 URL: https://issues.apache.org/jira/browse/HBASE-7137 Project: HBase Issue Type: Improvement Reporter: Hiroshi Ikeda Priority: Minor Attachments: HBASE-7137.patch Inside HBase, it seems that there is the implicit assumption that byte buffers have backed arrays and are not read-only, and we can freely call ByteBuffer.array() and arrayOffset() without runtime exceptions. But some classes, including Bytes, are supposed to be used by users from outside of HBase, and we should think the possibility that methods receive byte buffers which don't hold the assumption. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494130#comment-13494130 ] ramkrishna.s.vasudevan commented on HBASE-7131: --- Present in 0.94 also i think. Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: Region Assignment Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Attachments: HBase-7131-v1.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7130) NULL qualifier is ignored
[ https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494142#comment-13494142 ] Jimmy Xiang commented on HBASE-7130: The test is ok locally. Let me take a look. It may be a jdk1.7 thing. NULL qualifier is ignored - Key: HBASE-7130 URL: https://issues.apache.org/jira/browse/HBASE-7130 Project: HBase Issue Type: Bug Components: Client, Protobufs Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: trunk-7130.patch, trunk-7130_v2.patch HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But the request converter skips empty qualifier list too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7130) NULL qualifier is ignored
[ https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-7130: --- Status: Open (was: Patch Available) NULL qualifier is ignored - Key: HBASE-7130 URL: https://issues.apache.org/jira/browse/HBASE-7130 Project: HBase Issue Type: Bug Components: Client, Protobufs Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: trunk-7130.patch, trunk-7130_v2.patch HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But the request converter skips empty qualifier list too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7066) Some HMaster coprocessor exceptions are being swallowed in try catch blocks
[ https://issues.apache.org/jira/browse/HBASE-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494158#comment-13494158 ] Ted Yu commented on HBASE-7066: --- Comment on addendum would be appreciated. Some HMaster coprocessor exceptions are being swallowed in try catch blocks --- Key: HBASE-7066 URL: https://issues.apache.org/jira/browse/HBASE-7066 Project: HBase Issue Type: Bug Components: Coprocessors, security Affects Versions: 0.94.2, 0.96.0 Reporter: Francis Liu Assignee: Francis Liu Priority: Critical Attachments: 7066-addendum.txt, 7066-addendum-v2.txt, HBASE-7066_94.patch, HBASE-7066_trunk.patch, HBASE-7066_trunk.patch This is causing HMaster.shutdown() and HMaster.stopMaster() to succeed even when an AccessDeniedException is thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7130) NULL qualifier is ignored
[ https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-7130: --- Attachment: trunk-7130_v3.patch NULL qualifier is ignored - Key: HBASE-7130 URL: https://issues.apache.org/jira/browse/HBASE-7130 Project: HBase Issue Type: Bug Components: Client, Protobufs Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: trunk-7130.patch, trunk-7130_v2.patch, trunk-7130_v3.patch HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But the request converter skips empty qualifier list too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7130) NULL qualifier is ignored
[ https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-7130: --- Status: Patch Available (was: Open) It is a test problem. I fixed it. The two new tests added to TestFromClientSide also work in an old 0.94 branch. NULL qualifier is ignored - Key: HBASE-7130 URL: https://issues.apache.org/jira/browse/HBASE-7130 Project: HBase Issue Type: Bug Components: Client, Protobufs Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: trunk-7130.patch, trunk-7130_v2.patch, trunk-7130_v3.patch HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But the request converter skips empty qualifier list too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7130) NULL qualifier is ignored
[ https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494184#comment-13494184 ] Ted Yu commented on HBASE-7130: --- +1 on patch v3. NULL qualifier is ignored - Key: HBASE-7130 URL: https://issues.apache.org/jira/browse/HBASE-7130 Project: HBase Issue Type: Bug Components: Client, Protobufs Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: trunk-7130.patch, trunk-7130_v2.patch, trunk-7130_v3.patch HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But the request converter skips empty qualifier list too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7130) NULL qualifier is ignored
[
https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494220#comment-13494220
]
Hadoop QA commented on HBASE-7130:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552865/trunk-7130_v3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 12 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.master.TestRollingRestart
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3290//console
This message is automatically generated.
NULL qualifier is ignored
-
Key: HBASE-7130
URL: https://issues.apache.org/jira/browse/HBASE-7130
Project: HBase
Issue Type: Bug
Components: Client, Protobufs
Affects Versions: 0.96.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Fix For: 0.96.0
Attachments: trunk-7130.patch, trunk-7130_v2.patch,
trunk-7130_v3.patch
HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But
the request converter skips empty qualifier list too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6830) [WINDOWS] Tests should not rely on local temp dir to be available in DFS
[
https://issues.apache.org/jira/browse/HBASE-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-6830:
--
Status: Patch Available (was: Open)
[WINDOWS] Tests should not rely on local temp dir to be available in DFS
Key: HBASE-6830
URL: https://issues.apache.org/jira/browse/HBASE-6830
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: window
Attachments: hbase-6830_v1-0.94.patch, hbase-6830_v1-trunk.patch,
hbase-6830_v5-0.94.patch, hbase-6830_v5-trunk.patch
Some of the tests resolve the local temp directory for temporary test data,
but use this directory path in dfs. Since on windows, local temp dir is
resolved to something like: c:\\path_to_local_dir,
DistributedFileSystem.getPathName() throws an IllegalArgumentException
complaining that it is not a valid path name.
Instead of relying on a local temp dir name, we should create a temp dir on
dfs, and use this as a basis dir for test data.
At least the following test cases are affected by this:
{code}
TestHFileOutputFormat
TestHRegionServerBulkLoad
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7062) Move HLog stats to metrics 2
[ https://issues.apache.org/jira/browse/HBASE-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-7062: - Attachment: HBASE-7062-2.patch Headers. And @InterfaceAudience.Private for the stuff in hbase-server. Stuff in the hbase-hadoop-compat modules don't have InterfaceAudience since hbase-hadoop-compat can't depend on a certain hadoop. Move HLog stats to metrics 2 Key: HBASE-7062 URL: https://issues.apache.org/jira/browse/HBASE-7062 Project: HBase Issue Type: Sub-task Components: metrics Affects Versions: 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Priority: Critical Fix For: 0.96.0 Attachments: HBASE-7062-1.patch, HBASE-7062-2.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6830) [WINDOWS] Tests should not rely on local temp dir to be available in DFS
[
https://issues.apache.org/jira/browse/HBASE-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494280#comment-13494280
]
Hadoop QA commented on HBASE-6830:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12551439/hbase-6830_v5-trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 24 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3291//console
This message is automatically generated.
[WINDOWS] Tests should not rely on local temp dir to be available in DFS
Key: HBASE-6830
URL: https://issues.apache.org/jira/browse/HBASE-6830
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: window
Attachments: hbase-6830_v1-0.94.patch, hbase-6830_v1-trunk.patch,
hbase-6830_v5-0.94.patch, hbase-6830_v5-trunk.patch
Some of the tests resolve the local temp directory for temporary test data,
but use this directory path in dfs. Since on windows, local temp dir is
resolved to something like: c:\\path_to_local_dir,
DistributedFileSystem.getPathName() throws an IllegalArgumentException
complaining that it is not a valid path name.
Instead of relying on a local temp dir name, we should create a temp dir on
dfs, and use this as a basis dir for test data.
At least the following test cases are affected by this:
{code}
TestHFileOutputFormat
TestHRegionServerBulkLoad
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7062) Move HLog stats to metrics 2
[
https://issues.apache.org/jira/browse/HBASE-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494308#comment-13494308
]
Hadoop QA commented on HBASE-7062:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552881/HBASE-7062-2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3292//console
This message is automatically generated.
Move HLog stats to metrics 2
Key: HBASE-7062
URL: https://issues.apache.org/jira/browse/HBASE-7062
Project: HBase
Issue Type: Sub-task
Components: metrics
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Critical
Fix For: 0.96.0
Attachments: HBASE-7062-1.patch, HBASE-7062-2.patch
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7109) integration tests on cluster are not getting picked up from distribution
[ https://issues.apache.org/jira/browse/HBASE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-7109: Attachment: HBASE-7109-v3-squashed.patch renamed the methods integration tests on cluster are not getting picked up from distribution Key: HBASE-7109 URL: https://issues.apache.org/jira/browse/HBASE-7109 Project: HBase Issue Type: Sub-task Components: test Affects Versions: 0.96.0 Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Attachments: HBASE-7109-squashed.patch, HBASE-7109-v2-squashed.patch, HBASE-7109-v3-squashed.patch The method of finding test classes only works on local build (or its full copy), not if the distribution is used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7109) integration tests on cluster are not getting picked up from distribution
[
https://issues.apache.org/jira/browse/HBASE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494357#comment-13494357
]
Hadoop QA commented on HBASE-7109:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552891/HBASE-7109-v3-squashed.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 10 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.io.hfile.TestForceCacheImportantBlocks
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3293//console
This message is automatically generated.
integration tests on cluster are not getting picked up from distribution
Key: HBASE-7109
URL: https://issues.apache.org/jira/browse/HBASE-7109
Project: HBase
Issue Type: Sub-task
Components: test
Affects Versions: 0.96.0
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
Attachments: HBASE-7109-squashed.patch, HBASE-7109-v2-squashed.patch,
HBASE-7109-v3-squashed.patch
The method of finding test classes only works on local build (or its full
copy), not if the distribution is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7103) Need to fail split if SPLIT znode is deleted even before the split is completed.
[ https://issues.apache.org/jira/browse/HBASE-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494369#comment-13494369 ] Lars Hofhansl commented on HBASE-7103: -- I would like to entertain the thought of revert both HBASE-6854 and HBASE-6088 for 0.94. (possible scheduling them both to 0.94.4 along with this one and HBASE-7101 to fix these all together). I ran your test with these two patches reverted. It now fails in the last assert (where the RS and Master disagree whether the region is online or not). That is not ideal, but was a longstanding issue (I think). [~ram_krish] I realize this is frustrating. At the same time I think that for 0.94 we have start thinking about an expectation of stability. Thoughts about this? Need to fail split if SPLIT znode is deleted even before the split is completed. Key: HBASE-7103 URL: https://issues.apache.org/jira/browse/HBASE-7103 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.3, 0.96.0 Attachments: HBASE-7103_testcase.patch This came up after the following mail in dev list 'infinite loop of RS_ZK_REGION_SPLIT on .94.2'. The following is the reason for the problem The following steps happen - Initially the parent region P1 starts splitting. - The split is going on normally. - Another split starts at the same time for the same region P1. (Not sure why this started). - Rollback happens seeing an already existing node. - This node gets deleted in rollback and nodeDeleted Event starts. - In nodeDeleted event the RIT for the region P1 gets deleted. - Because of this there is no region in RIT. - Now the first split gets over. Here the problem is we try to transit the node to SPLITTING to SPLIT. But the node even does not exist. But we don take any action on this. We think it is successful. - Because of this SplitRegionHandler never gets invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7101) HBase stuck in Region SPLIT
[ https://issues.apache.org/jira/browse/HBASE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494370#comment-13494370 ] Lars Hofhansl commented on HBASE-7101: -- Any chance for a test for this, Bing? HBase stuck in Region SPLIT Key: HBASE-7101 URL: https://issues.apache.org/jira/browse/HBASE-7101 Project: HBase Issue Type: Bug Affects Versions: 0.92.1 Reporter: Bing Jiang Fix For: 0.94.3, 0.96.0 I found this issue from a zknode which has existed for a long time in the unassigned parent.And HMaster report warnning log increasingly.The loop log is at below. WARN org.apache.hadoop.hbase.master.AssignmentManager: Region 1a1c950ad45812d7b4b9b90ebf268468 not found on server sev0040,60020,1350378314041; failed processing WARN org.apache.hadoop.hbase.master.AssignmentManager: Received SPLIT for region 1a1c950ad45812d7b4b9b90ebf268468 from server sev0040,60020,1350378314041 but it doesn't exist anymore, probably already processed its split WARN org.apache.hadoop.hbase.master.AssignmentManager: Region 1a1c950ad45812d7b4b9b90ebf268468 not found on server gs-dpo-sev0040,60020,1350378314041; failed processing WARN org.apache.hadoop.hbase.master.AssignmentManager: Received SPLIT for region 1a1c950ad45812d7b4b9b90ebf268468 from server sev0040,60020,1350378314041 but it doesn't exist anymore, probably already processed its split we use Hbase-0.92.1, and I trace back to the source code. HMaster AssignmentManager have already deleted the SPLIT_Region in its memory structure,but HRegionServer SplitTransaction has found the unassigned/parent-node existed in a transient state, precisely SplitTransaction executes tickleNodeSplit to update a new version a little later than AssignmentManager deleting unassigned/parent-znode. After updating a version of the znode, it will intrigue the handleRegion operation again, however, AssignmentManager assert that the RegionState in Memory has been deleted, and transaction goes into a retry loop. In the SplitTransaction, transitionZKNode will retry tickleNodeSplit after sleeping 100ms. In my opinion, if the time is much longger than 100ms, all the operation from AssignmentManagement will finish off completely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5954) Allow proper fsync support for HBase
[ https://issues.apache.org/jira/browse/HBASE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494390#comment-13494390 ] Lars Hofhansl commented on HBASE-5954: -- I'm planning to pick this up again, soon. Allow proper fsync support for HBase Key: HBASE-5954 URL: https://issues.apache.org/jira/browse/HBASE-5954 Project: HBase Issue Type: Improvement Reporter: Lars Hofhansl Assignee: Lars Hofhansl Attachments: 5954-trunk-hdfs-trunk.txt, 5954-trunk-hdfs-trunk-v2.txt, 5954-trunk-hdfs-trunk-v3.txt, 5954-trunk-hdfs-trunk-v4.txt, 5954-trunk-hdfs-trunk-v5.txt, 5954-trunk-hdfs-trunk-v6.txt, hbase-hdfs-744.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7140) mvn eclipse:eclipse command is failing
Sujee Maniyam created HBASE-7140: Summary: mvn eclipse:eclipse command is failing Key: HBASE-7140 URL: https://issues.apache.org/jira/browse/HBASE-7140 Project: HBase Issue Type: Bug Reporter: Sujee Maniyam Priority: Minor seems like building hadoop-one-snapshot is failing. See error log [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] HBase [INFO] HBase - Common [INFO] HBase - Hadoop Compatibility [INFO] HBase - Hadoop One Compatibility [INFO] HBase - Server [INFO] HBase - Hadoop Two Compatibility [INFO] HBase - Integration Tests [INFO] HBase - Examples [INFO] [INFO] [INFO] Building HBase 0.95-SNAPSHOT [INFO] [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase [INFO] [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ hbase --- [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase [INFO] [INFO] --- maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase --- [INFO] Not running eclipse plugin goal for pom project [INFO] Using Eclipse Workspace: null [INFO] Adding default classpath container: org.eclipse.jdt.launching.JRE_CONTAINER [INFO] [INFO] [INFO] Building HBase - Common 0.95-SNAPSHOT [INFO] [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase-common [INFO] [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ hbase-common --- [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase-common [INFO] [INFO] --- maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase-common --- [INFO] Using Eclipse Workspace: null [INFO] Adding default classpath container: org.eclipse.jdt.launching.JRE_CONTAINER [INFO] File /Users/sujee/dev/hadoop/hbase-src/hbase-common/.project already exists. Additional settings will be preserved, run mvn eclipse:clean if you want old settings to be removed. [INFO] Wrote Eclipse project for hbase-common to /Users/sujee/dev/hadoop/hbase-src/hbase-common. [INFO] Sources for some artifacts are not available. Please run the same goal with the -DdownloadSources=true parameter in order to check remote repositories for sources. List of artifacts without a source archive: o com.google.guava:guava:12.0.1 o junit:junit:4.10-HBASE-1 o org.apache.hadoop:hadoop-core:1.1.0 o commons-io:commons-io:2.4 o commons-httpclient:commons-httpclient:3.0.1 o commons-codec:commons-codec:1.7 o commons-lang:commons-lang:2.6 o commons-net:commons-net:1.4.1 o org.mortbay.jetty:jsp-api-2.1:6.1.14 o org.mortbay.jetty:servlet-api-2.5:6.1.14 o org.mortbay.jetty:jsp-2.1:6.1.14 o org.apache.hadoop:hadoop-test:1.1.0 o org.apache.ftpserver:ftplet-api:1.0.0 o org.apache.mina:mina-core:2.0.0-M5 o org.slf4j:slf4j-api:1.4.3 o org.apache.ftpserver:ftpserver-core:1.0.0 o org.apache.ftpserver:ftpserver-deprecated:1.0.0-M2 o org.mockito:mockito-all:1.9.0 o org.slf4j:slf4j-log4j12:1.4.3 Javadoc for some artifacts is not available. Please run the same goal with the -DdownloadJavadocs=true parameter in order to check remote repositories for javadoc. List of artifacts without a javadoc archive: o com.google.guava:guava:12.0.1 o com.google.code.findbugs:jsr305:1.3.9 o commons-logging:commons-logging:1.1.1 o junit:junit:4.10-HBASE-1 o org.apache.hadoop:hadoop-core:1.1.0 o commons-cli:commons-cli:1.2 o xmlenc:xmlenc:0.52 o commons-io:commons-io:2.4 o commons-httpclient:commons-httpclient:3.0.1 o commons-codec:commons-codec:1.7 o org.apache.commons:commons-math:2.1 o commons-configuration:commons-configuration:1.6 o commons-collections:commons-collections:3.2.1 o commons-lang:commons-lang:2.6 o commons-digester:commons-digester:1.8 o commons-beanutils:commons-beanutils:1.7.0 o
[jira] [Updated] (HBASE-7062) Move HLog stats to metrics 2
[ https://issues.apache.org/jira/browse/HBASE-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-7062: - Attachment: HBASE-7062-3.patch Move HLog stats to metrics 2 Key: HBASE-7062 URL: https://issues.apache.org/jira/browse/HBASE-7062 Project: HBase Issue Type: Sub-task Components: metrics Affects Versions: 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Priority: Critical Fix For: 0.96.0 Attachments: HBASE-7062-1.patch, HBASE-7062-2.patch, HBASE-7062-3.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7140) mvn eclipse:eclipse command is failing
[ https://issues.apache.org/jira/browse/HBASE-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494397#comment-13494397 ] Jimmy Xiang commented on HBASE-7140: Can you go to the hbase-server folder to run mvn eclipse:eclipse? mvn eclipse:eclipse command is failing -- Key: HBASE-7140 URL: https://issues.apache.org/jira/browse/HBASE-7140 Project: HBase Issue Type: Bug Reporter: Sujee Maniyam Priority: Minor seems like building hadoop-one-snapshot is failing. See error log [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] HBase [INFO] HBase - Common [INFO] HBase - Hadoop Compatibility [INFO] HBase - Hadoop One Compatibility [INFO] HBase - Server [INFO] HBase - Hadoop Two Compatibility [INFO] HBase - Integration Tests [INFO] HBase - Examples [INFO] [INFO] [INFO] Building HBase 0.95-SNAPSHOT [INFO] [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase [INFO] [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ hbase --- [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase [INFO] [INFO] --- maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase --- [INFO] Not running eclipse plugin goal for pom project [INFO] Using Eclipse Workspace: null [INFO] Adding default classpath container: org.eclipse.jdt.launching.JRE_CONTAINER [INFO] [INFO] [INFO] Building HBase - Common 0.95-SNAPSHOT [INFO] [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase-common [INFO] [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ hbase-common --- [INFO] [INFO] maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase-common [INFO] [INFO] --- maven-eclipse-plugin:2.8:eclipse (default-cli) @ hbase-common --- [INFO] Using Eclipse Workspace: null [INFO] Adding default classpath container: org.eclipse.jdt.launching.JRE_CONTAINER [INFO] File /Users/sujee/dev/hadoop/hbase-src/hbase-common/.project already exists. Additional settings will be preserved, run mvn eclipse:clean if you want old settings to be removed. [INFO] Wrote Eclipse project for hbase-common to /Users/sujee/dev/hadoop/hbase-src/hbase-common. [INFO] Sources for some artifacts are not available. Please run the same goal with the -DdownloadSources=true parameter in order to check remote repositories for sources. List of artifacts without a source archive: o com.google.guava:guava:12.0.1 o junit:junit:4.10-HBASE-1 o org.apache.hadoop:hadoop-core:1.1.0 o commons-io:commons-io:2.4 o commons-httpclient:commons-httpclient:3.0.1 o commons-codec:commons-codec:1.7 o commons-lang:commons-lang:2.6 o commons-net:commons-net:1.4.1 o org.mortbay.jetty:jsp-api-2.1:6.1.14 o org.mortbay.jetty:servlet-api-2.5:6.1.14 o org.mortbay.jetty:jsp-2.1:6.1.14 o org.apache.hadoop:hadoop-test:1.1.0 o org.apache.ftpserver:ftplet-api:1.0.0 o org.apache.mina:mina-core:2.0.0-M5 o org.slf4j:slf4j-api:1.4.3 o org.apache.ftpserver:ftpserver-core:1.0.0 o org.apache.ftpserver:ftpserver-deprecated:1.0.0-M2 o org.mockito:mockito-all:1.9.0 o org.slf4j:slf4j-log4j12:1.4.3 Javadoc for some artifacts is not available. Please run the same goal with the -DdownloadJavadocs=true parameter in order to check remote repositories for javadoc. List of artifacts without a javadoc archive: o com.google.guava:guava:12.0.1 o com.google.code.findbugs:jsr305:1.3.9 o commons-logging:commons-logging:1.1.1 o junit:junit:4.10-HBASE-1 o org.apache.hadoop:hadoop-core:1.1.0 o commons-cli:commons-cli:1.2 o xmlenc:xmlenc:0.52 o commons-io:commons-io:2.4 o commons-httpclient:commons-httpclient:3.0.1
[jira] [Updated] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-7131: --- Component/s: (was: Region Assignment) test Priority: Minor (was: Major) Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494406#comment-13494406 ] Jimmy Xiang commented on HBASE-7131: Thanks for reporting this issue. It is a test problem. I will fix the test case you uploaded. Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7109) integration tests on cluster are not getting picked up from distribution
[
https://issues.apache.org/jira/browse/HBASE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494417#comment-13494417
]
Ted Yu commented on HBASE-7109:
---
{code}
+ private ListClass? findClassesFromJar(String jarFileName, String
packageName, boolean proceedOnExceptions)
{code}
The above line is too long ( 100 chars).
{code}
+String className = packageName + '.' + fileName.substring(0,
fileName.length() - .class.length());
{code}
The above line is long. Consider introducing a constant for .class.length()
which appears in two places.
ClassFinder is in src/test. People would think that it is used to find test
classes.
{code}
+public class ClassTestFinder extends ClassFinder {
{code}
ClassTestFinder is the class that gets instantiated in the patch. Is it
possible to unify the two classes ?
integration tests on cluster are not getting picked up from distribution
Key: HBASE-7109
URL: https://issues.apache.org/jira/browse/HBASE-7109
Project: HBase
Issue Type: Sub-task
Components: test
Affects Versions: 0.96.0
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
Attachments: HBASE-7109-squashed.patch, HBASE-7109-v2-squashed.patch,
HBASE-7109-v3-squashed.patch
The method of finding test classes only works on local build (or its full
copy), not if the distribution is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494425#comment-13494425 ] Aleksandr Shulman commented on HBASE-7131: -- Can you elaborate? Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7062) Move HLog stats to metrics 2
[
https://issues.apache.org/jira/browse/HBASE-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494431#comment-13494431
]
Ted Yu commented on HBASE-7062:
---
Patch v3 looks nice.
nit: it would be nice if sentences all end with period:
{code}
+ static final String APPEND_SIZE_DESC = Size of the data appended to the
HLog;
+ static final String SLOW_APPEND_COUNT = slowAppendCount;
+ static final String SLOW_APPEND_COUNT_DESC = Number of appends that were
slow.;
{code}
{code}
+ * Add the time it took to append to a histogram.
+ */
+ void incrementAppendTime(long time);
{code}
'histogram' should be 'HLog'
{code}
+ * Add the time it took to sync the hlog to a histogram.
+ */
+ void incrementSyncTime(long time);
{code}
'sync the hlog to a histogram' - 'sync the hlog to hdfs'
{code}
- HLogMetrics.syncTime.inc(System.currentTimeMillis() - now);
+ this.metrics.finishSync(System.currentTimeMillis() - now);
{code}
nit: use EnvironmentEdge above.
{code}
+@InterfaceAudience.Private
+public class MetricsHLog {
{code}
Add class javadoc for MetricsHLog.
Move HLog stats to metrics 2
Key: HBASE-7062
URL: https://issues.apache.org/jira/browse/HBASE-7062
Project: HBase
Issue Type: Sub-task
Components: metrics
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Critical
Fix For: 0.96.0
Attachments: HBASE-7062-1.patch, HBASE-7062-2.patch,
HBASE-7062-3.patch
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7103) Need to fail split if SPLIT znode is deleted even before the split is completed.
[ https://issues.apache.org/jira/browse/HBASE-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494432#comment-13494432 ] Lars Hofhansl commented on HBASE-7103: -- In fact just reverting HBASE-6088 seems to be fine. That is what I am proposing now. Need to fail split if SPLIT znode is deleted even before the split is completed. Key: HBASE-7103 URL: https://issues.apache.org/jira/browse/HBASE-7103 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.3, 0.96.0 Attachments: HBASE-7103_testcase.patch This came up after the following mail in dev list 'infinite loop of RS_ZK_REGION_SPLIT on .94.2'. The following is the reason for the problem The following steps happen - Initially the parent region P1 starts splitting. - The split is going on normally. - Another split starts at the same time for the same region P1. (Not sure why this started). - Rollback happens seeing an already existing node. - This node gets deleted in rollback and nodeDeleted Event starts. - In nodeDeleted event the RIT for the region P1 gets deleted. - Because of this there is no region in RIT. - Now the first split gets over. Here the problem is we try to transit the node to SPLITTING to SPLIT. But the node even does not exist. But we don take any action on this. We think it is successful. - Because of this SplitRegionHandler never gets invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-7131: --- Attachment: trunk-7131.patch Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch, trunk-7131.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494433#comment-13494433 ] Jimmy Xiang commented on HBASE-7131: After the table is re-enabled, the region could be assigned to a different region server. However, the HBase client caches the old connection, that's why the NotServingRegion exception. Once you add a line to clear the region cache, then it should work as expected: original.getConnection().clearRegionCache(); I was thinking how should the HBase client to deal with such scenario better. Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch, trunk-7131.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-7131: --- Status: Patch Available (was: Open) Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch, trunk-7131.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7130) NULL qualifier is ignored
[ https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-7130: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Integrated into trunk. Thanks Ted for the review. NULL qualifier is ignored - Key: HBASE-7130 URL: https://issues.apache.org/jira/browse/HBASE-7130 Project: HBase Issue Type: Bug Components: Client, Protobufs Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: trunk-7130.patch, trunk-7130_v2.patch, trunk-7130_v3.patch HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But the request converter skips empty qualifier list too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6830) [WINDOWS] Tests should not rely on local temp dir to be available in DFS
[
https://issues.apache.org/jira/browse/HBASE-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494438#comment-13494438
]
Ted Yu commented on HBASE-6830:
---
Patch looks good.
nit: no need to change style of comment
{code}
- // Directory where we put the data for this instance of HBaseTestingUtility.
+ /** Directory where we put the data for this instance of
HBaseTestingUtility*/
{code}
[WINDOWS] Tests should not rely on local temp dir to be available in DFS
Key: HBASE-6830
URL: https://issues.apache.org/jira/browse/HBASE-6830
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: window
Attachments: hbase-6830_v1-0.94.patch, hbase-6830_v1-trunk.patch,
hbase-6830_v5-0.94.patch, hbase-6830_v5-trunk.patch
Some of the tests resolve the local temp directory for temporary test data,
but use this directory path in dfs. Since on windows, local temp dir is
resolved to something like: c:\\path_to_local_dir,
DistributedFileSystem.getPathName() throws an IllegalArgumentException
complaining that it is not a valid path name.
Instead of relying on a local temp dir name, we should create a temp dir on
dfs, and use this as a basis dir for test data.
At least the following test cases are affected by this:
{code}
TestHFileOutputFormat
TestHRegionServerBulkLoad
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494439#comment-13494439 ] Lars Hofhansl commented on HBASE-4583: -- @Varun: I mostly agree. Increment/Append won't play nicely with concurrent Puts/Deletes anyway, whereas checkAndXXX does. [~saint@gmail.com] These tests finish pretty quickly on my laptop (about 2m), and 15s on my (beefy) desktop. Should be OK. OK... Going to commit later today. TestHFileOutputFormat is unrelated - I'll double check. This is nice correctness improvement to HBase. Integrate RWCC with Append and Increment operations --- Key: HBASE-4583 URL: https://issues.apache.org/jira/browse/HBASE-4583 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0 Attachments: 4583-mixed.txt, 4583-mixed-v2.txt, 4583-mixed-v4.txt, 4583-trunk-less-radical.txt, 4583-trunk-less-radical-v2.txt, 4583-trunk-less-radical-v3.txt, 4583-trunk-less-radical-v4.txt, 4583-trunk-less-radical-v5.txt, 4583-trunk-less-radical-v6.txt, 4583-trunk-radical.txt, 4583-trunk-radical_v2.txt, 4583-trunk-v3.txt, 4583.txt, 4583-v2.txt, 4583-v3.txt, 4583-v4.txt Currently Increment and Append operations do not work with RWCC and hence a client could see the results of multiple such operation mixed in the same Get/Scan. The semantics might be a bit more interesting here as upsert adds and removes to and from the memstore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (HBASE-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494439#comment-13494439 ] Lars Hofhansl edited comment on HBASE-4583 at 11/9/12 11:49 PM: @Varun: I mostly agree. Increment/Append won't play nicely with concurrent Puts/Deletes anyway (without this patch that is), whereas checkAndXXX does. [~saint@gmail.com] These tests finish pretty quickly on my laptop (about 2m), and 15s on my (beefy) desktop. Should be OK. OK... Going to commit later today. TestHFileOutputFormat is unrelated - I'll double check. This is nice correctness improvement to HBase. was (Author: lhofhansl): @Varun: I mostly agree. Increment/Append won't play nicely with concurrent Puts/Deletes anyway, whereas checkAndXXX does. [~saint@gmail.com] These tests finish pretty quickly on my laptop (about 2m), and 15s on my (beefy) desktop. Should be OK. OK... Going to commit later today. TestHFileOutputFormat is unrelated - I'll double check. This is nice correctness improvement to HBase. Integrate RWCC with Append and Increment operations --- Key: HBASE-4583 URL: https://issues.apache.org/jira/browse/HBASE-4583 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0 Attachments: 4583-mixed.txt, 4583-mixed-v2.txt, 4583-mixed-v4.txt, 4583-trunk-less-radical.txt, 4583-trunk-less-radical-v2.txt, 4583-trunk-less-radical-v3.txt, 4583-trunk-less-radical-v4.txt, 4583-trunk-less-radical-v5.txt, 4583-trunk-less-radical-v6.txt, 4583-trunk-radical.txt, 4583-trunk-radical_v2.txt, 4583-trunk-v3.txt, 4583.txt, 4583-v2.txt, 4583-v3.txt, 4583-v4.txt Currently Increment and Append operations do not work with RWCC and hence a client could see the results of multiple such operation mixed in the same Get/Scan. The semantics might be a bit more interesting here as upsert adds and removes to and from the memstore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7010) PrefixFilter should seek to first matching row
[ https://issues.apache.org/jira/browse/HBASE-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7010: - Resolution: Won't Fix Fix Version/s: (was: 0.94.4) (was: 0.96.0) Status: Resolved (was: Patch Available) It's not worth it. The Filter/FilterList stuff is too fragile to make this change. PrefixFilter must be used together with a proper startRow. PrefixFilter should seek to first matching row -- Key: HBASE-7010 URL: https://issues.apache.org/jira/browse/HBASE-7010 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Priority: Minor Attachments: 7010-experimental.txt, 7010.txt Currently a PrefixFilter will happily scan all KVs prefix. If should seek forward to the prefix if the current KV prefix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7141) Cleanup Increment and Append issues
Lars Hofhansl created HBASE-7141: Summary: Cleanup Increment and Append issues Key: HBASE-7141 URL: https://issues.apache.org/jira/browse/HBASE-7141 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Fix For: 0.96.0 * Append and Increment should take a TS for their update phase * Append should access a timerange for the read phase * Increment should no longer implement Writable (in trunk) This depends on HBASE-4583 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4676) Prefix Compression - Trie data block encoding
[ https://issues.apache.org/jira/browse/HBASE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Corgan updated HBASE-4676: --- Attachment: HBASE-4676-prefix-tree-trunk-v6.patch Prefix Compression - Trie data block encoding - Key: HBASE-4676 URL: https://issues.apache.org/jira/browse/HBASE-4676 Project: HBase Issue Type: New Feature Components: io, Performance, regionserver Affects Versions: 0.96.0 Reporter: Matt Corgan Assignee: Matt Corgan Attachments: HBASE-4676-0.94-v1.patch, HBASE-4676-prefix-tree-trunk-v1.patch, HBASE-4676-prefix-tree-trunk-v2.patch, HBASE-4676-prefix-tree-trunk-v3.patch, HBASE-4676-prefix-tree-trunk-v4.patch, HBASE-4676-prefix-tree-trunk-v5.patch, HBASE-4676-prefix-tree-trunk-v6.patch, hbase-prefix-trie-0.1.jar, PrefixTrie_Format_v1.pdf, PrefixTrie_Performance_v1.pdf, SeeksPerSec by blockSize.png The HBase data block format has room for 2 significant improvements for applications that have high block cache hit ratios. First, there is no prefix compression, and the current KeyValue format is somewhat metadata heavy, so there can be tremendous memory bloat for many common data layouts, specifically those with long keys and short values. Second, there is no random access to KeyValues inside data blocks. This means that every time you double the datablock size, average seek time (or average cpu consumption) goes up by a factor of 2. The standard 64KB block size is ~10x slower for random seeks than a 4KB block size, but block sizes as small as 4KB cause problems elsewhere. Using block sizes of 256KB or 1MB or more may be more efficient from a disk access and block-cache perspective in many big-data applications, but doing so is infeasible from a random seek perspective. The PrefixTrie block encoding format attempts to solve both of these problems. Some features: * trie format for row key encoding completely eliminates duplicate row keys and encodes similar row keys into a standard trie structure which also saves a lot of space * the column family is currently stored once at the beginning of each block. this could easily be modified to allow multiple family names per block * all qualifiers in the block are stored in their own trie format which caters nicely to wide rows. duplicate qualifers between rows are eliminated. the size of this trie determines the width of the block's qualifier fixed-width-int * the minimum timestamp is stored at the beginning of the block, and deltas are calculated from that. the maximum delta determines the width of the block's timestamp fixed-width-int The block is structured with metadata at the beginning, then a section for the row trie, then the column trie, then the timestamp deltas, and then then all the values. Most work is done in the row trie, where every leaf node (corresponding to a row) contains a list of offsets/references corresponding to the cells in that row. Each cell is fixed-width to enable binary searching and is represented by [1 byte operationType, X bytes qualifier offset, X bytes timestamp delta offset]. If all operation types are the same for a block, there will be zero per-cell overhead. Same for timestamps. Same for qualifiers when i get a chance. So, the compression aspect is very strong, but makes a few small sacrifices on VarInt size to enable faster binary searches in trie fan-out nodes. A more compressed but slower version might build on this by also applying further (suffix, etc) compression on the trie nodes at the cost of slower write speed. Even further compression could be obtained by using all VInts instead of FInts with a sacrifice on random seek speed (though not huge). One current drawback is the current write speed. While programmed with good constructs like TreeMaps, ByteBuffers, binary searches, etc, it's not programmed with the same level of optimization as the read path. Work will need to be done to optimize the data structures used for encoding and could probably show a 10x increase. It will still be slower than delta encoding, but with a much higher decode speed. I have not yet created a thorough benchmark for write speed nor sequential read speed. Though the trie is reaching a point where it is internally very efficient (probably within half or a quarter of its max read speed) the way that hbase currently uses it is far from optimal. The KeyValueScanner and related classes that iterate through the trie will eventually need to be smarter and have methods to do things like skipping to the next row of results without scanning every cell in between. When that is accomplished it will also allow much faster compactions because the full row key will not have to be
[jira] [Commented] (HBASE-4913) Per-CF compaction Via the Shell
[ https://issues.apache.org/jira/browse/HBASE-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494473#comment-13494473 ] Jimmy Xiang commented on HBASE-4913: The addendum looks good. Per-CF compaction Via the Shell --- Key: HBASE-4913 URL: https://issues.apache.org/jira/browse/HBASE-4913 Project: HBase Issue Type: Sub-task Components: Client, regionserver Reporter: Nicolas Spiegelberg Assignee: Mubarak Seyed Fix For: 0.96.0, 0.94.4 Attachments: HBASE-4913-94.patch, HBASE-4913-addendum.patch, HBASE-4913.trunk.v1.patch, HBASE-4913.trunk.v2.patch, HBASE-4913.trunk.v2.patch, HBASE-4913-trunk-v3.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7142) TestSplitLogManager#testDeadWorker may fail because of hard limit on the TimeoutMonitor's timeout period
Himanshu Vashishtha created HBASE-7142:
--
Summary: TestSplitLogManager#testDeadWorker may fail because of
hard limit on the TimeoutMonitor's timeout period
Key: HBASE-7142
URL: https://issues.apache.org/jira/browse/HBASE-7142
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.94.2
Reporter: Himanshu Vashishtha
Priority: Minor
Fix For: 0.94.3
The timeout in testDeadWorker is set to 1 sec, it is the same as the
TimeoutMonitor thread timeout. In some case, this may fail:
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.hadoop.hbase.master.TestSplitLogManager.waitForCounter(TestSplitLogManager.java:147)
at
org.apache.hadoop.hbase.master.TestSplitLogManager.waitForCounter(TestSplitLogManager.java:127)
at
org.apache.hadoop.hbase.master.TestSplitLogManager.testDeadWorker(TestSplitLogManager.java:433)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
{code}
Fix is to increase the timeout for this test. Its not needed in trunk as the
timeout is 3 seconds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7142) TestSplitLogManager#testDeadWorker may fail because of hard limit on the TimeoutMonitor's timeout period
[
https://issues.apache.org/jira/browse/HBASE-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Vashishtha updated HBASE-7142:
---
Attachment: HBASE-7142.patch
TestSplitLogManager passes.
TestSplitLogManager#testDeadWorker may fail because of hard limit on the
TimeoutMonitor's timeout period
Key: HBASE-7142
URL: https://issues.apache.org/jira/browse/HBASE-7142
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.94.2
Reporter: Himanshu Vashishtha
Priority: Minor
Fix For: 0.94.3
Attachments: HBASE-7142.patch
The timeout in testDeadWorker is set to 1 sec, it is the same as the
TimeoutMonitor thread timeout. In some case, this may fail:
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.hadoop.hbase.master.TestSplitLogManager.waitForCounter(TestSplitLogManager.java:147)
at
org.apache.hadoop.hbase.master.TestSplitLogManager.waitForCounter(TestSplitLogManager.java:127)
at
org.apache.hadoop.hbase.master.TestSplitLogManager.testDeadWorker(TestSplitLogManager.java:433)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
{code}
Fix is to increase the timeout for this test. Its not needed in trunk as the
timeout is 3 seconds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7109) integration tests on cluster are not getting picked up from distribution
[ https://issues.apache.org/jira/browse/HBASE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494477#comment-13494477 ] Sergey Shelukhin commented on HBASE-7109: - Split the lines, these and similar. As for classes - there's javadoc on ClassFinder, plus its API is such that it cannot be used without explicitly making decisions on how to filter classes (due to ctor), so there should be no confusion. ClassTestFinder only exists to contain the filters, initially ClassFinder was separate and filters separate (because they do separate things), but I encapsulated the filters into ClassTestFinder for convenience. integration tests on cluster are not getting picked up from distribution Key: HBASE-7109 URL: https://issues.apache.org/jira/browse/HBASE-7109 Project: HBase Issue Type: Sub-task Components: test Affects Versions: 0.96.0 Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Attachments: HBASE-7109-squashed.patch, HBASE-7109-v2-squashed.patch, HBASE-7109-v3-squashed.patch The method of finding test classes only works on local build (or its full copy), not if the distribution is used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7109) integration tests on cluster are not getting picked up from distribution
[ https://issues.apache.org/jira/browse/HBASE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-7109: Attachment: HBASE-7109-v4-squashed.patch integration tests on cluster are not getting picked up from distribution Key: HBASE-7109 URL: https://issues.apache.org/jira/browse/HBASE-7109 Project: HBase Issue Type: Sub-task Components: test Affects Versions: 0.96.0 Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Attachments: HBASE-7109-squashed.patch, HBASE-7109-v2-squashed.patch, HBASE-7109-v3-squashed.patch, HBASE-7109-v4-squashed.patch The method of finding test classes only works on local build (or its full copy), not if the distribution is used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23
Andrey Klochkov created HBASE-7143: -- Summary: TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23 Key: HBASE-7143 URL: https://issues.apache.org/jira/browse/HBASE-7143 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.2 Reporter: Andrey Klochkov Fix For: 0.94.3 TestMetaMigrationRemovingHTD fails when build is done with -Dhadoop.profile=23 option. The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it doesn't create parent directories by default anymore. The patch will be submitted shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23
[ https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Klochkov updated HBASE-7143: --- Attachment: HBASE-7143-0.94.patch TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23 - Key: HBASE-7143 URL: https://issues.apache.org/jira/browse/HBASE-7143 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.2 Reporter: Andrey Klochkov Fix For: 0.94.3 Attachments: HBASE-7143-0.94.patch TestMetaMigrationRemovingHTD fails when build is done with -Dhadoop.profile=23 option. The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it doesn't create parent directories by default anymore. The patch will be submitted shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23
[ https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Klochkov updated HBASE-7143: --- Attachment: HBASE-7143-trunk.patch TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23 - Key: HBASE-7143 URL: https://issues.apache.org/jira/browse/HBASE-7143 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.2 Reporter: Andrey Klochkov Fix For: 0.94.3 Attachments: HBASE-7143-0.94.patch, HBASE-7143-trunk.patch TestMetaMigrationRemovingHTD fails when build is done with -Dhadoop.profile=23 option. The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it doesn't create parent directories by default anymore. The patch will be submitted shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23
[ https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Klochkov updated HBASE-7143: --- Status: Patch Available (was: Open) attached patches for trunk and 0.94 TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23 - Key: HBASE-7143 URL: https://issues.apache.org/jira/browse/HBASE-7143 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.2 Reporter: Andrey Klochkov Fix For: 0.94.3 Attachments: HBASE-7143-0.94.patch, HBASE-7143-trunk.patch TestMetaMigrationRemovingHTD fails when build is done with -Dhadoop.profile=23 option. The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it doesn't create parent directories by default anymore. The patch will be submitted shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x
[ https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Klochkov updated HBASE-7143: --- Summary: TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x (was: TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x - Key: HBASE-7143 URL: https://issues.apache.org/jira/browse/HBASE-7143 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.2 Reporter: Andrey Klochkov Fix For: 0.94.3 Attachments: HBASE-7143-0.94.patch, HBASE-7143-trunk.patch TestMetaMigrationRemovingHTD fails when build is done with -Dhadoop.profile=23 option. The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it doesn't create parent directories by default anymore. The patch will be submitted shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494497#comment-13494497 ] Aleksandr Shulman commented on HBASE-7131: -- Good call. I tried your fix and it stopped the flakiness, with 40 consecutive successful runs. Perhaps we should clear the region cache automatically after a table is enabled or disabled? Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch, trunk-7131.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[
https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494506#comment-13494506
]
Hadoop QA commented on HBASE-7131:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552920/trunk-7131.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3295//console
This message is automatically generated.
Race condition after table is re-enabled: regions are incorrectly reported as
being available.
--
Key: HBASE-7131
URL: https://issues.apache.org/jira/browse/HBASE-7131
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.96.0
Reporter: Aleksandr Shulman
Assignee: Jimmy Xiang
Priority: Minor
Attachments: HBase-7131-v1.patch, trunk-7131.patch
For a table that is re-enabled shortly after it is disabled, regions that are
reported to be online are not. This is manifested by a flush attempt throwing
a NotServingRegion exception despite all regions from the original table
reporting that they are online.
I have a test in place that verifies this flaky behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6222) Add per-KeyValue Security
[ https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494519#comment-13494519 ] Himanshu Vashishtha commented on HBASE-6222: [~apurtell]Thanks for the writeup. Yes, your approach is different. Few thoughts: a) Its not clear how/where you are storing the acls at keyvalue level. You use _acl_ table, or something else? Reading through this gives an idea that the keyvalue level acls have null table, cf and cq attribute with them. Does this mean a user can have only one type of KV level acls in the application. Or in other words, how does the KV acl looks like in the _acl_ table? b) Currently, all the acl entries are stored in zk (limit of znode is 1 mb); will you be using the same approach? bq. It doesn't make sense to attach an ACL on a Delete, because the KVs covered by the delete will be ... deleted. I don't completely agree with this but will not comment also unless I completely understand your approach. [~yuzhih...@gmail.com] Thanks for taking time to read through it. bq. Versions will be kept for each unique visibility expression.Would this inflate memstore because we are keeping potentially many more versions of KeyValue which differ by visibility expression only ? Or HFile, right? If so, yes, as different visibility expressions provides different access control to user. If user A does two Put with Visibility A|B, C and then does a delete with visibility A|B, another user with acl of C should be able to see this. re: ENABLE_CELL_LEVEL_SECURITY I initially visualized a table level (will give some more thought about CF level... as mentioned in the doc also) Yes, change it after disabling the table as it will flush out the memstore. re: Multiple CVFilter No, only one should be good enough. How come you got this idea? I should fix the doc. re: Typo: Yes, he will get v2 and v4. Thanks for pointing this out. Add per-KeyValue Security - Key: HBASE-6222 URL: https://issues.apache.org/jira/browse/HBASE-6222 Project: HBase Issue Type: New Feature Components: security Reporter: stack Assignee: Andrew Purtell Attachments: HBaseCellRow-LevelSecurityDesignDoc.docx, HBaseCellRow-LevelSecurityPRD.docx Saw an interesting article: http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14 The Senate Armed Services Committee version of the fiscal 2013 national defense authorization act (S. 3254) would require DoD agencies to foreswear the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO certifies that there exists either no viable commercial open source database with security features comparable to [Accumulo] (such as the HBase or Cassandra databases)... Not sure what a 'commercial open source database' is, and I'm not sure whats going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security' like Accumulo's, we might put ourselves in the running for federal contributions? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x
[ https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494525#comment-13494525 ] Ted Yu commented on HBASE-7143: --- Thanks for the finding, Andrey. createDir() is recursive. Would be nice to write it in iterative manner. Would FileSystem.mkdirs() do the job ? TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x - Key: HBASE-7143 URL: https://issues.apache.org/jira/browse/HBASE-7143 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.2 Reporter: Andrey Klochkov Fix For: 0.94.3 Attachments: HBASE-7143-0.94.patch, HBASE-7143-trunk.patch TestMetaMigrationRemovingHTD fails when build is done with -Dhadoop.profile=23 option. The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it doesn't create parent directories by default anymore. The patch will be submitted shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7062) Move HLog stats to metrics 2
[
https://issues.apache.org/jira/browse/HBASE-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494536#comment-13494536
]
Hadoop QA commented on HBASE-7062:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552914/HBASE-7062-3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestAtomicOperation
org.apache.hadoop.hbase.TestDrainingServer
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3296//console
This message is automatically generated.
Move HLog stats to metrics 2
Key: HBASE-7062
URL: https://issues.apache.org/jira/browse/HBASE-7062
Project: HBase
Issue Type: Sub-task
Components: metrics
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Critical
Fix For: 0.96.0
Attachments: HBASE-7062-1.patch, HBASE-7062-2.patch,
HBASE-7062-3.patch
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7130) NULL qualifier is ignored
[ https://issues.apache.org/jira/browse/HBASE-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494539#comment-13494539 ] Hudson commented on HBASE-7130: --- Integrated in HBase-TRUNK #3525 (See [https://builds.apache.org/job/HBase-TRUNK/3525/]) HBASE-7130 NULL qualifier is ignored (Revision 1407695) Result = FAILURE jxiang : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/client/Get.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/client/Scan.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/AggregateImplementation.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestGet.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestScan.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestAggregateProtocol.java NULL qualifier is ignored - Key: HBASE-7130 URL: https://issues.apache.org/jira/browse/HBASE-7130 Project: HBase Issue Type: Bug Components: Client, Protobufs Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Attachments: trunk-7130.patch, trunk-7130_v2.patch, trunk-7130_v3.patch HBASE-6206 ignored NULL qualifier so the qualifier list could be empty. But the request converter skips empty qualifier list too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6830) [WINDOWS] Tests should not rely on local temp dir to be available in DFS
[
https://issues.apache.org/jira/browse/HBASE-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494541#comment-13494541
]
Enis Soztutar commented on HBASE-6830:
--
Thanks Ted for the review. I'm going to commit this unless anyone objects.
[WINDOWS] Tests should not rely on local temp dir to be available in DFS
Key: HBASE-6830
URL: https://issues.apache.org/jira/browse/HBASE-6830
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.3, 0.96.0
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: window
Attachments: hbase-6830_v1-0.94.patch, hbase-6830_v1-trunk.patch,
hbase-6830_v5-0.94.patch, hbase-6830_v5-trunk.patch
Some of the tests resolve the local temp directory for temporary test data,
but use this directory path in dfs. Since on windows, local temp dir is
resolved to something like: c:\\path_to_local_dir,
DistributedFileSystem.getPathName() throws an IllegalArgumentException
complaining that it is not a valid path name.
Instead of relying on a local temp dir name, we should create a temp dir on
dfs, and use this as a basis dir for test data.
At least the following test cases are affected by this:
{code}
TestHFileOutputFormat
TestHRegionServerBulkLoad
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x
[
https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494547#comment-13494547
]
Hadoop QA commented on HBASE-7143:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552944/HBASE-7143-trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 16 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3297//console
This message is automatically generated.
TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x
-
Key: HBASE-7143
URL: https://issues.apache.org/jira/browse/HBASE-7143
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.2
Reporter: Andrey Klochkov
Fix For: 0.94.3
Attachments: HBASE-7143-0.94.patch, HBASE-7143-trunk.patch
TestMetaMigrationRemovingHTD fails when build is done with
-Dhadoop.profile=23 option.
The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it
doesn't create parent directories by default anymore.
The patch will be submitted shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4583: - Release Note: This issue fixes MVCC issues with Increment and Append. To retain the current performance characteristics, VERSIONS should be set to 1 on column families with columns to be incremented/appended-to. If VERSIONS is 1 historical versions are kept for timerange queries, but Increment/Appends will be slower due to changes accumulating the memstore leading to frequent flushes. was: This issue fixes MVCC issues with Increment and Append. To retain the current performance characteristics, VERSIONS should be set to 1 on column families with columns to be incremented/appended-to. Integrate RWCC with Append and Increment operations --- Key: HBASE-4583 URL: https://issues.apache.org/jira/browse/HBASE-4583 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0 Attachments: 4583-mixed.txt, 4583-mixed-v2.txt, 4583-mixed-v4.txt, 4583-trunk-less-radical.txt, 4583-trunk-less-radical-v2.txt, 4583-trunk-less-radical-v3.txt, 4583-trunk-less-radical-v4.txt, 4583-trunk-less-radical-v5.txt, 4583-trunk-less-radical-v6.txt, 4583-trunk-radical.txt, 4583-trunk-radical_v2.txt, 4583-trunk-v3.txt, 4583.txt, 4583-v2.txt, 4583-v3.txt, 4583-v4.txt Currently Increment and Append operations do not work with RWCC and hence a client could see the results of multiple such operation mixed in the same Get/Scan. The semantics might be a bit more interesting here as upsert adds and removes to and from the memstore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-4583: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.96... Pfeeww. After one year. :) Thanks for the reviews folks. Integrate RWCC with Append and Increment operations --- Key: HBASE-4583 URL: https://issues.apache.org/jira/browse/HBASE-4583 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0 Attachments: 4583-mixed.txt, 4583-mixed-v2.txt, 4583-mixed-v4.txt, 4583-trunk-less-radical.txt, 4583-trunk-less-radical-v2.txt, 4583-trunk-less-radical-v3.txt, 4583-trunk-less-radical-v4.txt, 4583-trunk-less-radical-v5.txt, 4583-trunk-less-radical-v6.txt, 4583-trunk-radical.txt, 4583-trunk-radical_v2.txt, 4583-trunk-v3.txt, 4583.txt, 4583-v2.txt, 4583-v3.txt, 4583-v4.txt Currently Increment and Append operations do not work with RWCC and hence a client could see the results of multiple such operation mixed in the same Get/Scan. The semantics might be a bit more interesting here as upsert adds and removes to and from the memstore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x
[ https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-7143: -- Attachment: 7143-trunk-v2.txt I ran patch v2 using the following command and it passed: mvn test -Dhadoop.profile=2.0 -Dtest=TestMetaMigrationConvertingToPB TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x - Key: HBASE-7143 URL: https://issues.apache.org/jira/browse/HBASE-7143 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.94.2 Reporter: Andrey Klochkov Fix For: 0.94.3 Attachments: 7143-trunk-v2.txt, HBASE-7143-0.94.patch, HBASE-7143-trunk.patch TestMetaMigrationRemovingHTD fails when build is done with -Dhadoop.profile=23 option. The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it doesn't create parent directories by default anymore. The patch will be submitted shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7109) integration tests on cluster are not getting picked up from distribution
[
https://issues.apache.org/jira/browse/HBASE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494567#comment-13494567
]
Hadoop QA commented on HBASE-7109:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552934/HBASE-7109-v4-squashed.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 10 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 18 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3298//console
This message is automatically generated.
integration tests on cluster are not getting picked up from distribution
Key: HBASE-7109
URL: https://issues.apache.org/jira/browse/HBASE-7109
Project: HBase
Issue Type: Sub-task
Components: test
Affects Versions: 0.96.0
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
Attachments: HBASE-7109-squashed.patch, HBASE-7109-v2-squashed.patch,
HBASE-7109-v3-squashed.patch, HBASE-7109-v4-squashed.patch
The method of finding test classes only works on local build (or its full
copy), not if the distribution is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7103) Need to fail split if SPLIT znode is deleted even before the split is completed.
[ https://issues.apache.org/jira/browse/HBASE-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7103: - Attachment: 7103-6088-revert.txt Here's a patch against trunk, reverting HBASE-6088. Need to fail split if SPLIT znode is deleted even before the split is completed. Key: HBASE-7103 URL: https://issues.apache.org/jira/browse/HBASE-7103 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.3, 0.96.0 Attachments: 7103-6088-revert.txt, HBASE-7103_testcase.patch This came up after the following mail in dev list 'infinite loop of RS_ZK_REGION_SPLIT on .94.2'. The following is the reason for the problem The following steps happen - Initially the parent region P1 starts splitting. - The split is going on normally. - Another split starts at the same time for the same region P1. (Not sure why this started). - Rollback happens seeing an already existing node. - This node gets deleted in rollback and nodeDeleted Event starts. - In nodeDeleted event the RIT for the region P1 gets deleted. - Because of this there is no region in RIT. - Now the first split gets over. Here the problem is we try to transit the node to SPLITTING to SPLIT. But the node even does not exist. But we don take any action on this. We think it is successful. - Because of this SplitRegionHandler never gets invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7103) Need to fail split if SPLIT znode is deleted even before the split is completed.
[ https://issues.apache.org/jira/browse/HBASE-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7103: - Status: Patch Available (was: Open) Need to fail split if SPLIT znode is deleted even before the split is completed. Key: HBASE-7103 URL: https://issues.apache.org/jira/browse/HBASE-7103 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 0.94.3, 0.96.0 Attachments: 7103-6088-revert.txt, HBASE-7103_testcase.patch This came up after the following mail in dev list 'infinite loop of RS_ZK_REGION_SPLIT on .94.2'. The following is the reason for the problem The following steps happen - Initially the parent region P1 starts splitting. - The split is going on normally. - Another split starts at the same time for the same region P1. (Not sure why this started). - Rollback happens seeing an already existing node. - This node gets deleted in rollback and nodeDeleted Event starts. - In nodeDeleted event the RIT for the region P1 gets deleted. - Because of this there is no region in RIT. - Now the first split gets over. Here the problem is we try to transit the node to SPLITTING to SPLIT. But the node even does not exist. But we don take any action on this. We think it is successful. - Because of this SplitRegionHandler never gets invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494576#comment-13494576 ] Hudson commented on HBASE-4583: --- Integrated in HBase-TRUNK #3527 (See [https://builds.apache.org/job/HBase-TRUNK/3527/]) HBASE-4583 Integrate RWCC with Append and Increment operations (Revision 1407725) Result = FAILURE larsh : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestAtomicOperation.java Integrate RWCC with Append and Increment operations --- Key: HBASE-4583 URL: https://issues.apache.org/jira/browse/HBASE-4583 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Assignee: Lars Hofhansl Fix For: 0.96.0 Attachments: 4583-mixed.txt, 4583-mixed-v2.txt, 4583-mixed-v4.txt, 4583-trunk-less-radical.txt, 4583-trunk-less-radical-v2.txt, 4583-trunk-less-radical-v3.txt, 4583-trunk-less-radical-v4.txt, 4583-trunk-less-radical-v5.txt, 4583-trunk-less-radical-v6.txt, 4583-trunk-radical.txt, 4583-trunk-radical_v2.txt, 4583-trunk-v3.txt, 4583.txt, 4583-v2.txt, 4583-v3.txt, 4583-v4.txt Currently Increment and Append operations do not work with RWCC and hence a client could see the results of multiple such operation mixed in the same Get/Scan. The semantics might be a bit more interesting here as upsert adds and removes to and from the memstore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4676) Prefix Compression - Trie data block encoding
[
https://issues.apache.org/jira/browse/HBASE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494579#comment-13494579
]
Hadoop QA commented on HBASE-4676:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552931/HBASE-4676-prefix-tree-trunk-v6.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 142
new or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
103 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 60 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3299//console
This message is automatically generated.
Prefix Compression - Trie data block encoding
-
Key: HBASE-4676
URL: https://issues.apache.org/jira/browse/HBASE-4676
Project: HBase
Issue Type: New Feature
Components: io, Performance, regionserver
Affects Versions: 0.96.0
Reporter: Matt Corgan
Assignee: Matt Corgan
Attachments: HBASE-4676-0.94-v1.patch,
HBASE-4676-prefix-tree-trunk-v1.patch, HBASE-4676-prefix-tree-trunk-v2.patch,
HBASE-4676-prefix-tree-trunk-v3.patch, HBASE-4676-prefix-tree-trunk-v4.patch,
HBASE-4676-prefix-tree-trunk-v5.patch, HBASE-4676-prefix-tree-trunk-v6.patch,
hbase-prefix-trie-0.1.jar, PrefixTrie_Format_v1.pdf,
PrefixTrie_Performance_v1.pdf, SeeksPerSec by blockSize.png
The HBase data block format has room for 2 significant improvements for
applications that have high block cache hit ratios.
First, there is no prefix compression, and the current KeyValue format is
somewhat metadata heavy, so there can be tremendous memory bloat for many
common data layouts, specifically those with long keys and short values.
Second, there is no random access to KeyValues inside data blocks. This
means that every time you double the datablock size, average seek time (or
average cpu consumption) goes up by a factor of 2. The standard 64KB block
size is ~10x slower for random seeks than a 4KB block size, but block sizes
as small as 4KB cause problems elsewhere. Using block sizes of 256KB or 1MB
or more may be more efficient from a disk access and block-cache perspective
in many big-data applications, but doing so is infeasible from a random seek
perspective.
The PrefixTrie block encoding format attempts to solve both of these
problems. Some features:
* trie format for row key encoding completely eliminates duplicate row keys
and encodes similar row keys into a standard trie structure which also saves
a lot of space
* the column family is currently stored once at the beginning of each block.
this could easily be modified to allow multiple family names per block
* all qualifiers in the block are stored in their own trie format which
caters nicely to wide rows. duplicate qualifers between rows are eliminated.
the size of this trie determines the width of the block's qualifier
fixed-width-int
* the minimum timestamp is stored at the
[jira] [Commented] (HBASE-7143) TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x
[
https://issues.apache.org/jira/browse/HBASE-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494583#comment-13494583
]
Hadoop QA commented on HBASE-7143:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552962/7143-trunk-v2.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
87 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 18 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 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3300//console
This message is automatically generated.
TestMetaMigrationRemovingHTD fails when used with Hadoop 0.23/2.x
-
Key: HBASE-7143
URL: https://issues.apache.org/jira/browse/HBASE-7143
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.2
Reporter: Andrey Klochkov
Fix For: 0.94.3
Attachments: 7143-trunk-v2.txt, HBASE-7143-0.94.patch,
HBASE-7143-trunk.patch
TestMetaMigrationRemovingHTD fails when build is done with
-Dhadoop.profile=23 option.
The reason is the changes of defaults in -mkdir CLI call. In 0.23/2.x, it
doesn't create parent directories by default anymore.
The patch will be submitted shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7131) Race condition after table is re-enabled: regions are incorrectly reported as being available.
[ https://issues.apache.org/jira/browse/HBASE-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494584#comment-13494584 ] ramkrishna.s.vasudevan commented on HBASE-7131: --- Yes Jimmy. This is what i observed yesterday. It should be done automatically i suppose. Race condition after table is re-enabled: regions are incorrectly reported as being available. -- Key: HBASE-7131 URL: https://issues.apache.org/jira/browse/HBASE-7131 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.96.0 Reporter: Aleksandr Shulman Assignee: Jimmy Xiang Priority: Minor Attachments: HBase-7131-v1.patch, trunk-7131.patch For a table that is re-enabled shortly after it is disabled, regions that are reported to be online are not. This is manifested by a flush attempt throwing a NotServingRegion exception despite all regions from the original table reporting that they are online. I have a test in place that verifies this flaky behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6665) ROOT region should not be splitted even with META row as explicit split key
[ https://issues.apache.org/jira/browse/HBASE-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-6665: -- Resolution: Fixed Fix Version/s: 0.94.3 0.92.3 Status: Resolved (was: Patch Available) Committed to 0.94 and 0.92 also. Hence resolving it. ROOT region should not be splitted even with META row as explicit split key --- Key: HBASE-6665 URL: https://issues.apache.org/jira/browse/HBASE-6665 Project: HBase Issue Type: Bug Reporter: Y. SREENIVASULU REDDY Assignee: rajeshbabu Fix For: 0.92.3, 0.94.3, 0.96.0 Attachments: HBASE-6665_92.patch, HBASE-6665_94.patch, HBASE-6665_trunk.patch split operation on ROOT table by specifying explicit split key as .META. closing the ROOT region and taking long time to fail the split before rollback. I think we can skip split for ROOT table as how we are doing for META region. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
