[jira] [Commented] (HBASE-13242) TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
[
https://issues.apache.org/jira/browse/HBASE-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361635#comment-14361635
]
Hadoop QA commented on HBASE-13242:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704571/HBASE-13242.patch
against master branch at commit 72855c584e53173471c44a284ef2e839b6f31564.
ATTACHMENT ID: 12704571
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ assertEquals(DefaultMemStore.DEEP_OVERHEAD,
desiredRegion.getStore(FAMILY1).getMemStoreSize());
+ assertEquals(DefaultMemStore.DEEP_OVERHEAD,
desiredRegion.getStore(FAMILY2).getMemStoreSize());
+ assertEquals(DefaultMemStore.DEEP_OVERHEAD,
desiredRegion.getStore(FAMILY3).getMemStoreSize());
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.hadoop.hbase.http.TestHttpServerLifecycle.testStartedServerIsAlive(TestHttpServerLifecycle.java:71)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13242//console
This message is automatically generated.
> TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
>
>
> Key: HBASE-13242
> URL: https://issues.apache.org/jira/browse/HBASE-13242
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: zhangduo
>Assignee: zhangduo
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13242.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361634#comment-14361634
]
Hudson commented on HBASE-13236:
FAILURE: Integrated in HBase-0.98 #899 (See
[https://builds.apache.org/job/HBase-0.98/899/])
HBASE-13236 Add addt'l lifecycle-mapping executions. (busbey: rev
8f034815f661469d258618efde393366a36a27e5)
* hbase-examples/pom.xml
* pom.xml
* hbase-it/pom.xml
* hbase-hadoop2-compat/pom.xml
* hbase-server/pom.xml
* hbase-rest/pom.xml
* hbase-shell/pom.xml
* hbase-prefix-tree/pom.xml
* hbase-client/pom.xml
* hbase-common/pom.xml
* hbase-thrift/pom.xml
* hbase-hadoop-compat/pom.xml
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: HBASE-13236-master.patch, HBASE-13236-v1.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361633#comment-14361633
]
Hudson commented on HBASE-13236:
FAILURE: Integrated in HBase-TRUNK #6259 (See
[https://builds.apache.org/job/HBase-TRUNK/6259/])
HBASE-13236 Add addt'l lifecycle-mapping executions. (busbey: rev
72855c584e53173471c44a284ef2e839b6f31564)
* hbase-client/pom.xml
* hbase-server/pom.xml
* hbase-it/pom.xml
* hbase-examples/pom.xml
* hbase-prefix-tree/pom.xml
* hbase-hadoop2-compat/pom.xml
* hbase-shell/pom.xml
* pom.xml
* hbase-common/pom.xml
* hbase-thrift/pom.xml
* hbase-rest/pom.xml
* hbase-hadoop-compat/pom.xml
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: HBASE-13236-master.patch, HBASE-13236-v1.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-13236:
Resolution: Fixed
Fix Version/s: 0.98.12
1.0.1
Status: Resolved (was: Patch Available)
Pushed to 0.98+. Thanks Josh!
For future reference, we usually only wrap at 100.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: HBASE-13236-master.patch, HBASE-13236-v1.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361621#comment-14361621 ] Sean Busbey commented on HBASE-13239: - sounds like we're good to go then. > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13223) Add testMoveMeta to IntegrationTestMTTR
[ https://issues.apache.org/jira/browse/HBASE-13223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361618#comment-14361618 ] Elliott Clark commented on HBASE-13223: --- +1 lgtm > Add testMoveMeta to IntegrationTestMTTR > --- > > Key: HBASE-13223 > URL: https://issues.apache.org/jira/browse/HBASE-13223 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Dima Spivak >Assignee: Dima Spivak > Attachments: HBASE-13223_master_v1.patch > > > It would be nice to add a new test case to IntegrationTestMTTR that would > trigger a move of the regions of hbase:meta and evaluate the MTTR in the > aftermath. Pretty straightforward addition to the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361616#comment-14361616
]
Jerry He commented on HBASE-13239:
--
Tested the cell ACL with groups. Works wonderfully.
As 'user1'
{code}
hbase(main):014:0> scan 'table1'
ROW COLUMN+CELL
0 row(s) in 0.3340 seconds
{code}
As 'admin'
{code}
hbase(main):032:0> grant 'table1', {'@users' => 'RW'}, {FILTER =>
"(PrefixFilter ('r'))"}
3 row(s) in 0.0240 seconds
{code}
As 'user1'
{code}
hbase(main):015:0> scan 'table1'
ROW COLUMN+CELL
r1 column=family:c1, timestamp=1426311391957,
value=value1
r2 column=family:c1, timestamp=1426311399390,
value=value2
r3 column=family:c1, timestamp=1426311405686,
value=value3
3 row(s) in 0.0200 seconds
{code}
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt, 13239-v2.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific user and scan the table. It produces correct
> results, i.e. provides only the column where user has select privileges
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13242) TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
[ https://issues.apache.org/jira/browse/HBASE-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangduo updated HBASE-13242: - Attachment: HBASE-13242.patch > TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung > > > Key: HBASE-13242 > URL: https://issues.apache.org/jira/browse/HBASE-13242 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0, 1.1.0 >Reporter: zhangduo >Assignee: zhangduo > Fix For: 2.0.0, 1.1.0 > > Attachments: HBASE-13242.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13242) TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
[ https://issues.apache.org/jira/browse/HBASE-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangduo updated HBASE-13242: - Fix Version/s: 1.1.0 2.0.0 Status: Patch Available (was: Open) Try. > TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung > > > Key: HBASE-13242 > URL: https://issues.apache.org/jira/browse/HBASE-13242 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0, 1.1.0 >Reporter: zhangduo >Assignee: zhangduo > Fix For: 2.0.0, 1.1.0 > > Attachments: HBASE-13242.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13242) TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
[
https://issues.apache.org/jira/browse/HBASE-13242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361611#comment-14361611
]
zhangduo commented on HBASE-13242:
--
https://builds.apache.org/job/PreCommit-HBASE-Build/13240/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.regionserver.TestPerColumnFamilyFlush-output.txt
(125.64 MB, Do NOT open it directly in browser)
The testcase hangs after print this
{noformat}
2015-03-14 02:22:49,779 INFO [Thread-748]
regionserver.TestPerColumnFamilyFlush(481): The number of log files is now: 11.
Expect a log roll and memstore flush.
{noformat}
The code is here, we are waiting the number of log files fall below the max
logs limit.
{code:title=TestPerColumnFamilyFlush.java}
// Wait for some time till the flush caused by log rolling happens.
while (((FSHLog) (desiredRegion.getWAL())).getNumLogFiles() > maxLogs)
Threads.sleep(100);
{code}
Here we use 'getNumLogFiles', but in findRegionsToForceFlush we use
'getNumRolledLogFiles', see the implementation of 'getNumLogFiles'
{code:title=FSHLog.java}
// public only until class moves to o.a.h.h.wal
/** @return the number of log files in use */
public int getNumLogFiles() {
// +1 for current use log
return getNumRolledLogFiles() + 1;
}
{code}
So it is possible that we enter an infinite loop here because of the '+1'...
Will prepare a patch soon...
> TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
>
>
> Key: HBASE-13242
> URL: https://issues.apache.org/jira/browse/HBASE-13242
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: zhangduo
>Assignee: zhangduo
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13242) TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
zhangduo created HBASE-13242: Summary: TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung Key: HBASE-13242 URL: https://issues.apache.org/jira/browse/HBASE-13242 Project: HBase Issue Type: Bug Components: test Affects Versions: 2.0.0, 1.1.0 Reporter: zhangduo Assignee: zhangduo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[ https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361605#comment-14361605 ] Hudson commented on HBASE-13237: SUCCESS: Integrated in HBase-TRUNK #6258 (See [https://builds.apache.org/job/HBase-TRUNK/6258/]) HBASE-13237 Improve trademark marks on the hbase.apache.org homepage (apurtell: rev 2f43da0a7da879c0beb124c61d0ab8ca00f36df4) * src/main/site/xdoc/index.xml > Improve trademark marks on the hbase.apache.org homepage > > > Key: HBASE-13237 > URL: https://issues.apache.org/jira/browse/HBASE-13237 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13237.patch, screenshot.png > > > Ensure trademark marks are next to first and prominent uses of "HBase" on the > hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13109) Make better SEEK vs SKIP decisions during scanning
[ https://issues.apache.org/jira/browse/HBASE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361604#comment-14361604 ] James Taylor commented on HBASE-13109: -- I believe this essentially breaks all existing 4.x Phoenix releases (at a minimum, it would break mutable and local secondary indexes). The only way Phoenix users will be able to use 0.98.12+ is to wait for the next Phoenix release and upgrade to that one (at a minimum on the server side). Not sure if this is a problem for the user community. > Make better SEEK vs SKIP decisions during scanning > -- > > Key: HBASE-13109 > URL: https://issues.apache.org/jira/browse/HBASE-13109 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13109-0.98-v4.txt, 13109-trunk-v2.txt, > 13109-trunk-v3.txt, 13109-trunk-v4.txt, 13109-trunk-v5.txt, 13109-trunk.txt, > nextIndexKVChange_new.patch > > > I'm re-purposing this issue to add a heuristic as to when to SEEK and when to > SKIP Cells. This has come up in various issues, and I think I have a way to > finally fix this now. HBASE-9778, HBASE-12311, and friends are related. > --- Old description --- > This is a continuation of HBASE-9778. > We've seen a scenario of a very slow scan over a region using a timerange > that happens to fall after the ts of any Cell in the region. > Turns out we spend a lot of time seeking. > Tested with a 5 column table, and the scan is 5x faster when the timerange > falls before all Cells' ts. > We can use the lookahead hint introduced in HBASE-9778 to do opportunistic > SKIPing before we actually seek. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13219) Issues with PE tool in trunk
[
https://issues.apache.org/jira/browse/HBASE-13219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361603#comment-14361603
]
ramkrishna.s.vasudevan commented on HBASE-13219:
Ya sure. I Wil check this out. Excuse typos.
> Issues with PE tool in trunk
>
>
> Key: HBASE-13219
> URL: https://issues.apache.org/jira/browse/HBASE-13219
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Attachments: 13219.txt, t1
>
>
> -> PE tool tries to create the TEstTable and waits for it to be enabled and
> just hangs there
> Previously this was not happening and the PE tool used to run fine after the
> table creation.
> -> When we try to scan with 25 threads the PE tool fails after some time
> saying Unable to create native threads.
> I lost the Stack trace now. But I could get it easily. It happens here
> {code}
> public void submit(RetryingCallable task, int callTimeout, int id) {
> QueueingFuture newFuture = new QueueingFuture(task, callTimeout);
> executor.execute(Trace.wrap(newFuture));
> tasks[id] = newFuture;
> }
> {code}
> in ResultBoundedCompletionService. This is also new. Previously it used to
> work with 25 threads without any issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13205) [branch-1] Backport HBASE-11598 Add simple rpc throttling
[ https://issues.apache.org/jira/browse/HBASE-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361600#comment-14361600 ] Ashish Singhi commented on HBASE-13205: --- Thanks [~apurtell] for taking a look and comments. As the jira description says I was asking for a backport to branch-1(1.1). bq. I think it would be nice to have an admission control capability in 0.98 I will try to backport there, once I can make some time for it. [~enis] can we backport this to branch-1 ? > [branch-1] Backport HBASE-11598 Add simple rpc throttling > - > > Key: HBASE-13205 > URL: https://issues.apache.org/jira/browse/HBASE-13205 > Project: HBase > Issue Type: Task > Components: security >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Labels: multitenancy, quota > Fix For: 1.1.0 > > Attachments: HBASE-13205-branch-1.patch, > HBASE-13205-v1-branch-1.patch, HBASE-13205-v2-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361585#comment-14361585 ] Jerry He commented on HBASE-13239: -- Cell level is implemented with cell tags, which is quite different from table/family/column level. HBASE-12745 covered groups for the cell level visibility. I will try to do some testing to see if groups for cell ACL works. > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361571#comment-14361571 ] Sean Busbey commented on HBASE-13239: - I'd like to make sure this issue isn't actually "grants for groups only works at table level" or something like that. +1 fine for punting the cell check so long as we have a JIRA for it. > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361566#comment-14361566
]
Ted Yu commented on HBASE-13239:
>From QA run:
{code}
Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 251.349 sec <<<
FAILURE! - in org.apache.hadoop.hbase.regionserver.TestPerColumnFamilyFlush
testFlushingWhenLogRolling(org.apache.hadoop.hbase.regionserver.TestPerColumnFamilyFlush)
Time elapsed: 180.034 sec <<< ERROR!
java.lang.Exception: test timed out after 18 milliseconds
at java.lang.Thread.sleep(Native Method)
at org.apache.hadoop.hbase.util.Threads.sleep(Threads.java:146)
at
org.apache.hadoop.hbase.regionserver.TestPerColumnFamilyFlush.testFlushingWhenLogRolling(TestPerColumnFamilyFlush.java:488)
testLogReplayWithDistributedReplay(org.apache.hadoop.hbase.regionserver.TestPerColumnFamilyFlush)
Time elapsed: 1.71 sec <<< ERROR!
java.lang.IllegalStateException: A mini-cluster is already running
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:951)
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
at
org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:811)
at
org.apache.hadoop.hbase.regionserver.TestPerColumnFamilyFlush.doTestLogReplay(TestPerColumnFamilyFlush.java:338)
at
org.apache.hadoop.hbase.regionserver.TestPerColumnFamilyFlush.testLogReplayWithDistributedReplay(TestPerColumnFamilyFlush.java:420)
{code}
The above failure is not related to patch.
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt, 13239-v2.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific user and scan the table. It produces correct
> results, i.e. provides only the column where user has select privileges
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361564#comment-14361564 ] Ted Yu commented on HBASE-13239: bq. e.g. grant to cell level? I can verify the above next time I get onto secure cluster. But, issues for cell level security can be covered in another JIRA, right ? > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361563#comment-14361563
]
Hadoop QA commented on HBASE-13239:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704559/13239-v2.txt
against master branch at commit e60cae0500daf3c146e10d808c5070c6cb24ecec.
ATTACHMENT ID: 12704559
{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 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13240//console
This message is automatically generated.
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt, 13239-v2.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific
[jira] [Updated] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-13236:
---
Attachment: HBASE-13236-v1.patch
Wrapped comment lines that exceeded 80chars. Was _slightly_ over-aggressive in
the top-level pom.xml as the comment block I added to already exceeded 80 chars.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch, HBASE-13236-v1.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361528#comment-14361528 ] Sean Busbey commented on HBASE-13239: - filed HBASE-13241 as follow on for tests. > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13241) Add tests for group level grants
Sean Busbey created HBASE-13241: --- Summary: Add tests for group level grants Key: HBASE-13241 URL: https://issues.apache.org/jira/browse/HBASE-13241 Project: HBase Issue Type: Improvement Components: security Reporter: Sean Busbey Priority: Critical We need to have tests for group-level grants for various scopes. ref: HBASE-13239 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13109) Make better SEEK vs SKIP decisions during scanning
[ https://issues.apache.org/jira/browse/HBASE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361526#comment-14361526 ] Andrew Purtell edited comment on HBASE-13109 at 3/14/15 2:23 AM: - So here's where I think we are: - This commit is fine. - No new base classes and inheritance hierarchy changes - Handle updates to Phoenix on a Phoenix JIRA. I can push a 0.98.12 SNAPSHOT to Maven if that would help. Any issues with this [~giacomotaylor] [~lhofhansl] ? was (Author: apurtell): So here's where I think we are: - This commit is fine. - No new base classes and inheritance hierarchy changes - Handle updates to Phoenix on a Phoenix JIRA. I can push a 0.98.12 SNAPSHOT to Maven if that would help. Any issues with this [~giacomotaylor] [~lhofhansl] ? > Make better SEEK vs SKIP decisions during scanning > -- > > Key: HBASE-13109 > URL: https://issues.apache.org/jira/browse/HBASE-13109 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13109-0.98-v4.txt, 13109-trunk-v2.txt, > 13109-trunk-v3.txt, 13109-trunk-v4.txt, 13109-trunk-v5.txt, 13109-trunk.txt, > nextIndexKVChange_new.patch > > > I'm re-purposing this issue to add a heuristic as to when to SEEK and when to > SKIP Cells. This has come up in various issues, and I think I have a way to > finally fix this now. HBASE-9778, HBASE-12311, and friends are related. > --- Old description --- > This is a continuation of HBASE-9778. > We've seen a scenario of a very slow scan over a region using a timerange > that happens to fall after the ts of any Cell in the region. > Turns out we spend a lot of time seeking. > Tested with a 5 column table, and the scan is 5x faster when the timerange > falls before all Cells' ts. > We can use the lookahead hint introduced in HBASE-9778 to do opportunistic > SKIPing before we actually seek. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13109) Make better SEEK vs SKIP decisions during scanning
[ https://issues.apache.org/jira/browse/HBASE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361526#comment-14361526 ] Andrew Purtell commented on HBASE-13109: So here's where I think we are: - This commit is fine. - No new base classes and inheritance hierarchy changes - Handle updates to Phoenix on a Phoenix JIRA. I can push a 0.98.12 SNAPSHOT to Maven if that would help. Any issues with this [~giacomotaylor] [~lhofhansl] ? > Make better SEEK vs SKIP decisions during scanning > -- > > Key: HBASE-13109 > URL: https://issues.apache.org/jira/browse/HBASE-13109 > Project: HBase > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13109-0.98-v4.txt, 13109-trunk-v2.txt, > 13109-trunk-v3.txt, 13109-trunk-v4.txt, 13109-trunk-v5.txt, 13109-trunk.txt, > nextIndexKVChange_new.patch > > > I'm re-purposing this issue to add a heuristic as to when to SEEK and when to > SKIP Cells. This has come up in various issues, and I think I have a way to > finally fix this now. HBASE-9778, HBASE-12311, and friends are related. > --- Old description --- > This is a continuation of HBASE-9778. > We've seen a scenario of a very slow scan over a region using a timerange > that happens to fall after the ts of any Cell in the region. > Turns out we spend a lot of time seeking. > Tested with a 5 column table, and the scan is 5x faster when the timerange > falls before all Cells' ts. > We can use the lookahead hint introduced in HBASE-9778 to do opportunistic > SKIPing before we actually seek. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361524#comment-14361524 ] Sean Busbey commented on HBASE-13239: - do the other scopes work for groups? e.g. grant to cell level? > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361520#comment-14361520 ] Ted Yu commented on HBASE-13239: I haven't figured out a way to add test for this scenario. Can the test be added in another issue ? This should be a bug - grant on column to user works. So should grant to group. Thanks > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361517#comment-14361517
]
Sean Busbey commented on HBASE-13236:
-
site built fine locally
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[ https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13237: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the review [~busbey]. Pushed to master. Site regenerated and committed in SVN > Improve trademark marks on the hbase.apache.org homepage > > > Key: HBASE-13237 > URL: https://issues.apache.org/jira/browse/HBASE-13237 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13237.patch, screenshot.png > > > Ensure trademark marks are next to first and prominent uses of "HBase" on the > hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13238) Time out locks and abort if HDFS is wedged
[ https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361515#comment-14361515 ] Lars Hofhansl commented on HBASE-13238: --- Ideal we fix this in HDFS, but in this case we actually had to get the region server killed, just so we can get "unstuck". I think it's reasonable to abort a region server when a region cannot close for 10 minutes (or something). Do you still have the two stack traces [~apurtell]? Might be instructive to attach them here. HBASE-12457 might be related. > Time out locks and abort if HDFS is wedged > -- > > Key: HBASE-13238 > URL: https://issues.apache.org/jira/browse/HBASE-13238 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell > > This is a brainstorming issue on the topic of timing out locks and aborting > rather than waiting infinitely. Perhaps even as a rule. > We had a minor production incident where a region was unable to close after > trying for 24 hours. The CloseRegionHandler was waiting for a write lock on > the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding > read locks. Three other threads were stuck in scanning, all blocked on the > same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the > third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with > apparent infinite timeout from PacketReceiver#readChannelFully. > This is similar to other issues we have seen before, in the context of the > region wanting to finish a compaction before closing for a split, but can't > due to some HDFS issue causing the reader to become extremely slow if not > wedged. This has lead to what should be quick SplitTransactions causing > availability problems of many minutes in length. > The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning > to upgrade, but [~lhofhansl] and I were discussing the issue in general and > wonder if we should not be timing out locks such as the > ReentrantReadWriteLock, and if so, abort the regionserver. In this case this > would have caused recovery and reassignment of the region in question and we > would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361512#comment-14361512 ] Sean Busbey commented on HBASE-13239: - one other question, is this a bug or an improvement? I recall some other permission setting recently expanding from user-only to groups allowed, would like to make sure we're being consistent. I think it's a bug, since granting the permission to a group doesn't fail. does that seem reasonable? > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361508#comment-14361508 ] Sean Busbey commented on HBASE-13239: - can we get a test? > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[ https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361507#comment-14361507 ] Sean Busbey commented on HBASE-13237: - excellent! I had been wondering if we filed. +1 looks good to me. would prefer the long lines be wrapped, but it looks like they were already problematically long. > Improve trademark marks on the hbase.apache.org homepage > > > Key: HBASE-13237 > URL: https://issues.apache.org/jira/browse/HBASE-13237 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13237.patch, screenshot.png > > > Ensure trademark marks are next to first and prominent uses of "HBase" on the > hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13240) add an exemption to test-patch for build-only changes.
Sean Busbey created HBASE-13240: --- Summary: add an exemption to test-patch for build-only changes. Key: HBASE-13240 URL: https://issues.apache.org/jira/browse/HBASE-13240 Project: HBase Issue Type: Improvement Components: build Reporter: Sean Busbey Assignee: Sean Busbey Priority: Minor we've had a couple of patches lately that got pinged for no tests, but they were build-only changes. expand the exemption list from "docs" to also include changes just to build infra. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361506#comment-14361506
]
Sean Busbey commented on HBASE-13236:
-
test failures look unrelated. build patches don't need tests. I'm running
through site locally now to see what's up. the build looks like it just stopped.
Josh, could you clean up the long lines?
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13238) Time out locks and abort if HDFS is wedged
[
https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361479#comment-14361479
]
zhangduo edited comment on HBASE-13238 at 3/14/15 1:44 AM:
---
{quote}
Even if we get hung up at the HDFS level, it's our problem, we can't just have
indefinite unavailability in some known circumstances.
{quote}
Agree.
I know sometimes it is hard to make HDFS support us(HBASE-5940, almost 3 years
and no progress...), they have their own plan.
But suggest to keep the work around code only in critical places and strongly
document why we do this.
was (Author: apache9):
{noformat}
Even if we get hung up at the HDFS level, it's our problem, we can't just have
indefinite unavailability in some known circumstances.
{noformat}
Agree.
I know sometimes it is hard to make HDFS support us(HBASE-5940, almost 3 years
and no progress...), they have their own plan.
But suggest to keep the work around code only in critical places and strongly
document why we do this.
> Time out locks and abort if HDFS is wedged
> --
>
> Key: HBASE-13238
> URL: https://issues.apache.org/jira/browse/HBASE-13238
> Project: HBase
> Issue Type: Brainstorming
>Reporter: Andrew Purtell
>
> This is a brainstorming issue on the topic of timing out locks and aborting
> rather than waiting infinitely. Perhaps even as a rule.
> We had a minor production incident where a region was unable to close after
> trying for 24 hours. The CloseRegionHandler was waiting for a write lock on
> the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding
> read locks. Three other threads were stuck in scanning, all blocked on the
> same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the
> third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with
> apparent infinite timeout from PacketReceiver#readChannelFully.
> This is similar to other issues we have seen before, in the context of the
> region wanting to finish a compaction before closing for a split, but can't
> due to some HDFS issue causing the reader to become extremely slow if not
> wedged. This has lead to what should be quick SplitTransactions causing
> availability problems of many minutes in length.
> The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning
> to upgrade, but [~lhofhansl] and I were discussing the issue in general and
> wonder if we should not be timing out locks such as the
> ReentrantReadWriteLock, and if so, abort the regionserver. In this case this
> would have caused recovery and reassignment of the region in question and we
> would not have had a prolonged availability problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13238) Time out locks and abort if HDFS is wedged
[
https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361479#comment-14361479
]
zhangduo commented on HBASE-13238:
--
{noformat}
Even if we get hung up at the HDFS level, it's our problem, we can't just have
indefinite unavailability in some known circumstances.
{noformat}
Agree.
I know sometimes it is hard to make HDFS support us(HBASE-5940, almost 3 years
and no progress...), they have their own plan.
But suggest to keep the work around code only in critical places and strongly
document why we do this.
> Time out locks and abort if HDFS is wedged
> --
>
> Key: HBASE-13238
> URL: https://issues.apache.org/jira/browse/HBASE-13238
> Project: HBase
> Issue Type: Brainstorming
>Reporter: Andrew Purtell
>
> This is a brainstorming issue on the topic of timing out locks and aborting
> rather than waiting infinitely. Perhaps even as a rule.
> We had a minor production incident where a region was unable to close after
> trying for 24 hours. The CloseRegionHandler was waiting for a write lock on
> the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding
> read locks. Three other threads were stuck in scanning, all blocked on the
> same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the
> third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with
> apparent infinite timeout from PacketReceiver#readChannelFully.
> This is similar to other issues we have seen before, in the context of the
> region wanting to finish a compaction before closing for a split, but can't
> due to some HDFS issue causing the reader to become extremely slow if not
> wedged. This has lead to what should be quick SplitTransactions causing
> availability problems of many minutes in length.
> The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning
> to upgrade, but [~lhofhansl] and I were discussing the issue in general and
> wonder if we should not be timing out locks such as the
> ReentrantReadWriteLock, and if so, abort the regionserver. In this case this
> would have caused recovery and reassignment of the region in question and we
> would not have had a prolonged availability problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361466#comment-14361466 ] Srikanth Srungarapu commented on HBASE-13239: - +1 (non-binding). > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13222) Provide means of non-destructive balancer inspection
[ https://issues.apache.org/jira/browse/HBASE-13222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361465#comment-14361465 ] Enis Soztutar commented on HBASE-13222: --- Don't you love that balanceSwitch() is acting according to Heisenberg principle. You cannot observe without modifying the state. > Provide means of non-destructive balancer inspection > > > Key: HBASE-13222 > URL: https://issues.apache.org/jira/browse/HBASE-13222 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: Nick Dimiduk >Priority: Minor > Fix For: 0.98.13 > > Attachments: HBASE-13222.00-0.98.patch > > > At least on 0.98 (haven't checked master, 1.0), it seems we don't have a > means for accessing balancer status w.o changing it in the process. Here's a > little script to tickle ZK and see what the flag is. Would be nice if this > was available from the shell, on the master status page, or something similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-13239: --- Attachment: 13239-v2.txt Patch v2 addresses review comments. > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt, 13239-v2.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13223) Add testMoveMeta to IntegrationTestMTTR
[ https://issues.apache.org/jira/browse/HBASE-13223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361459#comment-14361459 ] Andrew Purtell commented on HBASE-13223: Patch lgtm Anyone see an issue preventing commit? Will come back to this next week and commit if no objection > Add testMoveMeta to IntegrationTestMTTR > --- > > Key: HBASE-13223 > URL: https://issues.apache.org/jira/browse/HBASE-13223 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Dima Spivak >Assignee: Dima Spivak > Attachments: HBASE-13223_master_v1.patch > > > It would be nice to add a new test case to IntegrationTestMTTR that would > trigger a move of the regions of hbase:meta and evaluate the MTTR in the > aftermath. Pretty straightforward addition to the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13222) Provide means of non-destructive balancer inspection
[ https://issues.apache.org/jira/browse/HBASE-13222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361457#comment-14361457 ] Andrew Purtell commented on HBASE-13222: Patch lgtm, but shouldn't we have this everywhere. Do later versions provide an API? Interested in adding one? The shell code could try using the API and fall back to znode inspection if it's not available. > Provide means of non-destructive balancer inspection > > > Key: HBASE-13222 > URL: https://issues.apache.org/jira/browse/HBASE-13222 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: Nick Dimiduk >Priority: Minor > Fix For: 0.98.13 > > Attachments: HBASE-13222.00-0.98.patch > > > At least on 0.98 (haven't checked master, 1.0), it seems we don't have a > means for accessing balancer status w.o changing it in the process. Here's a > little script to tickle ZK and see what the flag is. Would be nice if this > was available from the shell, on the master status page, or something similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361452#comment-14361452
]
Srikanth Srungarapu commented on HBASE-13239:
-
On second thoughts, actually you can delete existing function as it is not
being used else where!
{code}public boolean authorizeGroup(String groupName, TableName table, byte[]
family, Permission.Action action) {code}
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific user and scan the table. It produces correct
> results, i.e. provides only the column where user has select privileges
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13238) Time out locks and abort if HDFS is wedged
[ https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361448#comment-14361448 ] Andrew Purtell commented on HBASE-13238: bq. SocketIOWithTimeout does not timeout? So why does it have a 'Timeout' in its name... Beats me. FWIW, I dumped the stack of the regionserver several times over a period of hours and the thread in question had the same stack trace each time. Even if we get hung up at the HDFS level, it's our problem, we can't just have indefinite unavailability in some known circumstances. > Time out locks and abort if HDFS is wedged > -- > > Key: HBASE-13238 > URL: https://issues.apache.org/jira/browse/HBASE-13238 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell > > This is a brainstorming issue on the topic of timing out locks and aborting > rather than waiting infinitely. Perhaps even as a rule. > We had a minor production incident where a region was unable to close after > trying for 24 hours. The CloseRegionHandler was waiting for a write lock on > the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding > read locks. Three other threads were stuck in scanning, all blocked on the > same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the > third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with > apparent infinite timeout from PacketReceiver#readChannelFully. > This is similar to other issues we have seen before, in the context of the > region wanting to finish a compaction before closing for a split, but can't > due to some HDFS issue causing the reader to become extremely slow if not > wedged. This has lead to what should be quick SplitTransactions causing > availability problems of many minutes in length. > The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning > to upgrade, but [~lhofhansl] and I were discussing the issue in general and > wonder if we should not be timing out locks such as the > ReentrantReadWriteLock, and if so, abort the regionserver. In this case this > would have caused recovery and reassignment of the region in question and we > would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13205) [branch-1] Backport HBASE-11598 Add simple rpc throttling
[ https://issues.apache.org/jira/browse/HBASE-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361442#comment-14361442 ] Andrew Purtell edited comment on HBASE-13205 at 3/14/15 1:06 AM: - Or are you asking if this branch-1 backport is fine? Above comments mostly apply, but compatibility rules are different there, I think a new feature would be ok for 1.1, i.e. branch-1, but not 1.0 i.e. branch-1.0. So this patch is ok for branch-1. Ask [~enis] too was (Author: apurtell): Or are you asking if this branch-1 backport is fine? Above comments mostly apply, but compatibility rules are different there, I think new a new feature would be ok for 1.1, i.e. branch-1, but not 1.0 i.e. branch-1.0. So this patch is ok for branch-1. Ask [~enis] too > [branch-1] Backport HBASE-11598 Add simple rpc throttling > - > > Key: HBASE-13205 > URL: https://issues.apache.org/jira/browse/HBASE-13205 > Project: HBase > Issue Type: Task > Components: security >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Labels: multitenancy, quota > Fix For: 1.1.0 > > Attachments: HBASE-13205-branch-1.patch, > HBASE-13205-v1-branch-1.patch, HBASE-13205-v2-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13205) [branch-1] Backport HBASE-11598 Add simple rpc throttling
[ https://issues.apache.org/jira/browse/HBASE-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361442#comment-14361442 ] Andrew Purtell edited comment on HBASE-13205 at 3/14/15 1:06 AM: - Or are you asking if this branch-1 backport is fine? Above comments mostly apply, but compatibility rules are different there, I think new a new feature would be ok for 1.1, i.e. branch-1, but not 1.0 i.e. branch-1.0. So this patch is ok for branch-1. Ask [~enis] too was (Author: apurtell): Or are you asking if this branch-1 backport is fine? Compatibility is different there, I think new a new feature would be ok for 1.1, i.e. branch-1, but not 1.0 i.e. branch-1.0. So this patch is ok for branch-1. Ask [~enis] too > [branch-1] Backport HBASE-11598 Add simple rpc throttling > - > > Key: HBASE-13205 > URL: https://issues.apache.org/jira/browse/HBASE-13205 > Project: HBase > Issue Type: Task > Components: security >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Labels: multitenancy, quota > Fix For: 1.1.0 > > Attachments: HBASE-13205-branch-1.patch, > HBASE-13205-v1-branch-1.patch, HBASE-13205-v2-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13205) [branch-1] Backport HBASE-11598 Add simple rpc throttling
[ https://issues.apache.org/jira/browse/HBASE-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361440#comment-14361440 ] Andrew Purtell edited comment on HBASE-13205 at 3/14/15 1:05 AM: - You have a need for this in 0.98 [~ashish singhi]? I think it would be nice to have an admission control capability in 0.98 as long as we can be compatible in the following ways: - Rolling upgrades are possible, with configuration updates for new features deferred until the fleet is all at the same version - Old clients can talk to new servers - Old servers can talk to new clients, excepting where new APIs are not available on the server side, and this is handled gracefully I made a quick pass over the branch-1 patch: - In 0.98, Connection and ConnectionManager are HConnection and HConnectionManager, respectively. Both are marked Public/Evolving and not meant for direct client extension anyway. We discussed this earlier when backporting client load backoff. - Protobuf changes are wire compatible - There are new methods added to MasterObserver, for support for intercepting new admin APIs for quotas. The abstract base classes we have to assist implementors when this API evolves are updated with default implementations. - Adding new methods to interfaces like HBaseAdmin is binary compatible with earlier compiled code - Shell changes are additive - Other affected classes and interfaces are marked private. I don't see a blocking issue. was (Author: apurtell): You have a need for this in 0.98 [~ashish singhi]? I think it would be nice to have an admission control capability in 0.98 as long as we can be compatible in the following ways: - Rolling upgrades are possible, with configuration updates for new features deferred until the fleet is all at the same version - Old clients can talk to new servers - Old servers can talk to new clients, excepting where new APIs are not available on the server side, and this is handled gracefully I made a quick pass over the branch-1 pass: - In 0.98, Connection and ConnectionManager are HConnection and HConnectionManager, respectively. Both are marked Public/Evolving and not meant for direct client extension anyway. We discussed this earlier when backporting client load backoff. - Protobuf changes are wire compatible - There are new methods added to MasterObserver, for support for intercepting new admin APIs for quotas. The abstract base classes we have to assist implementors when this API evolves are updated with default implementations. - Adding new methods to interfaces like HBaseAdmin is binary compatible with earlier compiled code - Shell changes are additive - Other affected classes and interfaces are marked private. I don't see a blocking issue. > [branch-1] Backport HBASE-11598 Add simple rpc throttling > - > > Key: HBASE-13205 > URL: https://issues.apache.org/jira/browse/HBASE-13205 > Project: HBase > Issue Type: Task > Components: security >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Labels: multitenancy, quota > Fix For: 1.1.0 > > Attachments: HBASE-13205-branch-1.patch, > HBASE-13205-v1-branch-1.patch, HBASE-13205-v2-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361441#comment-14361441
]
Srikanth Srungarapu commented on HBASE-13239:
-
That's super fast, [~te...@apache.org]!
Some minor concerns:
* We can check for LOG.isDebugEnabled()
{code}
-return authorize(globalCache.getGroup(groupName), action);
+List perms = globalCache.getGroup(groupName);
+LOG.debug("authorizing " + (perms != null && !perms.isEmpty() ?
perms.get(0) : "") +
+ " for " + action);
+return authorize(perms, action);
{code}
* Any particular reason for creating a local variable *tblPerms*
{code}
+List tblPerms =
getTablePermissions(table).getGroup(groupName);
+return authorize(tblPerms, table, family, action);
{code}
* We can reuse the new function by calling it inside existing *authorizeGroup*
by using null for qualifier value.
{code}
+ /**
+ * Checks authorization to a given table, column family and column for a
group, based
+ * on the stored permissions.
+ * @param groupName
+ * @param table
+ * @param family
+ * @param qualifier
+ * @param action
+ * @return true if known and authorized, false otherwise
+ */
+ public boolean authorizeGroup(String groupName, TableName table, byte[]
family,
+ byte[] qualifier, Permission.Action action) {
+// Global authorization supercedes table level
+if (authorizeGroup(groupName, action)) {
+ return true;
+}
+if (table == null) table = AccessControlLists.ACL_TABLE_NAME;
+// Namespace authorization supercedes table level
+String namespace = table.getNamespaceAsString();
+if (authorize(getNamespacePermissions(namespace).getGroup(groupName),
namespace, action)) {
+ return true;
+}
+// Check table level
+List tblPerms =
getTablePermissions(table).getGroup(groupName);
+LOG.debug("authorizing " + (tblPerms != null && !tblPerms.isEmpty() ?
tblPerms.get(0) : "") +
+ " for " +groupName + " on " + table + "." + Bytes.toString(family) + "."
+
+Bytes.toString(qualifier) + " with " + action);
+return authorize(tblPerms, table, family, qualifier, action);
}
{code}
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific user and scan the table. It produces correct
> results, i.e. provides only the column where user has select privileges
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13205) [branch-1] Backport HBASE-11598 Add simple rpc throttling
[ https://issues.apache.org/jira/browse/HBASE-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361442#comment-14361442 ] Andrew Purtell commented on HBASE-13205: Or are you asking if this branch-1 backport is fine? Compatibility is different there, I think new a new feature would be ok for 1.1, i.e. branch-1, but not 1.0 i.e. branch-1.0. So this patch is ok for branch-1. Ask [~enis] too > [branch-1] Backport HBASE-11598 Add simple rpc throttling > - > > Key: HBASE-13205 > URL: https://issues.apache.org/jira/browse/HBASE-13205 > Project: HBase > Issue Type: Task > Components: security >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Labels: multitenancy, quota > Fix For: 1.1.0 > > Attachments: HBASE-13205-branch-1.patch, > HBASE-13205-v1-branch-1.patch, HBASE-13205-v2-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13205) [branch-1] Backport HBASE-11598 Add simple rpc throttling
[ https://issues.apache.org/jira/browse/HBASE-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361440#comment-14361440 ] Andrew Purtell commented on HBASE-13205: You have a need for this in 0.98 [~ashish singhi]? I think it would be nice to have an admission control capability in 0.98 as long as we can be compatible in the following ways: - Rolling upgrades are possible, with configuration updates for new features deferred until the fleet is all at the same version - Old clients can talk to new servers - Old servers can talk to new clients, excepting where new APIs are not available on the server side, and this is handled gracefully I made a quick pass over the branch-1 pass: - In 0.98, Connection and ConnectionManager are HConnection and HConnectionManager, respectively. Both are marked Public/Evolving and not meant for direct client extension anyway. We discussed this earlier when backporting client load backoff. - Protobuf changes are wire compatible - There are new methods added to MasterObserver, for support for intercepting new admin APIs for quotas. The abstract base classes we have to assist implementors when this API evolves are updated with default implementations. - Adding new methods to interfaces like HBaseAdmin is binary compatible with earlier compiled code - Shell changes are additive - Other affected classes and interfaces are marked private. I don't see a blocking issue. > [branch-1] Backport HBASE-11598 Add simple rpc throttling > - > > Key: HBASE-13205 > URL: https://issues.apache.org/jira/browse/HBASE-13205 > Project: HBase > Issue Type: Task > Components: security >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Labels: multitenancy, quota > Fix For: 1.1.0 > > Attachments: HBASE-13205-branch-1.patch, > HBASE-13205-v1-branch-1.patch, HBASE-13205-v2-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13090) Progress heartbeats for long running scanners
[
https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361439#comment-14361439
]
Hadoop QA commented on HBASE-13090:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704530/HBASE-13090-v3.patch
against master branch at commit e60cae0500daf3c146e10d808c5070c6cb24ecec.
ATTACHMENT ID: 12704530
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 28 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ result = result && (hasClientHandlesHeartbeatMessages() ==
other.hasClientHandlesHeartbeatMessages());
+ new java.lang.String[] { "Region", "Scan", "ScannerId",
"NumberOfRows", "CloseScanner", "NextCallSeq", "ClientHandlesPartials",
"ClientHandlesHeartbeatMessages", });
+ new java.lang.String[] { "CellsPerResult", "ScannerId",
"MoreResults", "Ttl", "Results", "Stale", "PartialFlagPerResult",
"HeartbeatMessage", });
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13237//console
This message is automatically generated.
> Progress heartbeats for long running scanners
> -
>
> Key: HBASE-13090
> URL: https://issues.apache.org/jira/browse/HBASE-13090
> Project: HBase
> Issue Type: New Feature
>Reporter: Andrew Purtell
>Assignee: Jonathan Lawlor
> Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch,
> HBASE-13090-v3.patch, HBASE-13090-v3.patch
>
>
> It can be necessary to set very long timeouts for clients that issue scans
> over large regions when all data in the region might be filtered out
> depending on scan criteria. This is a usability concern because it can be
> hard to identify what worst case timeout to use until scans are
> occasionally/intermittently failing in production, depending on variable scan
[jira] [Commented] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[
https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361435#comment-14361435
]
Hadoop QA commented on HBASE-13237:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704528/HBASE-13237.patch
against master branch at commit e60cae0500daf3c146e10d808c5070c6cb24ecec.
ATTACHMENT ID: 12704528
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+http://www.apache.org/";>Apache HBase™ is the
http://hadoop.apache.org";>Hadoop database, a distributed,
scalable, big data store.
+Click http://www.apache.org/dyn/closer.cgi/hbase/";>here to download
Apache HBase™.
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13236//console
This message is automatically generated.
> Improve trademark marks on the hbase.apache.org homepage
>
>
> Key: HBASE-13237
> URL: https://issues.apache.org/jira/browse/HBASE-13237
> Project: HBase
> Issue Type: Task
> Components: documentation
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-13237.patch, screenshot.png
>
>
> Ensure trademark marks are next to first and prominent uses of "HBase" on the
> hbase.apache.org homepage
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-13239: --- Attachment: 13239-v1.txt > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-13239: --- Attachment: (was: 13239-v1.txt) > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13202) Procedure v2 - core framework
[
https://issues.apache.org/jira/browse/HBASE-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361419#comment-14361419
]
Hadoop QA commented on HBASE-13202:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704524/HBASE-13202-v0-hbase-12439.patch
against hbase-12439 branch at commit e60cae0500daf3c146e10d808c5070c6cb24ecec.
ATTACHMENT ID: 12704524
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 16 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
+ if (!((mutable_bitField0_ & 0x0040) == 0x0040) &&
input.getBytesUntilLimit() > 0) {
+ "me\030\004 \002(\004\022\r\n\005owner\030\005
\001(\t\022\036\n\005state\030\006 \002(\0162\017" +
+ new java.lang.String[] { "ClassName", "ParentId", "ProcId",
"StartTime", "Owner", "State", "StackId", "LastUpdate", "Timeout", "Exception",
"Result", "StateData", });
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-procedure.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13235//console
This message is automatically generated.
> Procedure v2 - core framework
> -
>
> Key: HBASE-13202
> URL: https://issues.apache.org/jira/browse/HBASE-13202
> Project: HBase
> Issue Type: Sub-task
> Components: master
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-13202-v0-hbase-12439.patch
>
>
> core package, part of HBASE-12439
> this is just the
[jira] [Commented] (HBASE-13238) Time out locks and abort if HDFS is wedged
[ https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361416#comment-14361416 ] zhangduo commented on HBASE-13238: -- SocketIOWithTimeout does not timeout? So why does it have a 'Timeout' in its name... I think this is an HDFS issue, all I/O operations should have a configurable bounded timeout, and in HBase we deal with these timeout exceptions. Of course a timeout lock could help, but I think there are lots of places where we just use synchronized? Thanks. > Time out locks and abort if HDFS is wedged > -- > > Key: HBASE-13238 > URL: https://issues.apache.org/jira/browse/HBASE-13238 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell > > This is a brainstorming issue on the topic of timing out locks and aborting > rather than waiting infinitely. Perhaps even as a rule. > We had a minor production incident where a region was unable to close after > trying for 24 hours. The CloseRegionHandler was waiting for a write lock on > the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding > read locks. Three other threads were stuck in scanning, all blocked on the > same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the > third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with > apparent infinite timeout from PacketReceiver#readChannelFully. > This is similar to other issues we have seen before, in the context of the > region wanting to finish a compaction before closing for a split, but can't > due to some HDFS issue causing the reader to become extremely slow if not > wedged. This has lead to what should be quick SplitTransactions causing > availability problems of many minutes in length. > The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning > to upgrade, but [~lhofhansl] and I were discussing the issue in general and > wonder if we should not be timing out locks such as the > ReentrantReadWriteLock, and if so, abort the regionserver. In this case this > would have caused recovery and reassignment of the region in question and we > would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361408#comment-14361408
]
Ted Yu edited comment on HBASE-13239 at 3/14/15 12:40 AM:
--
Also confirmed that permission granting based on family still works:
{code}
hbase(main):001:0> user_permission 'IntegrationTestIngest'
User Table,Family,Qualifier:Permission
@users IntegrationTestIngest,test_cf,:
[Permission: actions=READ]
hbaseIntegrationTestIngest,,:
[Permission: actions=READ,WRITE,EXEC,CREATE,ADMIN]
...
[root@ty-sec-1-3 ~]# su - hrt_2
[hrt_2@ty-sec-1-3 ~]$ hbase shell
2015-03-13 23:50:41,438 INFO [main] Configuration.deprecation:
hadoop.native.lib is deprecated. Instead, use io.native.lib.available
HBase Shell; enter 'help' for list of supported commands.
Type "exit" to leave the HBase Shell
Version 0.98.4.2.2.2.0-2606-hadoop2, r82b3ef1436f1e5d35fa56a3ced1088e5308dd84f,
Thu Mar 12 20:38:30 EDT 2015
hbase(main):001:0> count 'IntegrationTestIngest'
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/hadoop/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
Current count: 1000, row: 017e3cdfbb52cd9828ec3136354c54b2-49287
Current count: 2000, row: 02ff1fa35bacc1643287baab70d1ce52-121729
Current count: 3000, row: 04851359d83c573e1b9bd3c5b1633618-106751
Current count: 4000, row: 0600480d533e3f41ce2e6e77415aa54e-134553
{code}
was (Author: yuzhih...@gmail.com):
Also confirmed that permission granting based family still works:
{code}
hbase(main):001:0> user_permission 'IntegrationTestIngest'
User Table,Family,Qualifier:Permission
@users IntegrationTestIngest,test_cf,:
[Permission: actions=READ]
hbaseIntegrationTestIngest,,:
[Permission: actions=READ,WRITE,EXEC,CREATE,ADMIN]
...
[root@ty-sec-1-3 ~]# su - hrt_2
[hrt_2@ty-sec-1-3 ~]$ hbase shell
2015-03-13 23:50:41,438 INFO [main] Configuration.deprecation:
hadoop.native.lib is deprecated. Instead, use io.native.lib.available
HBase Shell; enter 'help' for list of supported commands.
Type "exit" to leave the HBase Shell
Version 0.98.4.2.2.2.0-2606-hadoop2, r82b3ef1436f1e5d35fa56a3ced1088e5308dd84f,
Thu Mar 12 20:38:30 EDT 2015
hbase(main):001:0> count 'IntegrationTestIngest'
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/hadoop/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
Current count: 1000, row: 017e3cdfbb52cd9828ec3136354c54b2-49287
Current count: 2000, row: 02ff1fa35bacc1643287baab70d1ce52-121729
Current count: 3000, row: 04851359d83c573e1b9bd3c5b1633618-106751
Current count: 4000, row: 0600480d533e3f41ce2e6e77415aa54e-134553
{code}
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific user and scan the table. It produces correct
> results, i.e. provides only the column where user has select privileges
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361408#comment-14361408
]
Ted Yu commented on HBASE-13239:
Also confirmed that permission granting based family still works:
{code}
hbase(main):001:0> user_permission 'IntegrationTestIngest'
User Table,Family,Qualifier:Permission
@users IntegrationTestIngest,test_cf,:
[Permission: actions=READ]
hbaseIntegrationTestIngest,,:
[Permission: actions=READ,WRITE,EXEC,CREATE,ADMIN]
...
[root@ty-sec-1-3 ~]# su - hrt_2
[hrt_2@ty-sec-1-3 ~]$ hbase shell
2015-03-13 23:50:41,438 INFO [main] Configuration.deprecation:
hadoop.native.lib is deprecated. Instead, use io.native.lib.available
HBase Shell; enter 'help' for list of supported commands.
Type "exit" to leave the HBase Shell
Version 0.98.4.2.2.2.0-2606-hadoop2, r82b3ef1436f1e5d35fa56a3ced1088e5308dd84f,
Thu Mar 12 20:38:30 EDT 2015
hbase(main):001:0> count 'IntegrationTestIngest'
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/hadoop/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
Current count: 1000, row: 017e3cdfbb52cd9828ec3136354c54b2-49287
Current count: 2000, row: 02ff1fa35bacc1643287baab70d1ce52-121729
Current count: 3000, row: 04851359d83c573e1b9bd3c5b1633618-106751
Current count: 4000, row: 0600480d533e3f41ce2e6e77415aa54e-134553
{code}
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific user and scan the table. It produces correct
> results, i.e. provides only the column where user has select privileges
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[
https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361406#comment-14361406
]
Ted Yu commented on HBASE-13239:
Verified the patch on a secure cluster:
{code}
hbase(main):002:0> scan 'usertable'
ROW COLUMN+CELL
row01column=family:col01,
timestamp=1426265186329, value=value1
1 row(s) in 0.3130 seconds
hbase(main):002:0> grant '@users','R', 'usertable', 'family', 'col01'
0 row(s) in 0.4540 seconds
hbase(main):003:0> user_permission 'usertable'
User Table,Family,Qualifier:Permission
@users usertable,family,col01:
[Permission: actions=READ]
hrt_qa usertable,,: [Permission:
actions=READ,WRITE,EXEC,CREATE,ADMIN]
2 row(s) in 0.0770 seconds
{code}
I then logged in as user hrt_2 who is a member of users group:
{code}
hbase(main):001:0> scan 'usertable'
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/hadoop/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/grid/0/hdp/2.2.2.0-2606/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
ROW COLUMN+CELL
row01column=family:col01,
timestamp=1426265186329, value=value1
{code}
> Hbase grants at specific column level does not work for Groups
>
>
> Key: HBASE-13239
> URL: https://issues.apache.org/jira/browse/HBASE-13239
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 0.98.4
>Reporter: Jaymin Patel
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
> Attachments: 13239-v1.txt
>
>
> While performing Grant command to a specific column in a table - to a
> specific group does not produce needed results. However, when specific user
> is mentioned (instead of group name) in grant command, it becomes effective
> Steps to Reproduce :
> 1) using super-user, Grant a table/column family/column level grant to a group
> 2) login using a user ( part of the above group) and scan the table. It does
> not return any results
> 3) using super-user, Grant a table/column family/column level grant to a
> specific user ( instead of group)
> 4) login using that specific user and scan the table. It produces correct
> results, i.e. provides only the column where user has select privileges
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-13239: --- Fix Version/s: 0.98.12 1.1.0 1.0.1 2.0.0 Status: Patch Available (was: Open) > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-13239: --- Attachment: 13239-v1.txt > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: 13239-v1.txt > > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13227) LoadIncrementalHFile should skip non-files inside a possible family-dir
[ https://issues.apache.org/jira/browse/HBASE-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361369#comment-14361369 ] Hudson commented on HBASE-13227: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #854 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/854/]) HBASE-13227 LoadIncrementalHFile should skip non-files inside a possible family-dir (addendum) (matteo.bertozzi: rev 3c776ff280cdd42542429d82ad2d1d88f73855e2) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > LoadIncrementalHFile should skip non-files inside a possible family-dir > --- > > Key: HBASE-13227 > URL: https://issues.apache.org/jira/browse/HBASE-13227 > Project: HBase > Issue Type: Bug > Components: Client, mapreduce >Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.11 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: HBASE-13227-addendum-0.98.patch, HBASE-13227-v0.patch > > > if we have random files/dirs inside the bulkload family dir, we should try to > skip them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-13239) Hbase grants at specific column level does not work for Groups
[ https://issues.apache.org/jira/browse/HBASE-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu reassigned HBASE-13239: -- Assignee: Ted Yu > Hbase grants at specific column level does not work for Groups > > > Key: HBASE-13239 > URL: https://issues.apache.org/jira/browse/HBASE-13239 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 0.98.4 >Reporter: Jaymin Patel >Assignee: Ted Yu > > While performing Grant command to a specific column in a table - to a > specific group does not produce needed results. However, when specific user > is mentioned (instead of group name) in grant command, it becomes effective > Steps to Reproduce : > 1) using super-user, Grant a table/column family/column level grant to a group > 2) login using a user ( part of the above group) and scan the table. It does > not return any results > 3) using super-user, Grant a table/column family/column level grant to a > specific user ( instead of group) > 4) login using that specific user and scan the table. It produces correct > results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13239) Hbase grants at specific column level does not work for Groups
Jaymin Patel created HBASE-13239: Summary: Hbase grants at specific column level does not work for Groups Key: HBASE-13239 URL: https://issues.apache.org/jira/browse/HBASE-13239 Project: HBase Issue Type: Bug Components: hbase Affects Versions: 0.98.4 Reporter: Jaymin Patel While performing Grant command to a specific column in a table - to a specific group does not produce needed results. However, when specific user is mentioned (instead of group name) in grant command, it becomes effective Steps to Reproduce : 1) using super-user, Grant a table/column family/column level grant to a group 2) login using a user ( part of the above group) and scan the table. It does not return any results 3) using super-user, Grant a table/column family/column level grant to a specific user ( instead of group) 4) login using that specific user and scan the table. It produces correct results, i.e. provides only the column where user has select privileges -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361343#comment-14361343
]
Enis Soztutar commented on HBASE-13236:
---
+1.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361298#comment-14361298
]
Hadoop QA commented on HBASE-13236:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704510/HBASE-13236-master.patch
against master branch at commit e60cae0500daf3c146e10d808c5070c6cb24ecec.
ATTACHMENT ID: 12704510
{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 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+
+
+
+
+
+
+
+
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.util.TestProcessBasedCluster
org.apache.hadoop.hbase.mapreduce.TestImportExport
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13233//console
This message is automatically generated.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom
[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners
[ https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Lawlor updated HBASE-13090: Attachment: HBASE-13090-v3.patch > Progress heartbeats for long running scanners > - > > Key: HBASE-13090 > URL: https://issues.apache.org/jira/browse/HBASE-13090 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Jonathan Lawlor > Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch, > HBASE-13090-v3.patch, HBASE-13090-v3.patch > > > It can be necessary to set very long timeouts for clients that issue scans > over large regions when all data in the region might be filtered out > depending on scan criteria. This is a usability concern because it can be > hard to identify what worst case timeout to use until scans are > occasionally/intermittently failing in production, depending on variable scan > criteria. It would be better if the client-server scan protocol can send back > periodic progress heartbeats to clients as long as server scanners are alive > and making progress. > This is related but orthogonal to streaming scan (HBASE-13071). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[ https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13237: --- Attachment: HBASE-13237.patch Yes, the unicode symbol works better (at least with Chrome) > Improve trademark marks on the hbase.apache.org homepage > > > Key: HBASE-13237 > URL: https://issues.apache.org/jira/browse/HBASE-13237 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13237.patch, screenshot.png > > > Ensure trademark marks are next to first and prominent uses of "HBase" on the > hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[ https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13237: --- Status: Patch Available (was: Open) > Improve trademark marks on the hbase.apache.org homepage > > > Key: HBASE-13237 > URL: https://issues.apache.org/jira/browse/HBASE-13237 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13237.patch, screenshot.png > > > Ensure trademark marks are next to first and prominent uses of "HBase" on the > hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[ https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13237: --- Attachment: screenshot.png > Improve trademark marks on the hbase.apache.org homepage > > > Key: HBASE-13237 > URL: https://issues.apache.org/jira/browse/HBASE-13237 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13237.patch, screenshot.png > > > Ensure trademark marks are next to first and prominent uses of "HBase" on the > hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13234) Improve the obviousness of the download link on hbase.apache.org
[ https://issues.apache.org/jira/browse/HBASE-13234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361222#comment-14361222 ] Hudson commented on HBASE-13234: SUCCESS: Integrated in HBase-TRUNK #6257 (See [https://builds.apache.org/job/HBase-TRUNK/6257/]) HBASE-13234 Improve the obviousness of the download link on hbase.apache.org (apurtell: rev e60cae0500daf3c146e10d808c5070c6cb24ecec) * src/main/site/xdoc/index.xml > Improve the obviousness of the download link on hbase.apache.org > > > Key: HBASE-13234 > URL: https://issues.apache.org/jira/browse/HBASE-13234 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13234.patch, screenshot.png > > > Update the hbase.apache.org homepage to include a very obvious section > describing how a user can "Download HBase Software Here" with a link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners
[ https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Lawlor updated HBASE-13090: Status: Patch Available (was: Open) resubmit patch; pre-commit build didn't statrt > Progress heartbeats for long running scanners > - > > Key: HBASE-13090 > URL: https://issues.apache.org/jira/browse/HBASE-13090 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Jonathan Lawlor > Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch, > HBASE-13090-v3.patch > > > It can be necessary to set very long timeouts for clients that issue scans > over large regions when all data in the region might be filtered out > depending on scan criteria. This is a usability concern because it can be > hard to identify what worst case timeout to use until scans are > occasionally/intermittently failing in production, depending on variable scan > criteria. It would be better if the client-server scan protocol can send back > periodic progress heartbeats to clients as long as server scanners are alive > and making progress. > This is related but orthogonal to streaming scan (HBASE-13071). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners
[ https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Lawlor updated HBASE-13090: Status: Open (was: Patch Available) > Progress heartbeats for long running scanners > - > > Key: HBASE-13090 > URL: https://issues.apache.org/jira/browse/HBASE-13090 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Jonathan Lawlor > Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch, > HBASE-13090-v3.patch > > > It can be necessary to set very long timeouts for clients that issue scans > over large regions when all data in the region might be filtered out > depending on scan criteria. This is a usability concern because it can be > hard to identify what worst case timeout to use until scans are > occasionally/intermittently failing in production, depending on variable scan > criteria. It would be better if the client-server scan protocol can send back > periodic progress heartbeats to clients as long as server scanners are alive > and making progress. > This is related but orthogonal to streaming scan (HBASE-13071). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13202) Procedure v2 - core framework
[ https://issues.apache.org/jira/browse/HBASE-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-13202: Attachment: HBASE-13202-v0-hbase-12439.patch > Procedure v2 - core framework > - > > Key: HBASE-13202 > URL: https://issues.apache.org/jira/browse/HBASE-13202 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Attachments: HBASE-13202-v0-hbase-12439.patch > > > core package, part of HBASE-12439 > this is just the proc-v2 submodule. it depends only on hbase-common. > https://reviews.apache.org/r/27703/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13202) Procedure v2 - core framework
[ https://issues.apache.org/jira/browse/HBASE-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-13202: Attachment: (was: HBASE-13202-v0-hbase-12439.patch) > Procedure v2 - core framework > - > > Key: HBASE-13202 > URL: https://issues.apache.org/jira/browse/HBASE-13202 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Attachments: HBASE-13202-v0-hbase-12439.patch > > > core package, part of HBASE-12439 > this is just the proc-v2 submodule. it depends only on hbase-common. > https://reviews.apache.org/r/27703/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
[ https://issues.apache.org/jira/browse/HBASE-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361199#comment-14361199 ] Andrew Purtell commented on HBASE-13237: We have attempts at marks as '&\#153;' in site source but this doesn't produce TM marks, at least when viewed with Chrome. Let me try out the Unicode for this &\#8482; instead. > Improve trademark marks on the hbase.apache.org homepage > > > Key: HBASE-13237 > URL: https://issues.apache.org/jira/browse/HBASE-13237 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0 > > > Ensure trademark marks are next to first and prominent uses of "HBase" on the > hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners
[ https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Lawlor updated HBASE-13090: Attachment: HBASE-13090-v3.patch - Fix checkstyle, line lengths, and some whitespace > Progress heartbeats for long running scanners > - > > Key: HBASE-13090 > URL: https://issues.apache.org/jira/browse/HBASE-13090 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Jonathan Lawlor > Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch, > HBASE-13090-v3.patch > > > It can be necessary to set very long timeouts for clients that issue scans > over large regions when all data in the region might be filtered out > depending on scan criteria. This is a usability concern because it can be > hard to identify what worst case timeout to use until scans are > occasionally/intermittently failing in production, depending on variable scan > criteria. It would be better if the client-server scan protocol can send back > periodic progress heartbeats to clients as long as server scanners are alive > and making progress. > This is related but orthogonal to streaming scan (HBASE-13071). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13090) Progress heartbeats for long running scanners
[
https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361181#comment-14361181
]
Hadoop QA commented on HBASE-13090:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704509/HBASE-13090-v2.patch
against master branch at commit e60cae0500daf3c146e10d808c5070c6cb24ecec.
ATTACHMENT ID: 12704509
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 28 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1918 checkstyle errors (more than the master's current 1917 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ result = result && (hasClientHandlesHeartbeatMessages() ==
other.hasClientHandlesHeartbeatMessages());
+ new java.lang.String[] { "Region", "Scan", "ScannerId",
"NumberOfRows", "CloseScanner", "NextCallSeq", "ClientHandlesPartials",
"ClientHandlesHeartbeatMessages", });
+ new java.lang.String[] { "CellsPerResult", "ScannerId",
"MoreResults", "Ttl", "Results", "Stale", "PartialFlagPerResult",
"HeartbeatMessage", });
+ || !Bytes.equals(row, offset, length, matcher.row,
matcher.rowOffset, matcher.rowLength)) {
+public ScanResponse scan(RpcController controller, ScanRequest request)
throws ServiceException {
+public HeartbeatReversedKVHeap(List scanners,
KVComparator comparator)
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13232//console
This message is automatically generated.
> Progress heartbeats for long running scanners
> -
>
> Key: HBASE-13090
> URL: https://issues.apache.org/jira/browse/HBASE-13090
> Project: HBase
> Issue Type: New Feature
>Reporter: Andrew Purtell
>Assignee: Jonathan Lawlor
> Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch
>
>
> It can be necessary to set very long timeouts for clients that issue scans
> o
[jira] [Commented] (HBASE-13238) Time out locks and abort if HDFS is wedged
[ https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361174#comment-14361174 ] Andrew Purtell commented on HBASE-13238: Of course, why we propose aborts is the DFSClient is not interruptible. There are several places where the DFSClient swallows interrupts. > Time out locks and abort if HDFS is wedged > -- > > Key: HBASE-13238 > URL: https://issues.apache.org/jira/browse/HBASE-13238 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell > > This is a brainstorming issue on the topic of timing out locks and aborting > rather than waiting infinitely. Perhaps even as a rule. > We had a minor production incident where a region was unable to close after > trying for 24 hours. The CloseRegionHandler was waiting for a write lock on > the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding > read locks. Three other threads were stuck in scanning, all blocked on the > same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the > third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with > apparent infinite timeout from PacketReceiver#readChannelFully. > This is similar to other issues we have seen before, in the context of the > region wanting to finish a compaction before closing for a split, but can't > due to some HDFS issue causing the reader to become extremely slow if not > wedged. This has lead to what should be quick SplitTransactions causing > availability problems of many minutes in length. > The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning > to upgrade, but [~lhofhansl] and I were discussing the issue in general and > wonder if we should not be timing out locks such as the > ReentrantReadWriteLock, and if so, abort the regionserver. In this case this > would have caused recovery and reassignment of the region in question and we > would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13238) Time out locks and abort if HDFS is wedged
[ https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13238: --- Description: This is a brainstorming issue on the topic of timing out locks and aborting rather than waiting infinitely. Perhaps even as a rule. We had a minor production incident where a region was unable to close after trying for 24 hours. The CloseRegionHandler was waiting for a write lock on the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding read locks. Three other threads were stuck in scanning, all blocked on the same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with apparent infinite timeout from PacketReceiver#readChannelFully. This is similar to other issues we have seen before, in the context of the region wanting to finish a compaction before closing for a split, but can't due to some HDFS issue causing the reader to become extremely slow if not wedged. This has lead to what should be quick SplitTransactions causing availability problems of many minutes in length. The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning to upgrade, but [~lhofhansl] and I were discussing the issue in general and wonder if we should not be timing out locks such as the ReentrantReadWriteLock, and if so, abort the regionserver. In this case this would have caused recovery and reassignment of the region in question and we would not have had a prolonged availability problem. was: This is a brainstorming issue on the topic of timing out locks and aborting rather than waiting infinitely. Perhaps even as a rule. We had a minor production incident where a region was unable to close after trying for 24 hours. The CloseRegionHandler was waiting for a write lock on the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding read locks. Three other threads were stuck in scanning, all blocked on the same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with apparent infinite timeout from PacketReceiver#readChannelFully. This is similar to other issues we have seen before, in the context of the region wanting to finish a compaction, but can't due to some HDFS issue causing the reader to become extremely slow if not wedged. The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning to upgrade, but [~lhofhansl] and I were discussing the issue in general and wonder if we should not be timing out locks such as the ReentrantReadWriteLock, and if so, abort the regionserver. In this case this would have caused recovery and reassignment of the region in question and we would not have had a prolonged availability problem. > Time out locks and abort if HDFS is wedged > -- > > Key: HBASE-13238 > URL: https://issues.apache.org/jira/browse/HBASE-13238 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell > > This is a brainstorming issue on the topic of timing out locks and aborting > rather than waiting infinitely. Perhaps even as a rule. > We had a minor production incident where a region was unable to close after > trying for 24 hours. The CloseRegionHandler was waiting for a write lock on > the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding > read locks. Three other threads were stuck in scanning, all blocked on the > same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the > third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with > apparent infinite timeout from PacketReceiver#readChannelFully. > This is similar to other issues we have seen before, in the context of the > region wanting to finish a compaction before closing for a split, but can't > due to some HDFS issue causing the reader to become extremely slow if not > wedged. This has lead to what should be quick SplitTransactions causing > availability problems of many minutes in length. > The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning > to upgrade, but [~lhofhansl] and I were discussing the issue in general and > wonder if we should not be timing out locks such as the > ReentrantReadWriteLock, and if so, abort the regionserver. In this case this > would have caused recovery and reassignment of the region in question and we > would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13238) Time out locks and abort if HDFS is wedged
[ https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13238: --- Description: This is a brainstorming issue on the topic of timing out locks and aborting rather than waiting infinitely. Perhaps even as a rule. We had a minor production incident where a region was unable to close after trying for 24 hours. The CloseRegionHandler was waiting for a write lock on the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding read locks. Three other threads were stuck in scanning, all blocked on the same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with apparent infinite timeout from PacketReceiver#readChannelFully. This is similar to other issues we have seen before, in the context of the region wanting to finish a compaction, but can't due to some HDFS issue causing the reader to become extremely slow if not wedged. The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning to upgrade, but [~lhofhansl] and I were discussing the issue in general and wonder if we should not be timing out locks such as the ReentrantReadWriteLock, and if so, abort the regionserver. In this case this would have caused recovery and reassignment of the region in question and we would not have had a prolonged availability problem. was: This is a brainstorming issue on the topic of timing out locks and aborting rather than waiting infinitely. Perhaps even as a rule. We had a minor production incident where a region was unable to close after 24 hours. The CloseRegionHandler was waiting for a write lock on the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding read locks. Three other threads were stuck in scanning, all blocked on the same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with apparent infinite timeout from PacketReceiver#readChannelFully. This is similar to other issues we have seen before, in the context of the region wanting to finish a compaction, but can't due to some HDFS issue causing the reader to become extremely slow if not wedged. The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning to upgrade, but [~lhofhansl] and I were discussing the issue in general and wonder if we should not be timing out locks such as the ReentrantReadWriteLock, and if so, abort the regionserver. In this case this would have caused recovery and reassignment of the region in question and we would not have had a prolonged availability problem. > Time out locks and abort if HDFS is wedged > -- > > Key: HBASE-13238 > URL: https://issues.apache.org/jira/browse/HBASE-13238 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell > > This is a brainstorming issue on the topic of timing out locks and aborting > rather than waiting infinitely. Perhaps even as a rule. > We had a minor production incident where a region was unable to close after > trying for 24 hours. The CloseRegionHandler was waiting for a write lock on > the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding > read locks. Three other threads were stuck in scanning, all blocked on the > same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the > third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with > apparent infinite timeout from PacketReceiver#readChannelFully. > This is similar to other issues we have seen before, in the context of the > region wanting to finish a compaction, but can't due to some HDFS issue > causing the reader to become extremely slow if not wedged. > The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning > to upgrade, but [~lhofhansl] and I were discussing the issue in general and > wonder if we should not be timing out locks such as the > ReentrantReadWriteLock, and if so, abort the regionserver. In this case this > would have caused recovery and reassignment of the region in question and we > would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13238) Time out locks and abort if HDFS is wedged
[ https://issues.apache.org/jira/browse/HBASE-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13238: --- Description: This is a brainstorming issue on the topic of timing out locks and aborting rather than waiting infinitely. Perhaps even as a rule. We had a minor production incident where a region was unable to close after 24 hours. The CloseRegionHandler was waiting for a write lock on the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding read locks. Three other threads were stuck in scanning, all blocked on the same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with apparent infinite timeout from PacketReceiver#readChannelFully. This is similar to other issues we have seen before, in the context of the region wanting to finish a compaction, but can't due to some HDFS issue causing the reader to become extremely slow if not wedged. The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning to upgrade, but [~lhofhansl] and I were discussing the issue in general and wonder if we should not be timing out locks such as the ReentrantReadWriteLock, and if so, abort the regionserver. In this case this would have caused recovery and reassignment of the region in question and we would not have had a prolonged availability problem. was: This is a brainstorming issue on the top of timing out locks and aborting if HDFS is wedged. We had a minor production incident where a region was unable to close after 24 hours. The CloseRegionHandler was waiting for a write lock on the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding read locks. Three other threads were stuck in scanning, all blocked on the same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with apparent infinite timeout from PacketReceiver#readChannelFully. This is similar to other issues we have seen before, in the context of the region wanting to finish a compaction, but can't due to some HDFS issue causing the reader to become extremely slow if not wedged. The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning to upgrade, but [~lhofhansl] and I were discussing the issue in general and wonder if we should not be timing out locks such as the ReentrantReadWriteLock, and if so, abort the regionserver. In this case this would have caused recovery and reassignment of the region in question and we would not have had a prolonged availability problem. > Time out locks and abort if HDFS is wedged > -- > > Key: HBASE-13238 > URL: https://issues.apache.org/jira/browse/HBASE-13238 > Project: HBase > Issue Type: Brainstorming >Reporter: Andrew Purtell > > This is a brainstorming issue on the topic of timing out locks and aborting > rather than waiting infinitely. Perhaps even as a rule. > We had a minor production incident where a region was unable to close after > 24 hours. The CloseRegionHandler was waiting for a write lock on the > ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding > read locks. Three other threads were stuck in scanning, all blocked on the > same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the > third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with > apparent infinite timeout from PacketReceiver#readChannelFully. > This is similar to other issues we have seen before, in the context of the > region wanting to finish a compaction, but can't due to some HDFS issue > causing the reader to become extremely slow if not wedged. > The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning > to upgrade, but [~lhofhansl] and I were discussing the issue in general and > wonder if we should not be timing out locks such as the > ReentrantReadWriteLock, and if so, abort the regionserver. In this case this > would have caused recovery and reassignment of the region in question and we > would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13238) Time out locks and abort if HDFS is wedged
Andrew Purtell created HBASE-13238: -- Summary: Time out locks and abort if HDFS is wedged Key: HBASE-13238 URL: https://issues.apache.org/jira/browse/HBASE-13238 Project: HBase Issue Type: Brainstorming Reporter: Andrew Purtell This is a brainstorming issue on the top of timing out locks and aborting if HDFS is wedged. We had a minor production incident where a region was unable to close after 24 hours. The CloseRegionHandler was waiting for a write lock on the ReentrantReadWriteLock we take in HRegion#doClose. There were outstanding read locks. Three other threads were stuck in scanning, all blocked on the same DFSInputStream. Two were blocked in DFSInputStream#getFileLength, the third was waiting in epoll from SocketIOWithTimeout$SelectorPool#select with apparent infinite timeout from PacketReceiver#readChannelFully. This is similar to other issues we have seen before, in the context of the region wanting to finish a compaction, but can't due to some HDFS issue causing the reader to become extremely slow if not wedged. The Hadoop version was 2.3 (specifically 2.3 CDH 5.0.1), and we are planning to upgrade, but [~lhofhansl] and I were discussing the issue in general and wonder if we should not be timing out locks such as the ReentrantReadWriteLock, and if so, abort the regionserver. In this case this would have caused recovery and reassignment of the region in question and we would not have had a prolonged availability problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-13236:
Assignee: Josh Elser
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361153#comment-14361153
]
Josh Elser commented on HBASE-13236:
(Ugh, no edit privs). Applies cleanly and works as intended on 0.98 as well.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361150#comment-14361150
]
Josh Elser commented on HBASE-13236:
For you? Not at all.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361148#comment-14361148
]
Sean Busbey commented on HBASE-13236:
-
would you mind checking the 0.98 branch?
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361146#comment-14361146
]
Josh Elser commented on HBASE-13236:
Haha, I guess I could've been slightly more explicit on the end result :P
With this patch, I can import branch-1 and master into Eclipse without any
errors or additional dialogs to click through.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361137#comment-14361137
]
Josh Elser commented on HBASE-13236:
n/m, same patch should apply on branch-1. I thought they were different.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361141#comment-14361141
]
Sean Busbey commented on HBASE-13236:
-
I don't have an eclipse install to test the impact of this on locally. But the
changes look reasonable. Presuming it fixes things for you, I'm +1 pending
jenkins.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361138#comment-14361138
]
Josh Elser commented on HBASE-13236:
Ah, thanks for the clarification, Sean.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13237) Improve trademark marks on the hbase.apache.org homepage
Andrew Purtell created HBASE-13237: -- Summary: Improve trademark marks on the hbase.apache.org homepage Key: HBASE-13237 URL: https://issues.apache.org/jira/browse/HBASE-13237 Project: HBase Issue Type: Task Components: documentation Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 2.0.0 Ensure trademark marks are next to first and prominent uses of "HBase" on the hbase.apache.org homepage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361136#comment-14361136
]
Sean Busbey commented on HBASE-13236:
-
unless there's some difficulty in backporting, the committer will take care of
bringing the change back to earlier branches.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-13236:
---
Status: Patch Available (was: Open)
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13236) Clean up m2e-related warnings/errors from poms
[
https://issues.apache.org/jira/browse/HBASE-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-13236:
---
Attachment: HBASE-13236-master.patch
Patch for master, branch-1 incoming.
> Clean up m2e-related warnings/errors from poms
> --
>
> Key: HBASE-13236
> URL: https://issues.apache.org/jira/browse/HBASE-13236
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13236-master.patch
>
>
> Pulled down HBase, imported into Eclipse (either directly with m2eclipse or
> by running {{mvn eclipse:eclipse}} to generate the projects), and this
> results in a bunch of red due to executions/goals of certain plugins being
> unable to run in the context of eclipse.
> The lifecycle-mapping "plugin" can be used to get around these errors (and
> already exists in the pom).
> Add more mappings to the configuration so that a fresh import into Eclipse is
> not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners
[ https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Lawlor updated HBASE-13090: Attachment: HBASE-13090-v2.patch Attaching a patch that includes the ScannerLimit idea. It does seem to make things a little nicer and presents a cleaner interface for dealing with RegionScanner#next() and InternalScanner#next when many limits need to be specified. What do you guys think? This patch has also managed to get rid of the ugly postHeapNext method that was included before. Now in tests we use a custom key value heap class to insert delays between column family fetches to simulate long running scans on the server side. I am still looking into how I could remove the sleeps and replace them with latches. Will update reviewboard with latest diff > Progress heartbeats for long running scanners > - > > Key: HBASE-13090 > URL: https://issues.apache.org/jira/browse/HBASE-13090 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Jonathan Lawlor > Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch > > > It can be necessary to set very long timeouts for clients that issue scans > over large regions when all data in the region might be filtered out > depending on scan criteria. This is a usability concern because it can be > hard to identify what worst case timeout to use until scans are > occasionally/intermittently failing in production, depending on variable scan > criteria. It would be better if the client-server scan protocol can send back > periodic progress heartbeats to clients as long as server scanners are alive > and making progress. > This is related but orthogonal to streaming scan (HBASE-13071). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13236) Clean up m2e-related warnings/errors from poms
Josh Elser created HBASE-13236:
--
Summary: Clean up m2e-related warnings/errors from poms
Key: HBASE-13236
URL: https://issues.apache.org/jira/browse/HBASE-13236
Project: HBase
Issue Type: Improvement
Components: build
Reporter: Josh Elser
Priority: Minor
Fix For: 2.0.0, 1.1.0
Pulled down HBase, imported into Eclipse (either directly with m2eclipse or by
running {{mvn eclipse:eclipse}} to generate the projects), and this results in
a bunch of red due to executions/goals of certain plugins being unable to run
in the context of eclipse.
The lifecycle-mapping "plugin" can be used to get around these errors (and
already exists in the pom).
Add more mappings to the configuration so that a fresh import into Eclipse is
not hindered by a bunch of "false' errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13227) LoadIncrementalHFile should skip non-files inside a possible family-dir
[ https://issues.apache.org/jira/browse/HBASE-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361117#comment-14361117 ] Hudson commented on HBASE-13227: FAILURE: Integrated in HBase-0.98 #898 (See [https://builds.apache.org/job/HBase-0.98/898/]) HBASE-13227 LoadIncrementalHFile should skip non-files inside a possible family-dir (addendum) (matteo.bertozzi: rev 3c776ff280cdd42542429d82ad2d1d88f73855e2) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > LoadIncrementalHFile should skip non-files inside a possible family-dir > --- > > Key: HBASE-13227 > URL: https://issues.apache.org/jira/browse/HBASE-13227 > Project: HBase > Issue Type: Bug > Components: Client, mapreduce >Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.11 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: HBASE-13227-addendum-0.98.patch, HBASE-13227-v0.patch > > > if we have random files/dirs inside the bulkload family dir, we should try to > skip them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13202) Procedure v2 - core framework
[
https://issues.apache.org/jira/browse/HBASE-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361109#comment-14361109
]
Hadoop QA commented on HBASE-13202:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12704488/HBASE-13202-v0-hbase-12439.patch
against hbase-12439 branch at commit b21fa7c65241fdff7ee1c6523cb4db5c1e263433.
ATTACHMENT ID: 12704488
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 16 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1918 checkstyle errors (more than the master's current 1917 errors).
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
+ if (!((mutable_bitField0_ & 0x0040) == 0x0040) &&
input.getBytesUntilLimit() > 0) {
+ "me\030\004 \002(\004\022\r\n\005owner\030\005
\001(\t\022\036\n\005state\030\006 \002(\0162\017" +
+ new java.lang.String[] { "ClassName", "ParentId", "ProcId",
"StartTime", "Owner", "State", "StackId", "LastUpdate", "Timeout", "Exception",
"Result", "StateData", });
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-procedure.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13231//console
This message is automatically generated.
> Procedure v2 - core framework
> -
>
> Key: HBASE-13202
> URL: https://issues.apache.org/jira/browse/HBASE-13202
> Project: HBase
> Issue Type: Sub-task
> Components: master
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-13202-v0-hbase-12439.patch
>
>
> core package, part of HBASE-12439
> this is just the proc-v2 submodule. it de
[jira] [Commented] (HBASE-13227) LoadIncrementalHFile should skip non-files inside a possible family-dir
[ https://issues.apache.org/jira/browse/HBASE-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361095#comment-14361095 ] Hudson commented on HBASE-13227: SUCCESS: Integrated in HBase-0.98 #897 (See [https://builds.apache.org/job/HBase-0.98/897/]) HBASE-13227 LoadIncrementalHFile should skip non-files inside a possible family-dir (matteo.bertozzi: rev 2f831915d86359785395b8bdd6d6ba2698dc2ef0) * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestLoadIncrementalHFiles.java * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > LoadIncrementalHFile should skip non-files inside a possible family-dir > --- > > Key: HBASE-13227 > URL: https://issues.apache.org/jira/browse/HBASE-13227 > Project: HBase > Issue Type: Bug > Components: Client, mapreduce >Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.11 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: HBASE-13227-addendum-0.98.patch, HBASE-13227-v0.patch > > > if we have random files/dirs inside the bulkload family dir, we should try to > skip them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
