[jira] [Commented] (HBASE-5416) Improve performance of scans with some kind of filters.
[ https://issues.apache.org/jira/browse/HBASE-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492173#comment-13492173 ] Max Lapan commented on HBASE-5416: -- If no one against inclusion, let's include it :). But I have a small improvement to do. Personally, I don't like filters interface alteration. When I started, I thought that it would be more filters to conform to optimization, but only SingleColumnValueFiler and SingleColumnValueFilter are. So, I'd better to just check for these filters in HRegionScanner than introduce extra method in interface. > Improve performance of scans with some kind of filters. > --- > > Key: HBASE-5416 > URL: https://issues.apache.org/jira/browse/HBASE-5416 > Project: HBase > Issue Type: Improvement > Components: Filters, Performance, regionserver >Affects Versions: 0.90.4 >Reporter: Max Lapan >Assignee: Max Lapan > Fix For: 0.96.0 > > Attachments: 5416-Filtered_scans_v6.patch, 5416-v5.txt, 5416-v6.txt, > Filtered_scans.patch, Filtered_scans_v2.patch, Filtered_scans_v3.patch, > Filtered_scans_v4.patch, Filtered_scans_v5.1.patch, Filtered_scans_v5.patch, > Filtered_scans_v7.patch > > > When the scan is performed, whole row is loaded into result list, after that > filter (if exists) is applied to detect that row is needed. > But when scan is performed on several CFs and filter checks only data from > the subset of these CFs, data from CFs, not checked by a filter is not needed > on a filter stage. Only when we decided to include current row. And in such > case we can significantly reduce amount of IO performed by a scan, by loading > only values, actually checked by a filter. > For example, we have two CFs: flags and snap. Flags is quite small (bunch of > megabytes) and is used to filter large entries from snap. Snap is very large > (10s of GB) and it is quite costly to scan it. If we needed only rows with > some flag specified, we use SingleColumnValueFilter to limit result to only > small subset of region. But current implementation is loading both CFs to > perform scan, when only small subset is needed. > Attached patch adds one routine to Filter interface to allow filter to > specify which CF is needed to it's operation. In HRegion, we separate all > scanners into two groups: needed for filter and the rest (joined). When new > row is considered, only needed data is loaded, filter applied, and only if > filter accepts the row, rest of data is loaded. At our data, this speeds up > such kind of scans 30-50 times. Also, this gives us the way to better > normalize the data into separate columns by optimizing the scans performed. -- 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-6966) "Compressed RPCs for HBase" (HBASE-5355) port to trunk
[ https://issues.apache.org/jira/browse/HBASE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devaraj Das updated HBASE-6966: --- Attachment: 6966-v1.2.txt Updated to the latest trunk. Still need to run benchmarks.. > "Compressed RPCs for HBase" (HBASE-5355) port to trunk > -- > > Key: HBASE-6966 > URL: https://issues.apache.org/jira/browse/HBASE-6966 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.96.0 > > Attachments: 6966-1.patch, 6966-v1.1.txt, 6966-v1.2.txt, 6966-v2.txt > > > This jira will address the port of the compressed RPC implementation to > trunk. I am expecting the patch to be significantly different due to the PB > stuff in trunk, and hence filed a separate jira. -- 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-7112) ZK_CLIENT_PORT_KEY maybe is not correct
[ https://issues.apache.org/jira/browse/HBASE-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492163#comment-13492163 ] Zhou wenjian commented on HBASE-7112: - 94 has correct it， just for 90. > ZK_CLIENT_PORT_KEY maybe is not correct > --- > > Key: HBASE-7112 > URL: https://issues.apache.org/jira/browse/HBASE-7112 > Project: HBase > Issue Type: Bug > Components: Zookeeper >Affects Versions: 0.90.6 >Reporter: Zhou wenjian > Fix For: 0.90.7 > > > the ZK_CLIENT_PORT_KEY is declared as followed: > private static final String ZK_CFG_PROPERTY = "hbase.zookeeper.property."; > private static final String ZK_CLIENT_PORT_KEY = ZK_CFG_PROPERTY > + "clientPort"; > i think it is not correct exactly, it should not contain the prefix > ZK_CFG_PROPERTY. > IMO, need to change it to private static final String ZK_CLIENT_PORT_KEY = > "clientPort"; -- 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-7112) ZK_CLIENT_PORT_KEY maybe is not correct
[ https://issues.apache.org/jira/browse/HBASE-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhou wenjian updated HBASE-7112: Affects Version/s: (was: 0.94.2) 0.90.6 Fix Version/s: (was: 0.94.4) 0.90.7 > ZK_CLIENT_PORT_KEY maybe is not correct > --- > > Key: HBASE-7112 > URL: https://issues.apache.org/jira/browse/HBASE-7112 > Project: HBase > Issue Type: Bug > Components: Zookeeper >Affects Versions: 0.90.6 >Reporter: Zhou wenjian > Fix For: 0.90.7 > > > the ZK_CLIENT_PORT_KEY is declared as followed: > private static final String ZK_CFG_PROPERTY = "hbase.zookeeper.property."; > private static final String ZK_CLIENT_PORT_KEY = ZK_CFG_PROPERTY > + "clientPort"; > i think it is not correct exactly, it should not contain the prefix > ZK_CFG_PROPERTY. > IMO, need to change it to private static final String ZK_CLIENT_PORT_KEY = > "clientPort"; -- 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-7112) ZK_CLIENT_PORT_KEY maybe is not correct
Zhou wenjian created HBASE-7112: --- Summary: ZK_CLIENT_PORT_KEY maybe is not correct Key: HBASE-7112 URL: https://issues.apache.org/jira/browse/HBASE-7112 Project: HBase Issue Type: Bug Components: Zookeeper Affects Versions: 0.94.2 Reporter: Zhou wenjian Fix For: 0.94.4 the ZK_CLIENT_PORT_KEY is declared as followed: private static final String ZK_CFG_PROPERTY = "hbase.zookeeper.property."; private static final String ZK_CLIENT_PORT_KEY = ZK_CFG_PROPERTY + "clientPort"; i think it is not correct exactly, it should not contain the prefix ZK_CFG_PROPERTY. IMO, need to change it to private static final String ZK_CLIENT_PORT_KEY = "clientPort"; -- 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-6958) TestAssignmentManager sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492154#comment-13492154
]
Ted Yu commented on HBASE-6958:
---
Trunk patch looks good.
> TestAssignmentManager sometimes fails
> -
>
> Key: HBASE-6958
> URL: https://issues.apache.org/jira/browse/HBASE-6958
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Ted Yu
>Assignee: Jimmy Xiang
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 6958_0.94.patch, trunk-6958.patch
>
>
> From
> https://builds.apache.org/job/HBase-TRUNK/3432/testReport/junit/org.apache.hadoop.hbase.master/TestAssignmentManager/testBalanceOnMasterFailoverScenarioWithOpenedNode/
> :
> {code}
> Stacktrace
> java.lang.Exception: test timed out after 5000 milliseconds
> at java.lang.System.arraycopy(Native Method)
> at java.lang.ThreadGroup.remove(ThreadGroup.java:969)
> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942)
> at java.lang.Thread.exit(Thread.java:732)
> ...
> 2012-10-06 00:46:12,521 DEBUG [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> zookeeper.ZKUtil(1141): mockedServer-0x13a33892de7000e Retrieved 81 byte(s)
> of data from znode /hbase/unassigned/dc01abf9cd7fd0ea256af4df02811640 and set
> watcher; region=t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.,
> state=M_ZK_REGION_OFFLINE, servername=master,1,1, createTime=1349484372509,
> payload.length=0
> 2012-10-06 00:46:12,522 ERROR [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> executor.EventHandler(205): Caught throwable while processing event
> RS_ZK_REGION_CLOSED
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$MockedLoadBalancer.randomAssignment(TestAssignmentManager.java:773)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1709)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1666)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1435)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1155)
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$AssignmentManagerWithExtrasForTesting.assign(TestAssignmentManager.java:1035)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1130)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1125)
> at
> org.apache.hadoop.hbase.master.handler.ClosedRegionHandler.process(ClosedRegionHandler.java:106)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2012-10-06 00:46:12,522 DEBUG [pool-1-thread-1-EventThread]
> master.AssignmentManager(670): Handling transition=M_ZK_REGION_OFFLINE,
> server=master,1,1, region=dc01abf9cd7fd0ea256af4df02811640, current state
> from region state map ={t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.
> state=OFFLINE, ts=1349484372508, server=null}
> {code}
> Looks like NPE happened on this line:
> {code}
> this.gate.set(true);
> {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-tabpanel&focusedCommentId=13492150#comment-13492150
]
Hadoop QA commented on HBASE-4583:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552419/4583-mixed.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 17 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.TestResettingCounters
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3247//console
This message is automatically generated.
> 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-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-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492149#comment-13492149 ] Jonathan Gray commented on HBASE-4583: -- A single timestamp for all columns is sufficient for the types of use cases I am imagining, so that's fine with me. > 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-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-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492146#comment-13492146 ] Lars Hofhansl commented on HBASE-4583: -- Do you think we need this per column (as in Puts/Deletes) or just one TS per Increment/Append, which would be used for all columns? The latter would be easier to do, especially for Increment. > 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-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-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492144#comment-13492144 ] Jonathan Gray commented on HBASE-4583: -- That makes sense to me (versions = 1 means upsert). Big +1 from me on adding support for setting the timestamp. > 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-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: - Attachment: 4583-mixed.txt Here's what I mean: Use upsert for Increment and Append if VERSIONS == 1, use Store.add otherwise (just like Puts in that case) TODO: I can easily adept Append to take the TS (in fact it already does, just not per column); for Increments it's a bit more tricky as currently just serializes a column -> long mapping. > 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-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-4583) Integrate RWCC with Append and Increment operations
[ https://issues.apache.org/jira/browse/HBASE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492132#comment-13492132 ] Lars Hofhansl commented on HBASE-4583: -- In that case both Append and Increment should also get an optional timestamp member (like Put and Delete) to set the TS to use. While looking at Increment and Append in trunk, were they never protobuf'ed? > 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-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-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-tabpanel&focusedCommentId=13492131#comment-13492131 ] Lars Hofhansl commented on HBASE-7103: -- [~ram_krish] Would it be most expedient to revert HBASE-6854 for now? Then we can tackle these two issues together. Thoughts? > 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 > > > 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-7097) Log message in SecureServer.class uses wrong class name
[
https://issues.apache.org/jira/browse/HBASE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492130#comment-13492130
]
Hudson commented on HBASE-7097:
---
Integrated in HBase-0.92 #605 (See
[https://builds.apache.org/job/HBase-0.92/605/])
Amend HBASE-7097. Change per-request logging in SecureServer to TRACE level
(Revision 1406421)
Result = FAILURE
apurtell :
Files :
*
/hbase/branches/0.92/security/src/main/java/org/apache/hadoop/hbase/ipc/SecureServer.java
> Log message in SecureServer.class uses wrong class name
> ---
>
> Key: HBASE-7097
> URL: https://issues.apache.org/jira/browse/HBASE-7097
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.92.2, 0.94.2
>Reporter: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 0.92.3, 0.94.3
>
> Attachments: HBASE-7097_94.patch, HBASE-7097-addendum.patch,
> HBASE-7097-addendum.patch
>
>
> log messages are printing wrongly in
> org.apache.hadoop.hbase.ipc.SecureServer.class
> {code}
> public static final Log LOG =
> LogFactory.getLog("org.apache.hadoop.ipc.SecureServer");
> private static final Log AUDITLOG =
> LogFactory.getLog("SecurityLogger.org.apache.hadoop.ipc.SecureServer");
> {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-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-tabpanel&focusedCommentId=13492122#comment-13492122 ] ramkrishna.s.vasudevan commented on HBASE-7103: --- @JD HBASE-6854 is a reason for this. But prior to this i can check and tell you the behaviour. > 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 > > > 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-tabpanel&focusedCommentId=13492116#comment-13492116 ] Lars Hofhansl commented on HBASE-4583: -- Another thought... As I described above I can also make upsert VERSIONS aware, by also counting the versions in upsert. That way even historical queries would be correct... Could be slow if many version are to be retained. There's also one other options: Use upsert if VERSIONS is set to 1 and use the normal Store.add otherwise. In both cases Omid type transaction engines could still work. I'm going to take it as a given from now on that we want to keep the upsert logic as the default option. > 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-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-6958) TestAssignmentManager sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492107#comment-13492107
]
ramkrishna.s.vasudevan commented on HBASE-6958:
---
+1 on patch.
> TestAssignmentManager sometimes fails
> -
>
> Key: HBASE-6958
> URL: https://issues.apache.org/jira/browse/HBASE-6958
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Ted Yu
>Assignee: Jimmy Xiang
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 6958_0.94.patch, trunk-6958.patch
>
>
> From
> https://builds.apache.org/job/HBase-TRUNK/3432/testReport/junit/org.apache.hadoop.hbase.master/TestAssignmentManager/testBalanceOnMasterFailoverScenarioWithOpenedNode/
> :
> {code}
> Stacktrace
> java.lang.Exception: test timed out after 5000 milliseconds
> at java.lang.System.arraycopy(Native Method)
> at java.lang.ThreadGroup.remove(ThreadGroup.java:969)
> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942)
> at java.lang.Thread.exit(Thread.java:732)
> ...
> 2012-10-06 00:46:12,521 DEBUG [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> zookeeper.ZKUtil(1141): mockedServer-0x13a33892de7000e Retrieved 81 byte(s)
> of data from znode /hbase/unassigned/dc01abf9cd7fd0ea256af4df02811640 and set
> watcher; region=t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.,
> state=M_ZK_REGION_OFFLINE, servername=master,1,1, createTime=1349484372509,
> payload.length=0
> 2012-10-06 00:46:12,522 ERROR [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> executor.EventHandler(205): Caught throwable while processing event
> RS_ZK_REGION_CLOSED
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$MockedLoadBalancer.randomAssignment(TestAssignmentManager.java:773)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1709)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1666)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1435)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1155)
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$AssignmentManagerWithExtrasForTesting.assign(TestAssignmentManager.java:1035)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1130)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1125)
> at
> org.apache.hadoop.hbase.master.handler.ClosedRegionHandler.process(ClosedRegionHandler.java:106)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2012-10-06 00:46:12,522 DEBUG [pool-1-thread-1-EventThread]
> master.AssignmentManager(670): Handling transition=M_ZK_REGION_OFFLINE,
> server=master,1,1, region=dc01abf9cd7fd0ea256af4df02811640, current state
> from region state map ={t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.
> state=OFFLINE, ts=1349484372508, server=null}
> {code}
> Looks like NPE happened on this line:
> {code}
> this.gate.set(true);
> {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-6958) TestAssignmentManager sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492099#comment-13492099
]
Jimmy Xiang commented on HBASE-6958:
@Ted, thanks a lot for review. I think the trunk patch is also needed since we
can't guarantee the test execution order.
> TestAssignmentManager sometimes fails
> -
>
> Key: HBASE-6958
> URL: https://issues.apache.org/jira/browse/HBASE-6958
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Ted Yu
>Assignee: Jimmy Xiang
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 6958_0.94.patch, trunk-6958.patch
>
>
> From
> https://builds.apache.org/job/HBase-TRUNK/3432/testReport/junit/org.apache.hadoop.hbase.master/TestAssignmentManager/testBalanceOnMasterFailoverScenarioWithOpenedNode/
> :
> {code}
> Stacktrace
> java.lang.Exception: test timed out after 5000 milliseconds
> at java.lang.System.arraycopy(Native Method)
> at java.lang.ThreadGroup.remove(ThreadGroup.java:969)
> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942)
> at java.lang.Thread.exit(Thread.java:732)
> ...
> 2012-10-06 00:46:12,521 DEBUG [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> zookeeper.ZKUtil(1141): mockedServer-0x13a33892de7000e Retrieved 81 byte(s)
> of data from znode /hbase/unassigned/dc01abf9cd7fd0ea256af4df02811640 and set
> watcher; region=t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.,
> state=M_ZK_REGION_OFFLINE, servername=master,1,1, createTime=1349484372509,
> payload.length=0
> 2012-10-06 00:46:12,522 ERROR [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> executor.EventHandler(205): Caught throwable while processing event
> RS_ZK_REGION_CLOSED
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$MockedLoadBalancer.randomAssignment(TestAssignmentManager.java:773)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1709)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1666)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1435)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1155)
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$AssignmentManagerWithExtrasForTesting.assign(TestAssignmentManager.java:1035)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1130)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1125)
> at
> org.apache.hadoop.hbase.master.handler.ClosedRegionHandler.process(ClosedRegionHandler.java:106)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2012-10-06 00:46:12,522 DEBUG [pool-1-thread-1-EventThread]
> master.AssignmentManager(670): Handling transition=M_ZK_REGION_OFFLINE,
> server=master,1,1, region=dc01abf9cd7fd0ea256af4df02811640, current state
> from region state map ={t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.
> state=OFFLINE, ts=1349484372508, server=null}
> {code}
> Looks like NPE happened on this line:
> {code}
> this.gate.set(true);
> {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-7097) Log message in SecureServer.class uses wrong class name
[
https://issues.apache.org/jira/browse/HBASE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492094#comment-13492094
]
Hudson commented on HBASE-7097:
---
Integrated in HBase-0.94 #575 (See
[https://builds.apache.org/job/HBase-0.94/575/])
Amend HBASE-7097. Change per-request logging in SecureServer to TRACE level
(Revision 1406420)
Result = FAILURE
apurtell :
Files :
*
/hbase/branches/0.94/security/src/main/java/org/apache/hadoop/hbase/ipc/SecureServer.java
> Log message in SecureServer.class uses wrong class name
> ---
>
> Key: HBASE-7097
> URL: https://issues.apache.org/jira/browse/HBASE-7097
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.92.2, 0.94.2
>Reporter: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 0.92.3, 0.94.3
>
> Attachments: HBASE-7097_94.patch, HBASE-7097-addendum.patch,
> HBASE-7097-addendum.patch
>
>
> log messages are printing wrongly in
> org.apache.hadoop.hbase.ipc.SecureServer.class
> {code}
> public static final Log LOG =
> LogFactory.getLog("org.apache.hadoop.ipc.SecureServer");
> private static final Log AUDITLOG =
> LogFactory.getLog("SecurityLogger.org.apache.hadoop.ipc.SecureServer");
> {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-7111) hbase zkcli will not start if the zookeeper server choosen to connectted to is not available
[
https://issues.apache.org/jira/browse/HBASE-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492089#comment-13492089
]
Zhou wenjian commented on HBASE-7111:
-
IMO, need to choose a random server to connect, rather than the fixed one which
is depended on the properties reading from conf
> hbase zkcli will not start if the zookeeper server choosen to connectted to
> is not available
> -
>
> Key: HBASE-7111
> URL: https://issues.apache.org/jira/browse/HBASE-7111
> Project: HBase
> Issue Type: Bug
> Components: Zookeeper
>Affects Versions: 0.94.2
>Reporter: Zhou wenjian
>Assignee: Zhou wenjian
> Fix For: 0.94.4
>
>
> there are 3 zookeeper servers in my cluster.
> s1
> s2
> s3
> after killing s3, i found the hbase zkcli will not start again.
> it will try to connect to s3 continuely.
> /11/07 11:01:01 INFO zookeeper.ClientCnxn: Opening socket connection to
> server s3
> 12/11/07 11:01:01 WARN zookeeper.ClientCnxn: Session 0x0 for server null,
> unexpected error, closing socket connection and attempting reconnect
> java.net.ConnectException: Connection refused
> from the code
> public String parse(final Configuration c) {
> // Note that we do not simply grab the property
> // HConstants.ZOOKEEPER_QUORUM from the HBaseConfiguration because the
> // user may be using a zoo.cfg file.
> Properties zkProps = ZKConfig.makeZKProps(c);
> String host = null;
> String clientPort = null;
> for (Entry entry: zkProps.entrySet()) {
> String key = entry.getKey().toString().trim();
> String value = entry.getValue().toString().trim();
> if (key.startsWith("server.") && host == null) {
> String[] parts = value.split(":");
> host = parts[0];
> } else if (key.endsWith("clientPort")) {
> clientPort = value;
> }
> if (host != null && clientPort != null) break;
> }
> return host != null && clientPort != null? host + ":" + clientPort: null;
> }
> the code will choose the fixed zookeeper server (here is the unavailable s3),
> which leads to the script fails
--
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-7111) hbase zkcli will not start if the zookeeper server choosen to connectted to is not available
Zhou wenjian created HBASE-7111:
---
Summary: hbase zkcli will not start if the zookeeper server
choosen to connectted to is not available
Key: HBASE-7111
URL: https://issues.apache.org/jira/browse/HBASE-7111
Project: HBase
Issue Type: Bug
Components: Zookeeper
Affects Versions: 0.94.2
Reporter: Zhou wenjian
Assignee: Zhou wenjian
Fix For: 0.94.4
there are 3 zookeeper servers in my cluster.
s1
s2
s3
after killing s3, i found the hbase zkcli will not start again.
it will try to connect to s3 continuely.
/11/07 11:01:01 INFO zookeeper.ClientCnxn: Opening socket connection to server
s3
12/11/07 11:01:01 WARN zookeeper.ClientCnxn: Session 0x0 for server null,
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
from the code
public String parse(final Configuration c) {
// Note that we do not simply grab the property
// HConstants.ZOOKEEPER_QUORUM from the HBaseConfiguration because the
// user may be using a zoo.cfg file.
Properties zkProps = ZKConfig.makeZKProps(c);
String host = null;
String clientPort = null;
for (Entry entry: zkProps.entrySet()) {
String key = entry.getKey().toString().trim();
String value = entry.getValue().toString().trim();
if (key.startsWith("server.") && host == null) {
String[] parts = value.split(":");
host = parts[0];
} else if (key.endsWith("clientPort")) {
clientPort = value;
}
if (host != null && clientPort != null) break;
}
return host != null && clientPort != null? host + ":" + clientPort: null;
}
the code will choose the fixed zookeeper server (here is the unavailable s3),
which leads to the script fails
--
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-6410) Move RegionServer Metrics to metrics2
[ https://issues.apache.org/jira/browse/HBASE-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492085#comment-13492085 ] Ted Yu commented on HBASE-6410: --- TestHFileOutputFormat failed in trunk build #3517. It consistently failed on Hadoop QA after this patch went in. > Move RegionServer Metrics to metrics2 > - > > Key: HBASE-6410 > URL: https://issues.apache.org/jira/browse/HBASE-6410 > Project: HBase > Issue Type: Sub-task > Components: metrics >Affects Versions: 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Blocker > Fix For: 0.96.0 > > Attachments: HBASE-6410-13.patch, HBASE-6410-15.patch, > HBASE-6410-16.patch, HBASE-6410-18.patch, HBASE-6410-1.patch, > HBASE-6410-2.patch, HBASE-6410-3.patch, HBASE-6410-4.patch, > HBASE-6410-5.patch, HBASE-6410-6.patch, HBASE-6410.patch > > > Move RegionServer Metrics to metrics2 -- 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-6410) Move RegionServer Metrics to metrics2
[ https://issues.apache.org/jira/browse/HBASE-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492083#comment-13492083 ] Hudson commented on HBASE-6410: --- Integrated in HBase-TRUNK #3517 (See [https://builds.apache.org/job/HBase-TRUNK/3517/]) HBASE-6410 Move RegionServer Metrics to metrics2 (Revision 1406396) Result = FAILURE eclark : Files : * /hbase/trunk/dev-support/findbugs-exclude.xml * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/CompatibilitySingletonFactory.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterWrapper.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/metrics/MasterMetricsSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/metrics/MasterMetricsSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/metrics/MasterMetricsWrapper.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/metrics/BaseMetricsSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/metrics/BaseSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionAggregateSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionServerSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionServerSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionServerWrapper.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionWrapper.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/metrics/ReplicationMetricsSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/rest/MetricsRESTSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/rest/metrics/RESTMetricsSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/thrift/MetricsThriftServerSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/thrift/MetricsThriftServerSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/thrift/metrics/ThriftServerMetricsSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/thrift/metrics/ThriftServerMetricsSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/metrics/MetricHistogram.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/metrics/MetricsExecutor.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/metrics2 * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/metrics2/MetricHistogram.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/metrics2/MetricsExecutor.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/master/TestMetricsMasterSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/master/metrics/TestMasterMetricsSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/regionserver * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsRegionServerSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestMetricsReplicationSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/replication/regionserver/metrics/TestReplicationMetricsSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/rest/TestMetricsRESTSource.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/rest/metrics/TestRESTMetricsSource.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/test/MetricsAssertHelper.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/thrift/TestMetricsThriftServerSourceFactory.java * /hbase/trunk/hbase-hadoop-compat/src/test/java/org/apache/hadoop/hbase/thrift/metrics/TestThriftServerMetri
[jira] [Commented] (HBASE-7061) region balance algorithm should do "contiue" instead of "break" when calculating the underloaded server
[
https://issues.apache.org/jira/browse/HBASE-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492080#comment-13492080
]
Sergey Shelukhin commented on HBASE-7061:
-
I think the intent is that serversByLoad entries are sorted in ascending order
by load (it's a TreeMap and ServerAndLoad first compares load), therefore it
adds entries until it finds the first server over the boundary. So it should be
correct... Do you see specific problem because of this code?
> region balance algorithm should do "contiue" instead of "break" when
> calculating the underloaded server
> ---
>
> Key: HBASE-7061
> URL: https://issues.apache.org/jira/browse/HBASE-7061
> Project: HBase
> Issue Type: Bug
>Reporter: Tianying Chang
>Assignee: Tianying Chang
>
> I found this issue when investigating HBASE-7060. Basically, I think the
> intention of this code below is to find all the underloaded server. By using
> break, it will exit earlier, depending on where the non-overloaded server
> show up in the list. "break" should be changed to "continue".
> Map underloadedServers = new HashMap Integer>();
> for (Map.Entry> server:
> serversByLoad.entrySet()) {
> int regionCount = server.getKey().getLoad();
> if (regionCount >= min) { break; }
> underloadedServers.put(server.getKey().getServerName(), min - regionCount);
> }
--
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-7097) Log message in SecureServer.class uses wrong class name
[
https://issues.apache.org/jira/browse/HBASE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-7097:
--
Attachment: HBASE-7097-addendum.patch
> Log message in SecureServer.class uses wrong class name
> ---
>
> Key: HBASE-7097
> URL: https://issues.apache.org/jira/browse/HBASE-7097
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.92.2, 0.94.2
>Reporter: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 0.92.3, 0.94.3
>
> Attachments: HBASE-7097_94.patch, HBASE-7097-addendum.patch,
> HBASE-7097-addendum.patch
>
>
> log messages are printing wrongly in
> org.apache.hadoop.hbase.ipc.SecureServer.class
> {code}
> public static final Log LOG =
> LogFactory.getLog("org.apache.hadoop.ipc.SecureServer");
> private static final Log AUDITLOG =
> LogFactory.getLog("SecurityLogger.org.apache.hadoop.ipc.SecureServer");
> {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] [Resolved] (HBASE-7097) Log message in SecureServer.class uses wrong class name
[
https://issues.apache.org/jira/browse/HBASE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-7097.
---
Resolution: Fixed
Committed addendum to 0.94 and 0.92 branches.
> Log message in SecureServer.class uses wrong class name
> ---
>
> Key: HBASE-7097
> URL: https://issues.apache.org/jira/browse/HBASE-7097
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.92.2, 0.94.2
>Reporter: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 0.92.3, 0.94.3
>
> Attachments: HBASE-7097_94.patch, HBASE-7097-addendum.patch,
> HBASE-7097-addendum.patch
>
>
> log messages are printing wrongly in
> org.apache.hadoop.hbase.ipc.SecureServer.class
> {code}
> public static final Log LOG =
> LogFactory.getLog("org.apache.hadoop.ipc.SecureServer");
> private static final Log AUDITLOG =
> LogFactory.getLog("SecurityLogger.org.apache.hadoop.ipc.SecureServer");
> {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-6466) Enable multi-thread for memstore flush
[ https://issues.apache.org/jira/browse/HBASE-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492065#comment-13492065 ] Sergey Shelukhin commented on HBASE-6466: - Ping? > Enable multi-thread for memstore flush > -- > > Key: HBASE-6466 > URL: https://issues.apache.org/jira/browse/HBASE-6466 > Project: HBase > Issue Type: Improvement >Reporter: chunhui shen >Assignee: chunhui shen > Attachments: HBASE-6466.patch, HBASE-6466v2.patch, HBASE-6466v3.patch > > > If the KV is large or Hlog is closed with high-pressure putting, we found > memstore is often above the high water mark and block the putting. > So should we enable multi-thread for Memstore Flush? > Some performance test data for reference, > 1.test environment ： > random writting；upper memstore limit 5.6GB;lower memstore limit 4.8GB;400 > regions per regionserver；row len=50 bytes, value len=1024 bytes;5 > regionserver, 300 ipc handler per regionserver;5 client, 50 thread handler > per client for writing > 2.test results: > one cacheFlush handler, tps: 7.8k/s per regionserver, Flush:10.1MB/s per > regionserver, appears many aboveGlobalMemstoreLimit blocking > two cacheFlush handlers, tps: 10.7k/s per regionserver, Flush:12.46MB/s per > regionserver, > 200 thread handler per client & two cacheFlush handlers, tps:16.1k/s per > regionserver, Flush:18.6MB/s per regionserver -- 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-5258) Move coprocessors set out of RegionLoad
[ https://issues.apache.org/jira/browse/HBASE-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492066#comment-13492066 ] Sergey Shelukhin commented on HBASE-5258: - hi. is there any progress to be made on this? > Move coprocessors set out of RegionLoad > --- > > Key: HBASE-5258 > URL: https://issues.apache.org/jira/browse/HBASE-5258 > Project: HBase > Issue Type: Task >Reporter: Ted Yu >Priority: Critical > > When I worked on HBASE-5256, I revisited the code related to Ser/De of > coprocessors set in RegionLoad. > I think the rationale for embedding coprocessors set is for maximum > flexibility where each region can load different coprocessors. > This flexibility is causing extra cost in the region server to Master > communication and increasing the footprint of Master heap. > Would HServerLoad be a better place for this set ? > If required, region server should calculate disparity of loaded coprocessors > among regions and send report through HServerLoad -- 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-6894) Adding metadata to a table in the shell is both arcane and painful
[
https://issues.apache.org/jira/browse/HBASE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492067#comment-13492067
]
Hadoop QA commented on HBASE-6894:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552385/HBASE-6894-v5-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 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 15 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.mapreduce.TestHFileOutputFormat
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3246//console
This message is automatically generated.
> Adding metadata to a table in the shell is both arcane and painful
> --
>
> Key: HBASE-6894
> URL: https://issues.apache.org/jira/browse/HBASE-6894
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 0.96.0
>Reporter: stack
>Assignee: Sergey Shelukhin
> Labels: noob
> Attachments: HBASE-6894.patch, HBASE-6894.patch, HBASE-6894.patch,
> HBASE-6894-v2.patch, HBASE-6894-v3.1-squashed.patch,
> HBASE-6894-v3-squashed.patch, HBASE-6894-v4-squashed.patch,
> HBASE-6894-v5-squashed.patch
>
>
> In production we have hundreds of tables w/ whack names like 'aliaserv',
> 'ashish_bulk', 'age_gender_topics', etc. It be grand if you could look in
> master UI and see stuff like owner, eng group responsible, miscellaneous
> description, etc.
> Now, HTD has support for this; each carries a dictionary. Whats a PITA
> though is adding attributes to the dictionary. Here is what seems to work on
> trunk (though I do not trust it is doing the right thing):
> {code}
> hbase> create 'SOME_TABLENAME', {NAME => 'd', VERSION => 1, COMPRESSION =>
> 'LZO'}
> hbase> # Here is how I added metadata
> hbase> disable 'SOME_TABLENAME'
> hbase> alter 'SOME_TABLENAME', METHOD => 'table_att', OWNER => 'SOMEON',
> CONFIG => {'ENVIRONMENT' => 'BLAH BLAH', 'SIZING' => 'The size should be
> between 0-10K most of the time with new URLs coming in and getting removed as
> they are processed unless the pipeline has fallen behind', 'MISCELLANEOUS' =>
> 'Holds the list of URLs waiting to be processed in the parked page detection
> analyzer in ingestion pipeline.'}
> ...
> describe...
> enable...
> {code}
> The above doesn't work in 0.94. Complains about the CONFIG, the keyword we
> are using for the HTD dictionary.
> It works in 0.96 though I'd have to poke around some more to ensure it is
> doing the right thing.
> But this METHOD => 'table_att' stuff is really ugly can we fix it?
> And I can't add table attributes on table create seemingly.
> A little bit of thought and a bit of ruby could clean this all up.
--
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-5416) Improve performance of scans with some kind of filters.
[ https://issues.apache.org/jira/browse/HBASE-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492064#comment-13492064 ] Sergey Shelukhin commented on HBASE-5416: - Hmm... then, are there other specific objections/disagreement with the above, or should we proceed with the patch? :) > Improve performance of scans with some kind of filters. > --- > > Key: HBASE-5416 > URL: https://issues.apache.org/jira/browse/HBASE-5416 > Project: HBase > Issue Type: Improvement > Components: Filters, Performance, regionserver >Affects Versions: 0.90.4 >Reporter: Max Lapan >Assignee: Max Lapan > Fix For: 0.96.0 > > Attachments: 5416-Filtered_scans_v6.patch, 5416-v5.txt, 5416-v6.txt, > Filtered_scans.patch, Filtered_scans_v2.patch, Filtered_scans_v3.patch, > Filtered_scans_v4.patch, Filtered_scans_v5.1.patch, Filtered_scans_v5.patch, > Filtered_scans_v7.patch > > > When the scan is performed, whole row is loaded into result list, after that > filter (if exists) is applied to detect that row is needed. > But when scan is performed on several CFs and filter checks only data from > the subset of these CFs, data from CFs, not checked by a filter is not needed > on a filter stage. Only when we decided to include current row. And in such > case we can significantly reduce amount of IO performed by a scan, by loading > only values, actually checked by a filter. > For example, we have two CFs: flags and snap. Flags is quite small (bunch of > megabytes) and is used to filter large entries from snap. Snap is very large > (10s of GB) and it is quite costly to scan it. If we needed only rows with > some flag specified, we use SingleColumnValueFilter to limit result to only > small subset of region. But current implementation is loading both CFs to > perform scan, when only small subset is needed. > Attached patch adds one routine to Filter interface to allow filter to > specify which CF is needed to it's operation. In HRegion, we separate all > scanners into two groups: needed for filter and the rest (joined). When new > row is considered, only needed data is loaded, filter applied, and only if > filter accepts the row, rest of data is loaded. At our data, this speeds up > such kind of scans 30-50 times. Also, this gives us the way to better > normalize the data into separate columns by optimizing the scans performed. -- 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-6989) Avoid unneceseary regular expression matching in ruby code for "list" command
[ https://issues.apache.org/jira/browse/HBASE-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aditya Kishore updated HBASE-6989: -- Status: Open (was: Patch Available) Cancelling and resubmitting the patch. > Avoid unneceseary regular expression matching in ruby code for "list" command > - > > Key: HBASE-6989 > URL: https://issues.apache.org/jira/browse/HBASE-6989 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Fix For: 0.96.0 > > Attachments: HBASE-6989.patch > > > HBaseAdmin already has an API which can accept a regular expression string > and return the matching tables. > The list command in HBase shell should make use of this and should not pull > the entire table list and do a matching of its own -- 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-6989) Avoid unneceseary regular expression matching in ruby code for "list" command
[ https://issues.apache.org/jira/browse/HBASE-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aditya Kishore updated HBASE-6989: -- Status: Patch Available (was: Open) > Avoid unneceseary regular expression matching in ruby code for "list" command > - > > Key: HBASE-6989 > URL: https://issues.apache.org/jira/browse/HBASE-6989 > Project: HBase > Issue Type: Bug > Components: shell >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Fix For: 0.96.0 > > Attachments: HBASE-6989.patch > > > HBaseAdmin already has an API which can accept a regular expression string > and return the matching tables. > The list command in HBase shell should make use of this and should not pull > the entire table list and do a matching of its own -- 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-tabpanel&focusedCommentId=13492057#comment-13492057 ] Lars Hofhansl commented on HBASE-7103: -- I have very limited knowledge in this area... From looking through the code briefly, if two splits happen roughly the parallel the 2nd one will fail due to the split node already existing (see SplitTransaction.createNodeSplitting), but I then it already wrote STARTED_SPLITTING to its journal. Now the transaction is rolled back and will cleanup the ZK state. So I guess we can either: # track whether the split transaction failed because of a concurrent split, in that case we won't clean the zk state. # First try to create a ZK node, then write to the journal. Both cases probably have bad side effects and races. > 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 > > > 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-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-tabpanel&focusedCommentId=13492054#comment-13492054
]
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/12552378/HBASE-7109-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 15 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.mapreduce.TestHFileOutputFormat
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3242//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
>
>
> 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-6338) Cache Method in RPC handler
[ https://issues.apache.org/jira/browse/HBASE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492049#comment-13492049 ] Sergey Shelukhin commented on HBASE-6338: - then this seems straightforward to just apply to 0.94 > Cache Method in RPC handler > --- > > Key: HBASE-6338 > URL: https://issues.apache.org/jira/browse/HBASE-6338 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.94.3 >Reporter: binlijin > Attachments: HBASE-6338-90-2.patch, HBASE-6338-90.patch, > HBASE-6338-92-2.patch, HBASE-6338-92.patch, HBASE-6338-94-2.patch, > HBASE-6338-94.patch, HBASE-6338-trunk-2.patch, HBASE-6338-trunk.patch > > > Every call in rpc handler a Method will be created, if we cache the method > will improve a little. > I test with 0.90, Average Class.getMethod(String name, Class... > parameterTypes) cost 4780 ns , if we cache it cost 2620 ns. -- 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-6338) Cache Method in RPC handler
[ https://issues.apache.org/jira/browse/HBASE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-6338: Affects Version/s: 0.94.3 > Cache Method in RPC handler > --- > > Key: HBASE-6338 > URL: https://issues.apache.org/jira/browse/HBASE-6338 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.94.3 >Reporter: binlijin > Attachments: HBASE-6338-90-2.patch, HBASE-6338-90.patch, > HBASE-6338-92-2.patch, HBASE-6338-92.patch, HBASE-6338-94-2.patch, > HBASE-6338-94.patch, HBASE-6338-trunk-2.patch, HBASE-6338-trunk.patch > > > Every call in rpc handler a Method will be created, if we cache the method > will improve a little. > I test with 0.90, Average Class.getMethod(String name, Class... > parameterTypes) cost 4780 ns , if we cache it cost 2620 ns. -- 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-7097) Log message in SecureServer.class uses wrong class name
[
https://issues.apache.org/jira/browse/HBASE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492038#comment-13492038
]
Lars Hofhansl commented on HBASE-7097:
--
+1
> Log message in SecureServer.class uses wrong class name
> ---
>
> Key: HBASE-7097
> URL: https://issues.apache.org/jira/browse/HBASE-7097
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.92.2, 0.94.2
>Reporter: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 0.92.3, 0.94.3
>
> Attachments: HBASE-7097_94.patch, HBASE-7097-addendum.patch
>
>
> log messages are printing wrongly in
> org.apache.hadoop.hbase.ipc.SecureServer.class
> {code}
> public static final Log LOG =
> LogFactory.getLog("org.apache.hadoop.ipc.SecureServer");
> private static final Log AUDITLOG =
> LogFactory.getLog("SecurityLogger.org.apache.hadoop.ipc.SecureServer");
> {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-7108) Don't allow "recovered.edits" as legal family name
[
https://issues.apache.org/jira/browse/HBASE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492035#comment-13492035
]
Hadoop QA commented on HBASE-7108:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552359/HBASE-7108-v0.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 15 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.mapreduce.TestHFileOutputFormat
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3239//console
This message is automatically generated.
> Don't allow "recovered.edits" as legal family name
> --
>
> Key: HBASE-7108
> URL: https://issues.apache.org/jira/browse/HBASE-7108
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.92.2, 0.94.2, 0.96.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.96.0
>
> Attachments: HBASE-7108-v0.patch
>
>
> Region directories can contain a folder called "recovered.edits", log
> splitting related.
> But there's nothing that prevent a user to create a family with that name...
--
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-7097) Log message in SecureServer.class uses wrong class name
[
https://issues.apache.org/jira/browse/HBASE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492033#comment-13492033
]
Andrew Purtell commented on HBASE-7097:
---
Thanks for taking a look Lars. I'll commit the proposed addendum with the
additional log messages you called out moved to TRACE level shortly unless
there is further comment. I don't think they are that useful.
> Log message in SecureServer.class uses wrong class name
> ---
>
> Key: HBASE-7097
> URL: https://issues.apache.org/jira/browse/HBASE-7097
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.92.2, 0.94.2
>Reporter: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 0.92.3, 0.94.3
>
> Attachments: HBASE-7097_94.patch, HBASE-7097-addendum.patch
>
>
> log messages are printing wrongly in
> org.apache.hadoop.hbase.ipc.SecureServer.class
> {code}
> public static final Log LOG =
> LogFactory.getLog("org.apache.hadoop.ipc.SecureServer");
> private static final Log AUDITLOG =
> LogFactory.getLog("SecurityLogger.org.apache.hadoop.ipc.SecureServer");
> {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-7110) refactor the compaction selection and config code similarly to 0.89-fb changes
[ https://issues.apache.org/jira/browse/HBASE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492032#comment-13492032 ] Sergey Shelukhin commented on HBASE-7110: - woops, I meant the above comment to be in 7109 > refactor the compaction selection and config code similarly to 0.89-fb changes > -- > > Key: HBASE-7110 > URL: https://issues.apache.org/jira/browse/HBASE-7110 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-6371-v5-refactor-only-squashed.patch > > > Separate JIRA for refactoring changes from HBASE-7055 (and further ones after > code review) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-6222) Add per-KeyValue Security
[ https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell reassigned HBASE-6222: - Assignee: Andrew Purtell > 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 > > 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-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-tabpanel&focusedCommentId=13492030#comment-13492030 ] Sergey Shelukhin commented on HBASE-7109: - testclassfinder is not a test, it's a finder of test classes... will rename to avoid confusion > 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 > > > 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-6222) Add per-KeyValue Security
[ https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492029#comment-13492029 ] Andrew Purtell commented on HBASE-6222: --- I am currently exploring/coding a couple of implementation options in parallel. Please ping me if you're working in this area. > 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 > > 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-6894) Adding metadata to a table in the shell is both arcane and painful
[
https://issues.apache.org/jira/browse/HBASE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492025#comment-13492025
]
Sergey Shelukhin commented on HBASE-6894:
-
Fixed TABLE_ATTRIBUTES (which is not technically a constant, but I guess this
doesn't have to be valid Ruby), as well as alter help.
The delete CF stuff is legacy, I'm not changing that. I created HBASE-7064 for
explaining CONFIG (as well as other things).
You can erase from config by setting key to nil, which I guess is not the most
obvious way...
> Adding metadata to a table in the shell is both arcane and painful
> --
>
> Key: HBASE-6894
> URL: https://issues.apache.org/jira/browse/HBASE-6894
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 0.96.0
>Reporter: stack
>Assignee: Sergey Shelukhin
> Labels: noob
> Attachments: HBASE-6894.patch, HBASE-6894.patch, HBASE-6894.patch,
> HBASE-6894-v2.patch, HBASE-6894-v3.1-squashed.patch,
> HBASE-6894-v3-squashed.patch, HBASE-6894-v4-squashed.patch,
> HBASE-6894-v5-squashed.patch
>
>
> In production we have hundreds of tables w/ whack names like 'aliaserv',
> 'ashish_bulk', 'age_gender_topics', etc. It be grand if you could look in
> master UI and see stuff like owner, eng group responsible, miscellaneous
> description, etc.
> Now, HTD has support for this; each carries a dictionary. Whats a PITA
> though is adding attributes to the dictionary. Here is what seems to work on
> trunk (though I do not trust it is doing the right thing):
> {code}
> hbase> create 'SOME_TABLENAME', {NAME => 'd', VERSION => 1, COMPRESSION =>
> 'LZO'}
> hbase> # Here is how I added metadata
> hbase> disable 'SOME_TABLENAME'
> hbase> alter 'SOME_TABLENAME', METHOD => 'table_att', OWNER => 'SOMEON',
> CONFIG => {'ENVIRONMENT' => 'BLAH BLAH', 'SIZING' => 'The size should be
> between 0-10K most of the time with new URLs coming in and getting removed as
> they are processed unless the pipeline has fallen behind', 'MISCELLANEOUS' =>
> 'Holds the list of URLs waiting to be processed in the parked page detection
> analyzer in ingestion pipeline.'}
> ...
> describe...
> enable...
> {code}
> The above doesn't work in 0.94. Complains about the CONFIG, the keyword we
> are using for the HTD dictionary.
> It works in 0.96 though I'd have to poke around some more to ensure it is
> doing the right thing.
> But this METHOD => 'table_att' stuff is really ugly can we fix it?
> And I can't add table attributes on table create seemingly.
> A little bit of thought and a bit of ruby could clean this all up.
--
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-6894) Adding metadata to a table in the shell is both arcane and painful
[
https://issues.apache.org/jira/browse/HBASE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-6894:
Attachment: HBASE-6894-v5-squashed.patch
> Adding metadata to a table in the shell is both arcane and painful
> --
>
> Key: HBASE-6894
> URL: https://issues.apache.org/jira/browse/HBASE-6894
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 0.96.0
>Reporter: stack
>Assignee: Sergey Shelukhin
> Labels: noob
> Attachments: HBASE-6894.patch, HBASE-6894.patch, HBASE-6894.patch,
> HBASE-6894-v2.patch, HBASE-6894-v3.1-squashed.patch,
> HBASE-6894-v3-squashed.patch, HBASE-6894-v4-squashed.patch,
> HBASE-6894-v5-squashed.patch
>
>
> In production we have hundreds of tables w/ whack names like 'aliaserv',
> 'ashish_bulk', 'age_gender_topics', etc. It be grand if you could look in
> master UI and see stuff like owner, eng group responsible, miscellaneous
> description, etc.
> Now, HTD has support for this; each carries a dictionary. Whats a PITA
> though is adding attributes to the dictionary. Here is what seems to work on
> trunk (though I do not trust it is doing the right thing):
> {code}
> hbase> create 'SOME_TABLENAME', {NAME => 'd', VERSION => 1, COMPRESSION =>
> 'LZO'}
> hbase> # Here is how I added metadata
> hbase> disable 'SOME_TABLENAME'
> hbase> alter 'SOME_TABLENAME', METHOD => 'table_att', OWNER => 'SOMEON',
> CONFIG => {'ENVIRONMENT' => 'BLAH BLAH', 'SIZING' => 'The size should be
> between 0-10K most of the time with new URLs coming in and getting removed as
> they are processed unless the pipeline has fallen behind', 'MISCELLANEOUS' =>
> 'Holds the list of URLs waiting to be processed in the parked page detection
> analyzer in ingestion pipeline.'}
> ...
> describe...
> enable...
> {code}
> The above doesn't work in 0.94. Complains about the CONFIG, the keyword we
> are using for the HTD dictionary.
> It works in 0.96 though I'd have to poke around some more to ensure it is
> doing the right thing.
> But this METHOD => 'table_att' stuff is really ugly can we fix it?
> And I can't add table attributes on table create seemingly.
> A little bit of thought and a bit of ruby could clean this all up.
--
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-6353) Snapshots shell
[
https://issues.apache.org/jira/browse/HBASE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492019#comment-13492019
]
Hadoop QA commented on HBASE-6353:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12551976/snapshot-offline-test-demo.shell
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/3244//console
This message is automatically generated.
> Snapshots shell
> ---
>
> Key: HBASE-6353
> URL: https://issues.apache.org/jira/browse/HBASE-6353
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-6353-v0.patch, HBASE-6353-v1.patch,
> snapshot-offline-test-demo.shell
>
>
> h6. hbase shell with snapshot commands
> * snapshot
> ** Take a snapshot of the specified name with the specified name
> * restore_snapshot
> ** Restore specified snapshot on the original table
> * clone_snapshot
> ** Create a new table based on the snapshot content
> * list_snapshots [filter]
> ** Show the list of snapshots taken
> * delete_snapshot
> ** Remove a specified snapshot
> * rename_snapshot
> ** Rename a snapshot to a new name
> h6. Restore Table
> Given a "snapshot name" restore override the original table with the snapshot
> content.
> Before restoring a new snapshot of the table is taken, just to avoid bad
> situations.
> This allows a full and quick rollback to a previous snapshot.
> h6. Clone from Snapshot
> Given a "snapshot name" a new table is created with the content of the
> specified snapshot.
> This operation allows:
> * To have an old version of the table in parallel with the current one.
> ** Look at snapshot side-by-side with the "current" before making the
> decision whether to roll back or not
> * To Add/Remove data from this table without affecting the original one or
> the snapshot.
> * To Restore only "individual items" (only some small range of data was lost
> from "current")
> ** MR job that scan the cloned table and update the data in the original
> one. (Partial restore of the data)
> h6. Open points
> * Add snapshot type option on take snapshot command (global, timestamp)?
--
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-7110) refactor the compaction selection and config code similarly to 0.89-fb changes
[
https://issues.apache.org/jira/browse/HBASE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492018#comment-13492018
]
Hadoop QA commented on HBASE-7110:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552379/HBASE-6371-v5-refactor-only-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 11 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3243//console
This message is automatically generated.
> refactor the compaction selection and config code similarly to 0.89-fb changes
> --
>
> Key: HBASE-7110
> URL: https://issues.apache.org/jira/browse/HBASE-7110
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.96.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-6371-v5-refactor-only-squashed.patch
>
>
> Separate JIRA for refactoring changes from HBASE-7055 (and further ones after
> code review)
--
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-tabpanel&focusedCommentId=13492012#comment-13492012 ] Matt Corgan commented on HBASE-7103: I disabled my custom balancer (external java program that calls HBaseAdmin.move()) and it's been working without error for longer than usual. I've been using the same balancer since .90 series I think, so possibly something changed where calling move() on a new daughter region soon after a split leaves ZK in a bad state. > 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 > > > 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-tabpanel&focusedCommentId=13492006#comment-13492006
]
Hadoop QA commented on HBASE-4583:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12551483/4583-trunk-less-radical-v6.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:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3241//console
This message is automatically generated.
> 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-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-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-tabpanel&focusedCommentId=13492004#comment-13492004
]
Ted Yu commented on HBASE-7109:
---
{code}
+ private Class makeClass(String className, boolean optimistic)
{code}
optimistic is governing how exception is handled. Would failOnException be a
better name ?
{code}
+
+public class TestClassFinder extends ClassFinder {
{code}
The above test is missing test category.
> 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
>
>
> 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-5898) Consider double-checked locking for block cache lock
[ https://issues.apache.org/jira/browse/HBASE-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491999#comment-13491999 ] Lars Hofhansl commented on HBASE-5898: -- In the light of HBASE-6852, even saving taking the lock if we already have cached the block, might lead to a nice performance improvement. > Consider double-checked locking for block cache lock > > > Key: HBASE-5898 > URL: https://issues.apache.org/jira/browse/HBASE-5898 > Project: HBase > Issue Type: Improvement > Components: Performance >Affects Versions: 0.94.1 >Reporter: Todd Lipcon >Assignee: Todd Lipcon >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: 5898-TestBlocksRead.txt, HBASE-5898-0.patch, > HBASE-5898-1.patch, hbase-5898.txt > > > Running a workload with a high query rate against a dataset that fits in > cache, I saw a lot of CPU being used in IdLock.getLockEntry, being called by > HFileReaderV2.readBlock. Even though it was all cache hits, it was wasting a > lot of CPU doing lock management here. I wrote a quick patch to switch to a > double-checked locking and it improved throughput substantially for this > workload. -- 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-7110) refactor the compaction selection and config code similarly to 0.89-fb changes
[ https://issues.apache.org/jira/browse/HBASE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491994#comment-13491994 ] Sergey Shelukhin commented on HBASE-7110: - [~enis] can you please take a look eventually? Thanks! > refactor the compaction selection and config code similarly to 0.89-fb changes > -- > > Key: HBASE-7110 > URL: https://issues.apache.org/jira/browse/HBASE-7110 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-6371-v5-refactor-only-squashed.patch > > > Separate JIRA for refactoring changes from HBASE-7055 (and further ones after > code review) -- 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-tabpanel&focusedCommentId=13491995#comment-13491995 ] Lars Hofhansl commented on HBASE-7103: -- Did you change how frequently the balancer runs? > 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 > > > 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-7055) port HBASE-6371 tier-based compaction from 0.89-fb to trunk
[ https://issues.apache.org/jira/browse/HBASE-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491992#comment-13491992 ] Sergey Shelukhin commented on HBASE-7055: - sorry, didn't read the comment completely... new JIRA is HBASE-7110; latest patch added there. With regard to this JIRA - are we good with porting it without dynamic config updates, with cf-specific config stored on CF, and off by default? I'd treat compaction algorithms as internal as opposed to an extension point, so it would follow that we can create specific CF properties. > port HBASE-6371 tier-based compaction from 0.89-fb to trunk > --- > > Key: HBASE-7055 > URL: https://issues.apache.org/jira/browse/HBASE-7055 > Project: HBase > Issue Type: Task > Components: Compaction >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Fix For: 0.96.0 > > Attachments: HBASE-6371-squashed.patch, HBASE-6371-v2-squashed.patch, > HBASE-6371-v3-refactor-only-squashed.patch, > HBASE-6371-v4-refactor-only-squashed.patch, > HBASE-6371-v5-refactor-only-squashed.patch > > > There's divergence in the code :( > See HBASE-6371 for details. -- 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-7110) refactor the compaction selection and config code similarly to 0.89-fb changes
[ https://issues.apache.org/jira/browse/HBASE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-7110: Status: Patch Available (was: Open) > refactor the compaction selection and config code similarly to 0.89-fb changes > -- > > Key: HBASE-7110 > URL: https://issues.apache.org/jira/browse/HBASE-7110 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-6371-v5-refactor-only-squashed.patch > > > Separate JIRA for refactoring changes from HBASE-7055 (and further ones after > code review) -- 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-7110) refactor the compaction selection and config code similarly to 0.89-fb changes
[ https://issues.apache.org/jira/browse/HBASE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-7110: Attachment: HBASE-6371-v5-refactor-only-squashed.patch > refactor the compaction selection and config code similarly to 0.89-fb changes > -- > > Key: HBASE-7110 > URL: https://issues.apache.org/jira/browse/HBASE-7110 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-6371-v5-refactor-only-squashed.patch > > > Separate JIRA for refactoring changes from HBASE-7055 (and further ones after > code review) -- 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-7110) refactor the compaction selection and config code similarly to 0.89-fb changes
[ https://issues.apache.org/jira/browse/HBASE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-7110: Description: Separate JIRA for refactoring changes from HBASE-7055 (and further ones after code review) > refactor the compaction selection and config code similarly to 0.89-fb changes > -- > > Key: HBASE-7110 > URL: https://issues.apache.org/jira/browse/HBASE-7110 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-6371-v5-refactor-only-squashed.patch > > > Separate JIRA for refactoring changes from HBASE-7055 (and further ones after > code review) -- 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-7108) Don't allow "recovered.edits" as legal family name
[ https://issues.apache.org/jira/browse/HBASE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491991#comment-13491991 ] Todd Lipcon commented on HBASE-7108: For compatibility, one option would be: - in 0.94: change code to recognize both "recovered.edits" and ".recovered.edits" at region-open time - in 0.96: change code to write to ".recovered.edits" and recognize both Then, so long as someone is upgrading from the most recent 0.94 to 0.96, they'd be fine. An upgrade from an older 0.94 or 0.92 to 0.96 would potentially have an issue if there were a failure in the middle of a rolling upgrade. Would that be acceptible? > Don't allow "recovered.edits" as legal family name > -- > > Key: HBASE-7108 > URL: https://issues.apache.org/jira/browse/HBASE-7108 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.92.2, 0.94.2, 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.96.0 > > Attachments: HBASE-7108-v0.patch > > > Region directories can contain a folder called "recovered.edits", log > splitting related. > But there's nothing that prevent a user to create a family with that name... -- 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-7110) refactor the compaction selection and config code similarly to 0.89-fb changes
Sergey Shelukhin created HBASE-7110: --- Summary: refactor the compaction selection and config code similarly to 0.89-fb changes Key: HBASE-7110 URL: https://issues.apache.org/jira/browse/HBASE-7110 Project: HBase Issue Type: Improvement Affects Versions: 0.96.0 Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin -- 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: Status: Patch Available (was: Open) > 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 > > > 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-squashed.patch Initial 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 > > > 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-7009) Port HBaseCluster interface/tests to 0.94
[
https://issues.apache.org/jira/browse/HBASE-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491985#comment-13491985
]
Hadoop QA commented on HBASE-7009:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552357/HBASE-7009-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 75 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3240//console
This message is automatically generated.
> Port HBaseCluster interface/tests to 0.94
> -
>
> Key: HBASE-7009
> URL: https://issues.apache.org/jira/browse/HBASE-7009
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Affects Versions: 0.94.3
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Fix For: 0.94.4
>
> Attachments: HBASE-7009-p1.patch, HBASE-7009.patch,
> HBASE-7009-v2-squashed.patch, HBASE-7009-v3-squashed.patch
>
>
> Need to port. I am porting V5 patch from the original JIRA; I have a
> partially ported (V3) patch from Enis with protocol buffers being reverted to
> HRegionInterface/HMasterInterface
--
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-5898) Consider double-checked locking for block cache lock
[ https://issues.apache.org/jira/browse/HBASE-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491971#comment-13491971 ] Lars Hofhansl commented on HBASE-5898: -- Wanna commit Stack? :) > Consider double-checked locking for block cache lock > > > Key: HBASE-5898 > URL: https://issues.apache.org/jira/browse/HBASE-5898 > Project: HBase > Issue Type: Improvement > Components: Performance >Affects Versions: 0.94.1 >Reporter: Todd Lipcon >Assignee: Todd Lipcon >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: 5898-TestBlocksRead.txt, HBASE-5898-0.patch, > HBASE-5898-1.patch, hbase-5898.txt > > > Running a workload with a high query rate against a dataset that fits in > cache, I saw a lot of CPU being used in IdLock.getLockEntry, being called by > HFileReaderV2.readBlock. Even though it was all cache hits, it was wasting a > lot of CPU doing lock management here. I wrote a quick patch to switch to a > double-checked locking and it improved throughput substantially for this > workload. -- 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-6793) Make hbase-examples module
[ https://issues.apache.org/jira/browse/HBASE-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491954#comment-13491954 ] Hudson commented on HBASE-6793: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #250 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/250/]) HBASE-6793 Make hbase-examples module (Revision 1406339) Result = FAILURE stack : Files : * /hbase/trunk/examples * /hbase/trunk/hbase-examples * /hbase/trunk/hbase-examples/README.txt * /hbase/trunk/hbase-examples/pom.xml * /hbase/trunk/hbase-examples/src * /hbase/trunk/hbase-examples/src/main * /hbase/trunk/hbase-examples/src/main/cpp * /hbase/trunk/hbase-examples/src/main/cpp/DemoClient.cpp * /hbase/trunk/hbase-examples/src/main/cpp/Makefile * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase.h * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_constants.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_constants.h * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_server.skeleton.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_types.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_types.h * /hbase/trunk/hbase-examples/src/main/java * /hbase/trunk/hbase-examples/src/main/java/org * /hbase/trunk/hbase-examples/src/main/java/org/apache * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce/IndexBuilder.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce/SampleUploader.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/DemoClient.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/AlreadyExists.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/BatchMutation.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/ColumnDescriptor.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/Hbase.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/IOError.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/IllegalArgument.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/Mutation.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TCell.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TIncrement.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TRegionInfo.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TRowResult.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TScan.java * /hbase/trunk/hbase-examples/src/main/perl * /hbase/trunk/hbase-examples/src/main/perl/DemoClient.pl * /hbase/trunk/hbase-examples/src/main/perl/gen-perl * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase/Constants.pm * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase/Hbase.pm * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase/Types.pm * /hbase/trunk/hbase-examples/src/main/php * /hbase/trunk/hbase-examples/src/main/php/DemoClient.php * /hbase/trunk/hbase-examples/src/main/php/gen-php * /hbase/trunk/hbase-examples/src/main/php/gen-php/Hbase * /hbase/trunk/hbase-examples/src/main/php/gen-php/Hbase/Hbase.php * /hbase/trunk/hbase-examples/src/main/php/gen-php/Hbase/Types.php * /hbase/trunk/hbase-examples/src/main/python * /hbase/trunk/hbase-examples/src/main/python/DemoClient.py * /hbase/trunk/hbase-examples/src/main/python/gen-py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/Hbase-remote * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/Hbase.py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/__init__.py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/constants.py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/ttypes.py * /hbase/trunk/hbase-examples/src/main/ruby * /hbase/trunk/hbase-examples/src/main/ruby/DemoClient.rb * /hbase/trunk/hbase-examples/src/main/ruby/gen-rb * /hbase/trunk/hbase-examples/src/main/ruby/gen-rb/hbase.rb * /hbase/trunk/hbase-examples/src/main/ruby/gen-rb/hbase_constants.rb * /hbase/trunk/
[jira] [Commented] (HBASE-6991) Escape "\" in Bytes.toStringBinary() and its counterpart Bytes.toBytesBinary()
[
https://issues.apache.org/jira/browse/HBASE-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491955#comment-13491955
]
Hudson commented on HBASE-6991:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #250 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/250/])
HBASE-6991 Escape "\" in Bytes.toStringBinary() and its counterpart
Bytes.toBytesBinary() (Revision 1406297)
Result = FAILURE
stack :
Files :
*
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java
*
/hbase/trunk/hbase-common/src/test/java/org/apache/hadoop/hbase/util/TestBytes.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlock.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockCompatibility.java
> Escape "\" in Bytes.toStringBinary() and its counterpart Bytes.toBytesBinary()
> --
>
> Key: HBASE-6991
> URL: https://issues.apache.org/jira/browse/HBASE-6991
> Project: HBase
> Issue Type: Bug
> Components: util
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
> Fix For: 0.96.0
>
> Attachments: HBASE-6991_trunk.patch
>
>
> Since "\" is used to escape non-printable character but not treated as
> special character in conversion, it could lead to unexpected conversion.
> For example, please consider the following code snippet.
> {code}
> public void testConversion() {
> byte[] original = {
> '\\', 'x', 'A', 'D'
> };
> String stringFromBytes = Bytes.toStringBinary(original);
> byte[] converted = Bytes.toBytesBinary(stringFromBytes);
> System.out.println("Original: " + Arrays.toString(original));
> System.out.println("Converted: " + Arrays.toString(converted));
> System.out.println("Reversible?: " + (Bytes.compareTo(original, converted)
> == 0));
> }
> Output:
> ---
> Original: [92, 120, 65, 68]
> Converted: [-83]
> Reversible?: false
> {code}
> The "\" character needs to be treated as special and must be encoded as a
> non-printable character ("\x5C") to avoid any kind of ambiguity during
> conversion.
--
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-7109) integration tests on cluster are not getting picked up from distribution
Sergey Shelukhin created HBASE-7109: --- Summary: 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 Affects Versions: 0.96.0 Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin 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-6958) TestAssignmentManager sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491947#comment-13491947
]
Hadoop QA commented on HBASE-6958:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552340/trunk-6958.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
85 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 11 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/3238//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3238//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3238//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3238//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3238//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3238//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3238//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3238//console
This message is automatically generated.
> TestAssignmentManager sometimes fails
> -
>
> Key: HBASE-6958
> URL: https://issues.apache.org/jira/browse/HBASE-6958
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Ted Yu
>Assignee: Jimmy Xiang
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 6958_0.94.patch, trunk-6958.patch
>
>
> From
> https://builds.apache.org/job/HBase-TRUNK/3432/testReport/junit/org.apache.hadoop.hbase.master/TestAssignmentManager/testBalanceOnMasterFailoverScenarioWithOpenedNode/
> :
> {code}
> Stacktrace
> java.lang.Exception: test timed out after 5000 milliseconds
> at java.lang.System.arraycopy(Native Method)
> at java.lang.ThreadGroup.remove(ThreadGroup.java:969)
> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942)
> at java.lang.Thread.exit(Thread.java:732)
> ...
> 2012-10-06 00:46:12,521 DEBUG [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> zookeeper.ZKUtil(1141): mockedServer-0x13a33892de7000e Retrieved 81 byte(s)
> of data from znode /hbase/unassigned/dc01abf9cd7fd0ea256af4df02811640 and set
> watcher; region=t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.,
> state=M_ZK_REGION_OFFLINE, servername=master,1,1, createTime=1349484372509,
> payload.length=0
> 2012-10-06 00:46:12,522 ERROR [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> executor.EventHandler(205): Caught throwable while processing event
> RS_ZK_REGION_CLOSED
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$MockedLoadBalancer.randomAssignment(TestAssignmentManager.java:773)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1709)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1666)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1435)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1155)
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$AssignmentManagerWithExtrasForTesting.assign(TestAssignmentManager.java:1035)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1130)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1125)
> at
> org.apache.hadoop.hbase.master.handler.ClosedRegionHandler.process(ClosedRegionHandler.java:106)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(Eve
[jira] [Updated] (HBASE-6410) Move RegionServer Metrics to metrics2
[ https://issues.apache.org/jira/browse/HBASE-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-6410: - Resolution: Fixed Fix Version/s: 0.96.0 Release Note: Region server metrics are now exported through Hadoop's new metrics 2 sub system. Naming and location of MBeans have changed to be more consistent and informative. Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed revision 1406396 Thanks all for the reviews. > Move RegionServer Metrics to metrics2 > - > > Key: HBASE-6410 > URL: https://issues.apache.org/jira/browse/HBASE-6410 > Project: HBase > Issue Type: Sub-task > Components: metrics >Affects Versions: 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Blocker > Fix For: 0.96.0 > > Attachments: HBASE-6410-13.patch, HBASE-6410-15.patch, > HBASE-6410-16.patch, HBASE-6410-18.patch, HBASE-6410-1.patch, > HBASE-6410-2.patch, HBASE-6410-3.patch, HBASE-6410-4.patch, > HBASE-6410-5.patch, HBASE-6410-6.patch, HBASE-6410.patch > > > Move RegionServer Metrics to metrics2 -- 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-7108) Don't allow "recovered.edits" as legal family name
[ https://issues.apache.org/jira/browse/HBASE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491932#comment-13491932 ] Matteo Bertozzi commented on HBASE-7108: yeah good catch, we don't allow the '.' as starting character in the family name. So, can I just rename "recovered.edits" in ".recovered.edits"? do we preserve fs layout compatibility in some way? > Don't allow "recovered.edits" as legal family name > -- > > Key: HBASE-7108 > URL: https://issues.apache.org/jira/browse/HBASE-7108 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.92.2, 0.94.2, 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.96.0 > > Attachments: HBASE-7108-v0.patch > > > Region directories can contain a folder called "recovered.edits", log > splitting related. > But there's nothing that prevent a user to create a family with that name... -- 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-6793) Make hbase-examples module
[ https://issues.apache.org/jira/browse/HBASE-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491925#comment-13491925 ] Hudson commented on HBASE-6793: --- Integrated in HBase-TRUNK #3516 (See [https://builds.apache.org/job/HBase-TRUNK/3516/]) HBASE-6793 Make hbase-examples module (Revision 1406339) Result = FAILURE stack : Files : * /hbase/trunk/examples * /hbase/trunk/hbase-examples * /hbase/trunk/hbase-examples/README.txt * /hbase/trunk/hbase-examples/pom.xml * /hbase/trunk/hbase-examples/src * /hbase/trunk/hbase-examples/src/main * /hbase/trunk/hbase-examples/src/main/cpp * /hbase/trunk/hbase-examples/src/main/cpp/DemoClient.cpp * /hbase/trunk/hbase-examples/src/main/cpp/Makefile * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase.h * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_constants.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_constants.h * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_server.skeleton.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_types.cpp * /hbase/trunk/hbase-examples/src/main/cpp/gen-cpp/Hbase_types.h * /hbase/trunk/hbase-examples/src/main/java * /hbase/trunk/hbase-examples/src/main/java/org * /hbase/trunk/hbase-examples/src/main/java/org/apache * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce/IndexBuilder.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce/SampleUploader.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/DemoClient.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/AlreadyExists.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/BatchMutation.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/ColumnDescriptor.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/Hbase.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/IOError.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/IllegalArgument.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/Mutation.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TCell.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TIncrement.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TRegionInfo.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TRowResult.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/generated/TScan.java * /hbase/trunk/hbase-examples/src/main/perl * /hbase/trunk/hbase-examples/src/main/perl/DemoClient.pl * /hbase/trunk/hbase-examples/src/main/perl/gen-perl * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase/Constants.pm * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase/Hbase.pm * /hbase/trunk/hbase-examples/src/main/perl/gen-perl/Hbase/Types.pm * /hbase/trunk/hbase-examples/src/main/php * /hbase/trunk/hbase-examples/src/main/php/DemoClient.php * /hbase/trunk/hbase-examples/src/main/php/gen-php * /hbase/trunk/hbase-examples/src/main/php/gen-php/Hbase * /hbase/trunk/hbase-examples/src/main/php/gen-php/Hbase/Hbase.php * /hbase/trunk/hbase-examples/src/main/php/gen-php/Hbase/Types.php * /hbase/trunk/hbase-examples/src/main/python * /hbase/trunk/hbase-examples/src/main/python/DemoClient.py * /hbase/trunk/hbase-examples/src/main/python/gen-py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/Hbase-remote * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/Hbase.py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/__init__.py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/constants.py * /hbase/trunk/hbase-examples/src/main/python/gen-py/hbase/ttypes.py * /hbase/trunk/hbase-examples/src/main/ruby * /hbase/trunk/hbase-examples/src/main/ruby/DemoClient.rb * /hbase/trunk/hbase-examples/src/main/ruby/gen-rb * /hbase/trunk/hbase-examples/src/main/ruby/gen-rb/hbase.rb * /hbase/trunk/hbase-examples/src/main/ruby/gen-rb/hbase_constants.rb * /hbase/trunk/hbase-examples/src/main/ruby/g
[jira] [Updated] (HBASE-7108) Don't allow "recovered.edits" as legal family name
[ https://issues.apache.org/jira/browse/HBASE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-7108: --- Attachment: HBASE-7108-v0.patch added patch to mark "recovered.edits" as Illegal family name > Don't allow "recovered.edits" as legal family name > -- > > Key: HBASE-7108 > URL: https://issues.apache.org/jira/browse/HBASE-7108 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.92.2, 0.94.2, 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.96.0 > > Attachments: HBASE-7108-v0.patch > > > Region directories can contain a folder called "recovered.edits", log > splitting related. > But there's nothing that prevent a user to create a family with that name... -- 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-7108) Don't allow "recovered.edits" as legal family name
[ https://issues.apache.org/jira/browse/HBASE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491924#comment-13491924 ] Todd Lipcon commented on HBASE-7108: Instead of disallowing it, could we change recovered.edits to be something starting with a '.'? I think we already have some requirement that CFs not start with '.', right? (if not, is there any other prefix which we've already disallowed for users?) > Don't allow "recovered.edits" as legal family name > -- > > Key: HBASE-7108 > URL: https://issues.apache.org/jira/browse/HBASE-7108 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.92.2, 0.94.2, 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.96.0 > > Attachments: HBASE-7108-v0.patch > > > Region directories can contain a folder called "recovered.edits", log > splitting related. > But there's nothing that prevent a user to create a family with that name... -- 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-7108) Don't allow "recovered.edits" as legal family name
[ https://issues.apache.org/jira/browse/HBASE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-7108: --- Status: Patch Available (was: Open) > Don't allow "recovered.edits" as legal family name > -- > > Key: HBASE-7108 > URL: https://issues.apache.org/jira/browse/HBASE-7108 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.94.2, 0.92.2, 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.96.0 > > Attachments: HBASE-7108-v0.patch > > > Region directories can contain a folder called "recovered.edits", log > splitting related. > But there's nothing that prevent a user to create a family with that name... -- 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-7108) Don't allow "recovered.edits" as legal family name
Matteo Bertozzi created HBASE-7108: -- Summary: Don't allow "recovered.edits" as legal family name Key: HBASE-7108 URL: https://issues.apache.org/jira/browse/HBASE-7108 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.94.2, 0.92.2, 0.96.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Fix For: 0.96.0 Region directories can contain a folder called "recovered.edits", log splitting related. But there's nothing that prevent a user to create a family with that name... -- 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-7009) Port HBaseCluster interface/tests to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-7009: Attachment: HBASE-7009-v3-squashed.patch added proper class finder that seems to work with jars, refactor code out of a test class into separate classes > Port HBaseCluster interface/tests to 0.94 > - > > Key: HBASE-7009 > URL: https://issues.apache.org/jira/browse/HBASE-7009 > Project: HBase > Issue Type: Sub-task > Components: test >Affects Versions: 0.94.3 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Fix For: 0.94.4 > > Attachments: HBASE-7009-p1.patch, HBASE-7009.patch, > HBASE-7009-v2-squashed.patch, HBASE-7009-v3-squashed.patch > > > Need to port. I am porting V5 patch from the original JIRA; I have a > partially ported (V3) patch from Enis with protocol buffers being reverted to > HRegionInterface/HMasterInterface -- 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-6958) TestAssignmentManager sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491910#comment-13491910
]
Hadoop QA commented on HBASE-6958:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552340/trunk-6958.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
85 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 11 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/3234//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3234//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3234//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3234//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3234//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3234//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3234//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3234//console
This message is automatically generated.
> TestAssignmentManager sometimes fails
> -
>
> Key: HBASE-6958
> URL: https://issues.apache.org/jira/browse/HBASE-6958
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Ted Yu
>Assignee: Jimmy Xiang
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 6958_0.94.patch, trunk-6958.patch
>
>
> From
> https://builds.apache.org/job/HBase-TRUNK/3432/testReport/junit/org.apache.hadoop.hbase.master/TestAssignmentManager/testBalanceOnMasterFailoverScenarioWithOpenedNode/
> :
> {code}
> Stacktrace
> java.lang.Exception: test timed out after 5000 milliseconds
> at java.lang.System.arraycopy(Native Method)
> at java.lang.ThreadGroup.remove(ThreadGroup.java:969)
> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942)
> at java.lang.Thread.exit(Thread.java:732)
> ...
> 2012-10-06 00:46:12,521 DEBUG [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> zookeeper.ZKUtil(1141): mockedServer-0x13a33892de7000e Retrieved 81 byte(s)
> of data from znode /hbase/unassigned/dc01abf9cd7fd0ea256af4df02811640 and set
> watcher; region=t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.,
> state=M_ZK_REGION_OFFLINE, servername=master,1,1, createTime=1349484372509,
> payload.length=0
> 2012-10-06 00:46:12,522 ERROR [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> executor.EventHandler(205): Caught throwable while processing event
> RS_ZK_REGION_CLOSED
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$MockedLoadBalancer.randomAssignment(TestAssignmentManager.java:773)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1709)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1666)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1435)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1155)
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$AssignmentManagerWithExtrasForTesting.assign(TestAssignmentManager.java:1035)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1130)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1125)
> at
> org.apache.hadoop.hbase.master.handler.ClosedRegionHandler.process(ClosedRegionHandler.java:106)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(Eve
[jira] [Updated] (HBASE-7106) [89-fb] Fix the NPE in unit tests for JDK7
[ https://issues.apache.org/jira/browse/HBASE-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang updated HBASE-7106: -- Description: In JDK7, it will throw out NPE if put a NULL into a TreeSet. And in the unit tests, user can add a NULL as qualifier into the family map for GET or SCAN. So we shall do the followings: 1) Make sure the semantics of NULL column qualifier is equal to that of the EMPYT_BYTE_ARRAY column qualifier. 2) An easy fix is to use the EMPYT_BYTE_ARRAY qualifier to replace NULL qualifier in the family map for the GET or SCAN objects, and everything else shall be backward compatible. 3) Add a jdk option in the pom.xml (Assuming user installed the fb packaged jdk) eg: mvn test -Dtest=TestFromClientSide -Pjdk7 was: In JDK7, it will throw out NPE if put a NULL into a TreeSet. And in the unit tests, user can add a NULL as qualifier into the family map for GET or SCAN. So we shall do the followings: 1) Make sure the semantics of NULL column qualifier is equal to that of the EMPYT_BYTE_ARRAY column qualifier. 2) An easy fix is to use the EMPYT_BYTE_ARRAY qualifier to replace NULL qualifier in the family map for the GET or SCAN objects, and everything else shall be backward compatible. 3) Add a jdk option in the pom.xml (Assuming user install the fb packaged jdk) eg: mvn test -Dtest=TestFromClientSide -Pjdk7 > [89-fb] Fix the NPE in unit tests for JDK7 > -- > > Key: HBASE-7106 > URL: https://issues.apache.org/jira/browse/HBASE-7106 > Project: HBase > Issue Type: Improvement >Reporter: Liyin Tang >Priority: Trivial > > In JDK7, it will throw out NPE if put a NULL into a TreeSet. And in the unit > tests, user can add a NULL as qualifier into the family map for GET or SCAN. > So we shall do the followings: > 1) Make sure the semantics of NULL column qualifier is equal to that of the > EMPYT_BYTE_ARRAY column qualifier. > 2) An easy fix is to use the EMPYT_BYTE_ARRAY qualifier to replace NULL > qualifier in the family map for the GET or SCAN objects, and everything else > shall be backward compatible. > 3) Add a jdk option in the pom.xml (Assuming user installed the fb packaged > jdk) > eg: mvn test -Dtest=TestFromClientSide -Pjdk7 -- 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-7106) [89-fb] Fix the NPE in unit tests for JDK7
[ https://issues.apache.org/jira/browse/HBASE-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liyin Tang updated HBASE-7106: -- Description: In JDK7, it will throw out NPE if put a NULL into a TreeSet. And in the unit tests, user can add a NULL as qualifier into the family map for GET or SCAN. So we shall do the followings: 1) Make sure the semantics of NULL column qualifier is equal to that of the EMPYT_BYTE_ARRAY column qualifier. 2) An easy fix is to use the EMPYT_BYTE_ARRAY qualifier to replace NULL qualifier in the family map for the GET or SCAN objects, and everything else shall be backward compatible. 3) Add a jdk option in the pom.xml (Assuming user install the fb packaged jdk) eg: mvn test -Dtest=TestFromClientSide -Pjdk7 was:In JDK7, it will throw out NPE if put a NULL into a TreeSet. So the easy fix is to skip putting the NULL qualifier into the family map for the GET and SCAN objects, and everything else shall be backward compatible. > [89-fb] Fix the NPE in unit tests for JDK7 > -- > > Key: HBASE-7106 > URL: https://issues.apache.org/jira/browse/HBASE-7106 > Project: HBase > Issue Type: Improvement >Reporter: Liyin Tang >Priority: Trivial > > In JDK7, it will throw out NPE if put a NULL into a TreeSet. And in the unit > tests, user can add a NULL as qualifier into the family map for GET or SCAN. > So we shall do the followings: > 1) Make sure the semantics of NULL column qualifier is equal to that of the > EMPYT_BYTE_ARRAY column qualifier. > 2) An easy fix is to use the EMPYT_BYTE_ARRAY qualifier to replace NULL > qualifier in the family map for the GET or SCAN objects, and everything else > shall be backward compatible. > 3) Add a jdk option in the pom.xml (Assuming user install the fb packaged jdk) > eg: mvn test -Dtest=TestFromClientSide -Pjdk7 -- 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-7107) Snapshot References Utils (FileSystem Visitor)
[ https://issues.apache.org/jira/browse/HBASE-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-7107: --- Status: Patch Available (was: Open) > Snapshot References Utils (FileSystem Visitor) > -- > > Key: HBASE-7107 > URL: https://issues.apache.org/jira/browse/HBASE-7107 > Project: HBase > Issue Type: Sub-task > Components: snapshots >Affects Versions: 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.96.0 > > > Utils to traverse the table and snapshot directory. > Used by Restore and Export and should be used by cleaner, and other that want > to look inside the snapshot folder. > It provides an abstraction to the "snapshot metadata" format, and allows to > get information about files, logs and recovered.edits snapshotted. -- 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-7107) Snapshot References Utils (FileSystem Visitor)
[ https://issues.apache.org/jira/browse/HBASE-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491894#comment-13491894 ] Matteo Bertozzi commented on HBASE-7107: Review is here: https://reviews.apache.org/r/7788/ > Snapshot References Utils (FileSystem Visitor) > -- > > Key: HBASE-7107 > URL: https://issues.apache.org/jira/browse/HBASE-7107 > Project: HBase > Issue Type: Sub-task > Components: snapshots >Affects Versions: 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: hbase-6055 > > > Utils to traverse the table and snapshot directory. > Used by Restore and Export and should be used by cleaner, and other that want > to look inside the snapshot folder. > It provides an abstraction to the "snapshot metadata" format, and allows to > get information about files, logs and recovered.edits snapshotted. -- 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-7107) Snapshot References Utils (FileSystem Visitor)
[ https://issues.apache.org/jira/browse/HBASE-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-7107: --- Fix Version/s: (was: 0.96.0) hbase-6055 > Snapshot References Utils (FileSystem Visitor) > -- > > Key: HBASE-7107 > URL: https://issues.apache.org/jira/browse/HBASE-7107 > Project: HBase > Issue Type: Sub-task > Components: snapshots >Affects Versions: 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: hbase-6055 > > > Utils to traverse the table and snapshot directory. > Used by Restore and Export and should be used by cleaner, and other that want > to look inside the snapshot folder. > It provides an abstraction to the "snapshot metadata" format, and allows to > get information about files, logs and recovered.edits snapshotted. -- 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-7107) Snapshot References Utils (FileSystem Visitor)
Matteo Bertozzi created HBASE-7107: -- Summary: Snapshot References Utils (FileSystem Visitor) Key: HBASE-7107 URL: https://issues.apache.org/jira/browse/HBASE-7107 Project: HBase Issue Type: Sub-task Components: snapshots Affects Versions: 0.96.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Fix For: 0.96.0 Utils to traverse the table and snapshot directory. Used by Restore and Export and should be used by cleaner, and other that want to look inside the snapshot folder. It provides an abstraction to the "snapshot metadata" format, and allows to get information about files, logs and recovered.edits snapshotted. -- 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-6958) TestAssignmentManager sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491892#comment-13491892
]
Ted Yu commented on HBASE-6958:
---
+1 on patch for 0.94
Looped TestAssignmentManager 8 times locally with the patch and they passed.
> TestAssignmentManager sometimes fails
> -
>
> Key: HBASE-6958
> URL: https://issues.apache.org/jira/browse/HBASE-6958
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Ted Yu
>Assignee: Jimmy Xiang
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 6958_0.94.patch, trunk-6958.patch
>
>
> From
> https://builds.apache.org/job/HBase-TRUNK/3432/testReport/junit/org.apache.hadoop.hbase.master/TestAssignmentManager/testBalanceOnMasterFailoverScenarioWithOpenedNode/
> :
> {code}
> Stacktrace
> java.lang.Exception: test timed out after 5000 milliseconds
> at java.lang.System.arraycopy(Native Method)
> at java.lang.ThreadGroup.remove(ThreadGroup.java:969)
> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942)
> at java.lang.Thread.exit(Thread.java:732)
> ...
> 2012-10-06 00:46:12,521 DEBUG [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> zookeeper.ZKUtil(1141): mockedServer-0x13a33892de7000e Retrieved 81 byte(s)
> of data from znode /hbase/unassigned/dc01abf9cd7fd0ea256af4df02811640 and set
> watcher; region=t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.,
> state=M_ZK_REGION_OFFLINE, servername=master,1,1, createTime=1349484372509,
> payload.length=0
> 2012-10-06 00:46:12,522 ERROR [MASTER_CLOSE_REGION-mockedAMExecutor-0]
> executor.EventHandler(205): Caught throwable while processing event
> RS_ZK_REGION_CLOSED
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$MockedLoadBalancer.randomAssignment(TestAssignmentManager.java:773)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1709)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.getRegionPlan(AssignmentManager.java:1666)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1435)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1155)
> at
> org.apache.hadoop.hbase.master.TestAssignmentManager$AssignmentManagerWithExtrasForTesting.assign(TestAssignmentManager.java:1035)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1130)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.assign(AssignmentManager.java:1125)
> at
> org.apache.hadoop.hbase.master.handler.ClosedRegionHandler.process(ClosedRegionHandler.java:106)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2012-10-06 00:46:12,522 DEBUG [pool-1-thread-1-EventThread]
> master.AssignmentManager(670): Handling transition=M_ZK_REGION_OFFLINE,
> server=master,1,1, region=dc01abf9cd7fd0ea256af4df02811640, current state
> from region state map ={t,,1349484359011.dc01abf9cd7fd0ea256af4df02811640.
> state=OFFLINE, ts=1349484372508, server=null}
> {code}
> Looks like NPE happened on this line:
> {code}
> this.gate.set(true);
> {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-tabpanel&focusedCommentId=13491884#comment-13491884 ] Lars Hofhansl commented on HBASE-4583: -- As I said I'm fine with the "less radical" patch :) Increments are special in they are only useful when updating something existing. > 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-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] [Created] (HBASE-7106) [89-fb] Fix the NPE in unit tests for JDK7
Liyin Tang created HBASE-7106: - Summary: [89-fb] Fix the NPE in unit tests for JDK7 Key: HBASE-7106 URL: https://issues.apache.org/jira/browse/HBASE-7106 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Priority: Trivial In JDK7, it will throw out NPE if put a NULL into a TreeSet. So the easy fix is to skip putting the NULL qualifier into the family map for the GET and SCAN objects, and everything else shall be backward compatible. -- 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-7055) port HBASE-6371 tier-based compaction from 0.89-fb to trunk
[ https://issues.apache.org/jira/browse/HBASE-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491880#comment-13491880 ] Sergey Shelukhin commented on HBASE-7055: - already renamed in the recent patch > port HBASE-6371 tier-based compaction from 0.89-fb to trunk > --- > > Key: HBASE-7055 > URL: https://issues.apache.org/jira/browse/HBASE-7055 > Project: HBase > Issue Type: Task > Components: Compaction >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Fix For: 0.96.0 > > Attachments: HBASE-6371-squashed.patch, HBASE-6371-v2-squashed.patch, > HBASE-6371-v3-refactor-only-squashed.patch, > HBASE-6371-v4-refactor-only-squashed.patch, > HBASE-6371-v5-refactor-only-squashed.patch > > > There's divergence in the code :( > See HBASE-6371 for details. -- 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-7047) [snapshots] Refactor error handling to use javax.management
[ https://issues.apache.org/jira/browse/HBASE-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491875#comment-13491875 ] Jonathan Hsieh commented on HBASE-7047: --- I agree. Let's get the nits taken care of on the offline snapshots, commit, and then file some follow on jiras for the remaining issues. > [snapshots] Refactor error handling to use javax.management > --- > > Key: HBASE-7047 > URL: https://issues.apache.org/jira/browse/HBASE-7047 > Project: HBase > Issue Type: Sub-task > Components: Client, master, regionserver, snapshots, Zookeeper >Affects Versions: hbase-6055 >Reporter: Jesse Yates >Assignee: Jesse Yates > Fix For: hbase-6055 > > Attachments: hbase-7047-v0-adv.patch, hbase-7047-v0.patch > > > The current error handling framework introduced in HBASE-6571 adds a lot of > complexity for what is essentially a solved problem. Specifically, > cross-thread notifications have been generalized for the JMX tooling in the > javax.management classes. > Similar to what we developed, they have a NotifciationBroadcaster, > NotificationListener, etc. though these are interfaces rather than general > classes. These javax classes can be used almost 1-to-1 as replacements for > things like the ExceptionOrchestrator and ExceptionListener. This also gives > us the opportunity to easily add primitive notifications for standard HBase > things like (1) timeouts, (2) aborts, and (3) server stops since the > framework already considers things like typed notifications. -- 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-tabpanel&focusedCommentId=13491871#comment-13491871 ] Jonathan Gray commented on HBASE-4583: -- My vote (if only for one implementation) would be for the less radical patch that removes in-memory versions that are not visible rather than doing this cleanup on flush which has a number of performance implications. I can see some reasons for wanting to keep versions around (providing support to an Omid-like transaction engine requires retaining old versions for at least some time), but it would be cool to have an option to prevent the deletion of the old versions rather than require that these exist in cases I won't ever use them. In all my increment performance tests, of which there have been many, the upsert/removal of old versions is one of the biggest gains, especially if you have particularly hot columns. I'm not sure which design you are referring to when you talk about being true to HBase's design ;) Or maybe you're referring to the general principles of HBase (append-only), but the increment operation itself was not part of any original design or implementation of HBase and has been a hack in one way or another from the very first implementation. For the reason that the implementation has been targeted at performance over purity. I've always seen it as an atomic operation that would have any notion of versioning as opaque to the user of the atomic increment. Again, I can see use cases for it, but I'd lean towards having it as an option rather than requirement. Thanks for doing this work, good stuff. +1 > 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-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-6353) Snapshots shell
[
https://issues.apache.org/jira/browse/HBASE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491869#comment-13491869
]
Hadoop QA commented on HBASE-6353:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12551976/snapshot-offline-test-demo.shell
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/3236//console
This message is automatically generated.
> Snapshots shell
> ---
>
> Key: HBASE-6353
> URL: https://issues.apache.org/jira/browse/HBASE-6353
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-6353-v0.patch, HBASE-6353-v1.patch,
> snapshot-offline-test-demo.shell
>
>
> h6. hbase shell with snapshot commands
> * snapshot
> ** Take a snapshot of the specified name with the specified name
> * restore_snapshot
> ** Restore specified snapshot on the original table
> * clone_snapshot
> ** Create a new table based on the snapshot content
> * list_snapshots [filter]
> ** Show the list of snapshots taken
> * delete_snapshot
> ** Remove a specified snapshot
> * rename_snapshot
> ** Rename a snapshot to a new name
> h6. Restore Table
> Given a "snapshot name" restore override the original table with the snapshot
> content.
> Before restoring a new snapshot of the table is taken, just to avoid bad
> situations.
> This allows a full and quick rollback to a previous snapshot.
> h6. Clone from Snapshot
> Given a "snapshot name" a new table is created with the content of the
> specified snapshot.
> This operation allows:
> * To have an old version of the table in parallel with the current one.
> ** Look at snapshot side-by-side with the "current" before making the
> decision whether to roll back or not
> * To Add/Remove data from this table without affecting the original one or
> the snapshot.
> * To Restore only "individual items" (only some small range of data was lost
> from "current")
> ** MR job that scan the cloned table and update the data in the original
> one. (Partial restore of the data)
> h6. Open points
> * Add snapshot type option on take snapshot command (global, timestamp)?
--
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-6865) Snapshot File Cleaners
[ https://issues.apache.org/jira/browse/HBASE-6865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-6865: -- Status: Patch Available (was: Open) > Snapshot File Cleaners > -- > > Key: HBASE-6865 > URL: https://issues.apache.org/jira/browse/HBASE-6865 > Project: HBase > Issue Type: Sub-task >Reporter: Jesse Yates >Assignee: Jesse Yates > Fix For: hbase-6055 > > > HFile and HLog cleaners are necessary for fully implementing snapshots, but > can be broken out into their own piece really cleanly. The HFile cleaner is > necessary for both timestamp and globally consistent snapshots, but the HLog > cleaner is necessary for globally consistent and offline snapshots. > Putting everything together in one patch isn't too much overload as there is > a lot of overlap between the cleaners. -- 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-6777) Snapshot Restore interface
[ https://issues.apache.org/jira/browse/HBASE-6777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-6777: -- Status: Patch Available (was: Open) > Snapshot Restore interface > -- > > Key: HBASE-6777 > URL: https://issues.apache.org/jira/browse/HBASE-6777 > Project: HBase > Issue Type: Sub-task > Components: Client, master, snapshots >Affects Versions: 0.96.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: hbase-6055 > > > Add interfaces for restoring a snapshot -- 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-6802) Export Snapshot
[ https://issues.apache.org/jira/browse/HBASE-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-6802: -- Status: Patch Available (was: Open) > Export Snapshot > --- > > Key: HBASE-6802 > URL: https://issues.apache.org/jira/browse/HBASE-6802 > Project: HBase > Issue Type: Sub-task > Components: snapshots >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: hbase-6055, 0.96.0 > > > Export a snapshot to another cluster. > - Copy the .snapshot/name folder with all the references > - Copy the hfiles/hlogs needed by the snapshot > Once the other cluster has the files and the snapshot information it can > restore the snapshot. -- 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-6863) Offline snapshots
[ https://issues.apache.org/jira/browse/HBASE-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-6863: -- Status: Patch Available (was: Open) > Offline snapshots > - > > Key: HBASE-6863 > URL: https://issues.apache.org/jira/browse/HBASE-6863 > Project: HBase > Issue Type: Sub-task >Reporter: Jesse Yates >Assignee: Jesse Yates > Fix For: hbase-6055 > > > Create a snapshot of a table while the table is offline. This also should > handle a lot of the common utils/scaffolding for taking snapshots > (HBASE-6055) with minimal overhead as the code itself is pretty simple. -- 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-7097) Log message in SecureServer.class uses wrong class name
[
https://issues.apache.org/jira/browse/HBASE-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491865#comment-13491865
]
Lars Hofhansl commented on HBASE-7097:
--
I think this looks reasonable.
Should we leave the "SecurityEnabled" message?
I have no good sense about how frequently
{code}
if (LOG.isDebugEnabled())
LOG.debug("Created SASL server with mechanism = "
+ authMethod.getMechanismName());
{code}
or
{code}
if (LOG.isDebugEnabled())
LOG.debug("Kerberos principal name is " + fullName);
{code}
Would called, but I think it should be OK to leave those at DEBUG.
> Log message in SecureServer.class uses wrong class name
> ---
>
> Key: HBASE-7097
> URL: https://issues.apache.org/jira/browse/HBASE-7097
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.92.2, 0.94.2
>Reporter: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 0.92.3, 0.94.3
>
> Attachments: HBASE-7097_94.patch, HBASE-7097-addendum.patch
>
>
> log messages are printing wrongly in
> org.apache.hadoop.hbase.ipc.SecureServer.class
> {code}
> public static final Log LOG =
> LogFactory.getLog("org.apache.hadoop.ipc.SecureServer");
> private static final Log AUDITLOG =
> LogFactory.getLog("SecurityLogger.org.apache.hadoop.ipc.SecureServer");
> {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-6865) Snapshot File Cleaners
[ https://issues.apache.org/jira/browse/HBASE-6865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491864#comment-13491864 ] Jonathan Hsieh commented on HBASE-6865: --- (Oops, there was a point 3 but it got folded into one of the others). [~te...@apache.org] Take a look at this link and some of the comments around it and its analog. https://reviews.apache.org/r/7627/diff/2/?file=183690#file183690line64 Setters conventionally don't io, doesn't start threads, and can be called anytime in the lifecycle of an object. In the code in this patch, the conf being is more like part of a constructor or a thread start method. Specifically, it instantiates a cache object that has a thread. Hm.. I should have asked why it wasn't in the constructor -- I'll add that to the review. > Snapshot File Cleaners > -- > > Key: HBASE-6865 > URL: https://issues.apache.org/jira/browse/HBASE-6865 > Project: HBase > Issue Type: Sub-task >Reporter: Jesse Yates >Assignee: Jesse Yates > Fix For: hbase-6055 > > > HFile and HLog cleaners are necessary for fully implementing snapshots, but > can be broken out into their own piece really cleanly. The HFile cleaner is > necessary for both timestamp and globally consistent snapshots, but the HLog > cleaner is necessary for globally consistent and offline snapshots. > Putting everything together in one patch isn't too much overload as there is > a lot of overlap between the cleaners. -- 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-6353) Snapshots shell
[
https://issues.apache.org/jira/browse/HBASE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491862#comment-13491862
]
Hadoop QA commented on HBASE-6353:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12551976/snapshot-offline-test-demo.shell
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/3235//console
This message is automatically generated.
> Snapshots shell
> ---
>
> Key: HBASE-6353
> URL: https://issues.apache.org/jira/browse/HBASE-6353
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-6353-v0.patch, HBASE-6353-v1.patch,
> snapshot-offline-test-demo.shell
>
>
> h6. hbase shell with snapshot commands
> * snapshot
> ** Take a snapshot of the specified name with the specified name
> * restore_snapshot
> ** Restore specified snapshot on the original table
> * clone_snapshot
> ** Create a new table based on the snapshot content
> * list_snapshots [filter]
> ** Show the list of snapshots taken
> * delete_snapshot
> ** Remove a specified snapshot
> * rename_snapshot
> ** Rename a snapshot to a new name
> h6. Restore Table
> Given a "snapshot name" restore override the original table with the snapshot
> content.
> Before restoring a new snapshot of the table is taken, just to avoid bad
> situations.
> This allows a full and quick rollback to a previous snapshot.
> h6. Clone from Snapshot
> Given a "snapshot name" a new table is created with the content of the
> specified snapshot.
> This operation allows:
> * To have an old version of the table in parallel with the current one.
> ** Look at snapshot side-by-side with the "current" before making the
> decision whether to roll back or not
> * To Add/Remove data from this table without affecting the original one or
> the snapshot.
> * To Restore only "individual items" (only some small range of data was lost
> from "current")
> ** MR job that scan the cloned table and update the data in the original
> one. (Partial restore of the data)
> h6. Open points
> * Add snapshot type option on take snapshot command (global, timestamp)?
--
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-6353) Snapshots shell
[ https://issues.apache.org/jira/browse/HBASE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-6353: -- Hadoop Flags: Reviewed Status: Patch Available (was: Open) > Snapshots shell > --- > > Key: HBASE-6353 > URL: https://issues.apache.org/jira/browse/HBASE-6353 > Project: HBase > Issue Type: Sub-task > Components: shell >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Attachments: HBASE-6353-v0.patch, HBASE-6353-v1.patch, > snapshot-offline-test-demo.shell > > > h6. hbase shell with snapshot commands > * snapshot > ** Take a snapshot of the specified name with the specified name > * restore_snapshot > ** Restore specified snapshot on the original table > * clone_snapshot > ** Create a new table based on the snapshot content > * list_snapshots [filter] > ** Show the list of snapshots taken > * delete_snapshot > ** Remove a specified snapshot > * rename_snapshot > ** Rename a snapshot to a new name > h6. Restore Table > Given a "snapshot name" restore override the original table with the snapshot > content. > Before restoring a new snapshot of the table is taken, just to avoid bad > situations. > This allows a full and quick rollback to a previous snapshot. > h6. Clone from Snapshot > Given a "snapshot name" a new table is created with the content of the > specified snapshot. > This operation allows: > * To have an old version of the table in parallel with the current one. > ** Look at snapshot side-by-side with the "current" before making the > decision whether to roll back or not > * To Add/Remove data from this table without affecting the original one or > the snapshot. > * To Restore only "individual items" (only some small range of data was lost > from "current") > ** MR job that scan the cloned table and update the data in the original > one. (Partial restore of the data) > h6. Open points > * Add snapshot type option on take snapshot command (global, timestamp)? -- 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-6353) Snapshots shell
[ https://issues.apache.org/jira/browse/HBASE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491858#comment-13491858 ] Jonathan Hsieh commented on HBASE-6353: --- Jesse, where do we stand on this? Do we need more or is this good to go? > Snapshots shell > --- > > Key: HBASE-6353 > URL: https://issues.apache.org/jira/browse/HBASE-6353 > Project: HBase > Issue Type: Sub-task > Components: shell >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Attachments: HBASE-6353-v0.patch, HBASE-6353-v1.patch, > snapshot-offline-test-demo.shell > > > h6. hbase shell with snapshot commands > * snapshot > ** Take a snapshot of the specified name with the specified name > * restore_snapshot > ** Restore specified snapshot on the original table > * clone_snapshot > ** Create a new table based on the snapshot content > * list_snapshots [filter] > ** Show the list of snapshots taken > * delete_snapshot > ** Remove a specified snapshot > * rename_snapshot > ** Rename a snapshot to a new name > h6. Restore Table > Given a "snapshot name" restore override the original table with the snapshot > content. > Before restoring a new snapshot of the table is taken, just to avoid bad > situations. > This allows a full and quick rollback to a previous snapshot. > h6. Clone from Snapshot > Given a "snapshot name" a new table is created with the content of the > specified snapshot. > This operation allows: > * To have an old version of the table in parallel with the current one. > ** Look at snapshot side-by-side with the "current" before making the > decision whether to roll back or not > * To Add/Remove data from this table without affecting the original one or > the snapshot. > * To Restore only "individual items" (only some small range of data was lost > from "current") > ** MR job that scan the cloned table and update the data in the original > one. (Partial restore of the data) > h6. Open points > * Add snapshot type option on take snapshot command (global, timestamp)? -- 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-tabpanel&focusedCommentId=13491854#comment-13491854 ] Lars Hofhansl commented on HBASE-4583: -- [~saint@gmail.com] That's what the less radical patch does, it removed old versions of the KVs when they are no longer visible to concurrent scanners. You cannot clean up the in memory KVs (without a lot of refactoring and repacking into new slabs) while still using mslab. There was talk about in memory compactions that could something like this... If we consider this an issue then that would be the proper route. Let me try to summarize: # The "less radical" patch is correct w.r.t. to MVCC. It does not correct the Increment behavior when it comes to historical scans. For practical purposes there is only a single version of the Incremented column, which is changed - regardless of how the CF is configured. # The "radical" removes upsert. Increments are just treated like Puts, all special code is removed. Upon flush all excess versions are removed before they are flushed to disk (HBASE-4241). The flushed files will be small, compaction will be fast. No attempt is made to clean up KVs before that, so it works with mslab, but the memstore will fill up more quickly. This patch causes a 10-15% performance degradation for pure Increments. As I stated before, in my mind only the "radical" version is true to HBase's design and upsert was a hack, which should be removed. However, I'm fine committing the "less radical" version, which retains (mostly) the current performance and fixes the behavior w.r.t. MVCC. > 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-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-6338) Cache Method in RPC handler
[ https://issues.apache.org/jira/browse/HBASE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491851#comment-13491851 ] Devaraj Das commented on HBASE-6338: On trunk (0.96), the ProtobufRpcEngine already does keep a similar mapping of methodname to Method objects.. > Cache Method in RPC handler > --- > > Key: HBASE-6338 > URL: https://issues.apache.org/jira/browse/HBASE-6338 > Project: HBase > Issue Type: Improvement >Reporter: binlijin > Attachments: HBASE-6338-90-2.patch, HBASE-6338-90.patch, > HBASE-6338-92-2.patch, HBASE-6338-92.patch, HBASE-6338-94-2.patch, > HBASE-6338-94.patch, HBASE-6338-trunk-2.patch, HBASE-6338-trunk.patch > > > Every call in rpc handler a Method will be created, if we cache the method > will improve a little. > I test with 0.90, Average Class.getMethod(String name, Class... > parameterTypes) cost 4780 ns , if we cache it cost 2620 ns. -- 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
