[jira] [Commented] (HBASE-12853) distributed write pattern to replace ad hoc 'salting'
[ https://issues.apache.org/jira/browse/HBASE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291765#comment-14291765 ] Michael Segel commented on HBASE-12853: Before we go in to a design, I need to get a bit more information. As a practice, I don't review HBase source code and work from the exposed APIs. Of course looking at the HBase API these days is a bit of a CF since most of the APIs are deprecated referring to other deprecated classes / interfaces etc ... not to mention there a couple of different releases... So we start with a Connection instance which we get a instance of class Table for the given table. Ignoring put() for a moment, we have get() and getScanner() methods. What happens on the server side of the connection when the client calls getScanner() or get() ? Part of the issue is that a simple scanner won't work right unless you end up preprocessing it and treating it as a scanner but with a default (blank) set of filters. So while I can walk you through the logic and give you a resulting diagram, I need a committer who's familiar with the server side workings. Then it should be a pretty straight forward thing to implement. -Mike distributed write pattern to replace ad hoc 'salting' - Key: HBASE-12853 URL: https://issues.apache.org/jira/browse/HBASE-12853 Project: HBase Issue Type: New Feature Reporter: Michael Segel Priority: Minor In reviewing HBASE-11682 (Description of Hot Spotting), one of the issues is that while 'salting' alleviated regional hot spotting, it increased the complexity required to utilize the data. Through the use of coprocessors, it should be possible to offer a method which distributes the data on write across the cluster and then manages reading the data returning a sort ordered result set, abstracting the underlying process. On table creation, a flag is set to indicate that this is a parallel table. On insert in to the table, if the flag is set to true then a prefix is added to the key. e.g. region server#- or region server #|| where the region server # is an integer between 1 and the number of region servers defined. On read (scan) for each region server defined, a separate scan is created adding the prefix. Since each scan will be in sort order, its possible to strip the prefix and return the lowest value key from each of the subsets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12902) Post-asciidoc conversion fix-ups
[
https://issues.apache.org/jira/browse/HBASE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291790#comment-14291790
]
Lars George commented on HBASE-12902:
-
Well, it does _not_ lool lovely. The main issue, i.e. that the hierarchy is
stuffed (see the middle part of our conversation above) is not fixed. There
should not be 140+ sections listed in the final document. This is caused by the
major section heading not counted and all subsection being promoted to the
major level. Needs fixing. Either reopen or create new issue?
Post-asciidoc conversion fix-ups
Key: HBASE-12902
URL: https://issues.apache.org/jira/browse/HBASE-12902
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Misty Stanley-Jones
Assignee: Misty Stanley-Jones
Fix For: 2.0.0
Attachments: HBASE-12902.patch
- Put HBase logo back on book
- Remove docbkx building instructions and make sure asciidoc building
instructions are solid
- Several feedback items from [~larsgeorge]:
{quote}
Lars George
Jan-19 8:45 pm
@misty Something is off with Table1, no?
https://github.com/apache/hbase/blob/master/src/main/asciidoc/_chapters/getting_started.adoc#24-adva...
Lars George
Jan-19 8:45 pm
Is seems like a header for a table, but has no content
Misty Stanley-Jones
Jan-19 8:47 pm
yes you are right
Lars George
Jan-19 8:47 pm
@misty yeah, it is missing the node-a etc in the first column and the Xs (I
presume) in the others for the assignment
{quote}
{quote}
Lars George
Jan-19 11:53 pm
@misty 2.4 (or was it 2.3, but it is at the end of that section) and 5. are
messing up the ports for the UIs
Lars George
Jan-19 11:56 pm
@misty there is a stray section between 2.5 and 3. that seems lost and out of
place.
Tuesday January 20, 2015
Lars George
Jan-20 12:04 am
@misty hbase.balancer.period in the section with the parsed hbase-default.xml
is borked
Lars George
Jan-20 12:05 am
A few more below that are also borked
Lars George
Jan-20 12:15 am
This is 6.2 btw
Lars George
Jan-20 12:16 am
There are quite a few where Description is missing and the actual
description is printed as Courier font text, like the property name
Lars George
Jan-20 12:17 am
@misty That dangling section between 2.5 and 3. seems redundant, as 6.x
explain them all. Unless the former is for the quickstart section?
Lars George
Jan-20 12:41 am
@misty 11.1 also stuffs up the ports, the new master port in this case
Lars George
Jan-20 12:43 am
@misty in general the upgrading sections should be subsections (11, 12, 13,
etc should be no major sections)
Lars George
Jan-20 12:45 am
@misty between 17. and 18. is another dangling section with no numbering
Lars George
Jan-20 12:47 am
And again, 18., 19., 20. etc should be one major section with subsections,
not all major section on their own
Lars George
Jan-20 12:47 am
I presume now that that dangling section between 17. and 18. is the Intro and
the other should be beneath it. I guess also then this is the same for
earlier issues with section placements.
Lars George
Jan-20 12:51 am
Yeah, same for 23.5 to 24., the Data Model is the intro but shows up dangling
and all else is moved up the hierarchy
Lars George
Jan-20 1:19 am
@misty 38. (or whatever that really is now that I noticed the broken
hierarchy) is also out of date.
Lars George
Jan-20 1:20 am
(well decoupled flushing is still being worked on though)
{quote}
{quote}
Lars George
Jan-20 8:05 pm
@misty 70.5 the lead into the bulleted list is borked, it appears as part of
the first item
Lars George
Jan-20 8:06 pm
@misty and did you see those other 20+ message I sent earlier? Just checking
you se them
Lars George
Jan-20 8:08 pm
oh, and a spell check run would not be the worst idea. Some later content is
off.
Lars George
Jan-20 8:27 pm
@misty Same issue with bulleted list in 70.7.7 - I assume this is a wider
issue after conversion?
Lars George
Jan-20 8:39 pm
@misty Parameters Used by Compaction Algorithm the table is broken
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12917) HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to recursive loop in createCell function
[
https://issues.apache.org/jira/browse/HBASE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291794#comment-14291794
]
Hadoop QA commented on HBASE-12917:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694527/HBASE-12917.patch
against master branch at commit 1c1a306b2e4bdd5a4ff877634c5064097637e2f2.
ATTACHMENT ID: 12694527
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 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:
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12585//console
This message is automatically generated.
HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to
recursive loop in createCell function
---
Key: HBASE-12917
URL: https://issues.apache.org/jira/browse/HBASE-12917
Project: HBase
Issue Type: Bug
Components: hbase
Affects Versions: 2.0.0
Environment: Ubuntu
Reporter: Vikas Vishwakarma
Assignee: Vikas Vishwakarma
Fix For: 2.0.0
Attachments: HBASE-12917.patch
While trying to run HFilePerformanceEvaluation with hbase-2.0.0
UniformRandomSmallScan is failing with StackOverflowError. Lookes related to
the byte array to Cell based HFile changes.
2015-01-26 12:42:09,551 WARN [main] util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
2015-01-26 12:42:09,760 INFO [main] hbase.HFilePerformanceEvaluation:
Running SequentialWriteBenchmark for 100 rows.
2015-01-26 12:42:10,007 INFO [main] hfile.CacheConfig: CacheConfig:disabled
2015-01-26 12:42:11,560 INFO [main] hbase.HFilePerformanceEvaluation:
Running SequentialWriteBenchmark for 100 rows took 1496ms.
2015-01-26
[jira] [Commented] (HBASE-12684) Add new AsyncRpcClient
[ https://issues.apache.org/jira/browse/HBASE-12684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291872#comment-14291872 ] Jurriaan Mous commented on HBASE-12684: --- [~stack] Nice! Thanks for the commit. :) I will send a mail about it to the mailing list later today! Add new AsyncRpcClient -- Key: HBASE-12684 URL: https://issues.apache.org/jira/browse/HBASE-12684 Project: HBase Issue Type: Improvement Components: Client Reporter: Jurriaan Mous Assignee: Jurriaan Mous Fix For: 2.0.0, 1.1.0 Attachments: HBASE-12684-DEBUG2.patch, HBASE-12684-DEBUG3.patch, HBASE-12684-v1.patch, HBASE-12684-v10.patch, HBASE-12684-v11.patch, HBASE-12684-v12.patch, HBASE-12684-v13.patch, HBASE-12684-v14.patch, HBASE-12684-v15.patch, HBASE-12684-v16.patch, HBASE-12684-v17.patch, HBASE-12684-v17.patch, HBASE-12684-v18.patch, HBASE-12684-v19.1.patch, HBASE-12684-v19.patch, HBASE-12684-v19.patch, HBASE-12684-v2.patch, HBASE-12684-v20-heapBuffer.patch, HBASE-12684-v20.patch, HBASE-12684-v21-heapBuffer.1.patch, HBASE-12684-v21-heapBuffer.patch, HBASE-12684-v21.patch, HBASE-12684-v22.patch, HBASE-12684-v23-epoll.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v25.patch, HBASE-12684-v26.patch, HBASE-12684-v27.patch, HBASE-12684-v27.patch, HBASE-12684-v28.patch, HBASE-12684-v29.patch, HBASE-12684-v3.patch, HBASE-12684-v30.patch, HBASE-12684-v30.patch, HBASE-12684-v30.patch, HBASE-12684-v31.patch, HBASE-12684-v31.patch, HBASE-12684-v31.patch, HBASE-12684-v4.patch, HBASE-12684-v5.patch, HBASE-12684-v6.patch, HBASE-12684-v7.patch, HBASE-12684-v8.patch, HBASE-12684-v9.patch, HBASE-12684.patch, Screen Shot 2015-01-11 at 11.55.32 PM.png, myrecording.jfr, q.png, requests.png With the changes in HBASE-12597 it is possible to add new RpcClients. This issue is about adding a new Async RpcClient which would enable HBase to do non blocking protobuf service communication. Besides delivering a new AsyncRpcClient I would also like to ask the question what it would take to replace the current RpcClient? This would enable to simplify async code in some next issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-7024) TableMapReduceUtil.initTableMapperJob unnecessarily limits the types of outputKeyClass and outputValueClass
[ https://issues.apache.org/jira/browse/HBASE-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291802#comment-14291802 ] Will Temperley commented on HBASE-7024: --- This is marked as fixed, but the unnecessary restrictions on the types of outputKeyClass and outputValueClass are still in place. TableMapReduceUtil.initTableMapperJob unnecessarily limits the types of outputKeyClass and outputValueClass --- Key: HBASE-7024 URL: https://issues.apache.org/jira/browse/HBASE-7024 Project: HBase Issue Type: Improvement Components: mapreduce Reporter: Dave Beech Priority: Minor Fix For: 0.95.0 Attachments: HBASE-7024.patch The various initTableMapperJob methods in TableMapReduceUtil take outputKeyClass and outputValueClass parameters which need to extend WritableComparable and Writable respectively. Because of this, it is not convenient to use an alternative serialization like Avro. (I wanted to set these parameters to AvroKey and AvroValue). The methods in the MapReduce API to set map output key and value types do not impose this restriction, so is there a reason to do it here? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-7024) TableMapReduceUtil.initTableMapperJob unnecessarily limits the types of outputKeyClass and outputValueClass
[ https://issues.apache.org/jira/browse/HBASE-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Temperley updated HBASE-7024: -- Attachment: HBASE-7024-multiscan.patch This patch removes unnecessary limits on types in some method overloads which were missed by the previous patch TableMapReduceUtil.initTableMapperJob unnecessarily limits the types of outputKeyClass and outputValueClass --- Key: HBASE-7024 URL: https://issues.apache.org/jira/browse/HBASE-7024 Project: HBase Issue Type: Improvement Components: mapreduce Reporter: Dave Beech Priority: Minor Fix For: 0.95.0 Attachments: HBASE-7024-multiscan.patch, HBASE-7024.patch The various initTableMapperJob methods in TableMapReduceUtil take outputKeyClass and outputValueClass parameters which need to extend WritableComparable and Writable respectively. Because of this, it is not convenient to use an alternative serialization like Avro. (I wanted to set these parameters to AvroKey and AvroValue). The methods in the MapReduce API to set map output key and value types do not impose this restriction, so is there a reason to do it here? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12684) Add new AsyncRpcClient
[ https://issues.apache.org/jira/browse/HBASE-12684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291974#comment-14291974 ] Nicolas Liochon commented on HBASE-12684: - Sorry, I'm seeing this only now (I missed the message on the 15th), but yep, I like this. And I like the configurable RPC implementation, great as well. Add new AsyncRpcClient -- Key: HBASE-12684 URL: https://issues.apache.org/jira/browse/HBASE-12684 Project: HBase Issue Type: Improvement Components: Client Reporter: Jurriaan Mous Assignee: Jurriaan Mous Fix For: 2.0.0, 1.1.0 Attachments: HBASE-12684-DEBUG2.patch, HBASE-12684-DEBUG3.patch, HBASE-12684-v1.patch, HBASE-12684-v10.patch, HBASE-12684-v11.patch, HBASE-12684-v12.patch, HBASE-12684-v13.patch, HBASE-12684-v14.patch, HBASE-12684-v15.patch, HBASE-12684-v16.patch, HBASE-12684-v17.patch, HBASE-12684-v17.patch, HBASE-12684-v18.patch, HBASE-12684-v19.1.patch, HBASE-12684-v19.patch, HBASE-12684-v19.patch, HBASE-12684-v2.patch, HBASE-12684-v20-heapBuffer.patch, HBASE-12684-v20.patch, HBASE-12684-v21-heapBuffer.1.patch, HBASE-12684-v21-heapBuffer.patch, HBASE-12684-v21.patch, HBASE-12684-v22.patch, HBASE-12684-v23-epoll.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v24.patch, HBASE-12684-v25.patch, HBASE-12684-v26.patch, HBASE-12684-v27.patch, HBASE-12684-v27.patch, HBASE-12684-v28.patch, HBASE-12684-v29.patch, HBASE-12684-v3.patch, HBASE-12684-v30.patch, HBASE-12684-v30.patch, HBASE-12684-v30.patch, HBASE-12684-v31.patch, HBASE-12684-v31.patch, HBASE-12684-v31.patch, HBASE-12684-v4.patch, HBASE-12684-v5.patch, HBASE-12684-v6.patch, HBASE-12684-v7.patch, HBASE-12684-v8.patch, HBASE-12684-v9.patch, HBASE-12684.patch, Screen Shot 2015-01-11 at 11.55.32 PM.png, myrecording.jfr, q.png, requests.png With the changes in HBASE-12597 it is possible to add new RpcClients. This issue is about adding a new Async RpcClient which would enable HBase to do non blocking protobuf service communication. Besides delivering a new AsyncRpcClient I would also like to ask the question what it would take to replace the current RpcClient? This would enable to simplify async code in some next issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12745) Visibility Labels: support visibility labels for user groups.
[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-12745:
---
Attachment: hbase-12745_branch-1-addendum2.patch
Visibility Labels: support visibility labels for user groups.
--
Key: HBASE-12745
URL: https://issues.apache.org/jira/browse/HBASE-12745
Project: HBase
Issue Type: Improvement
Components: security
Affects Versions: 1.0.0, 0.98.9, 0.99.2
Reporter: Jerry He
Assignee: Jerry He
Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0
Attachments: HBASE-12745-master-v1.patch,
HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
HBASE-12745-v7-0.98-with-update.patch, HBASE-12745-v7-0.98.patch,
HBASE-12745-v7-branch1.patch, hbase-12745_branch-1-addendum.patch,
hbase-12745_branch-1-addendum2.patch
The thinking is that we should support visibility labels to be associated
with user groups.
We will then be able grant visibility labels to a group in addition to
individual users, which provides convenience and usability.
We will use '@group' to denote a group name, as similarly done in
AcccessController.
For example,
{code}
set_auths '@group1', ['SECRET','PRIVATE']
{code}
{code}
get_auth '@group1'
{code}
A user belonging to 'group1' will have all the visibility labels granted to
'group1'
We'll also support super user groups as specified in hbase-site.xml.
The code update will mainly be on the server side VisibilityLabelService
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-12922) Post-asciidoc conversion fix-ups part 2
Lars Francke created HBASE-12922: Summary: Post-asciidoc conversion fix-ups part 2 Key: HBASE-12922 URL: https://issues.apache.org/jira/browse/HBASE-12922 Project: HBase Issue Type: Bug Components: documentation Reporter: Lars Francke Assignee: Lars Francke I did read through large parts of the documentation and fixed what I found. Some of it is AsciiDoc stuff, some is contents, some is grammar, some typos fixed etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[
https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291948#comment-14291948
]
Ted Yu commented on HBASE-12915:
From QA report:
{code}
Failed tests:
TestHCM.testConnectionCloseAllowsInterrupt:293-testConnectionClose:405
Waiting timed out after [40,000] msec
{code}
This test fails in trunk consistently.
Flaky tests are not related to the patch.
Disallow small scan with batching
-
Key: HBASE-12915
URL: https://issues.apache.org/jira/browse/HBASE-12915
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 12915-001.txt, 12915-001.txt
If user sets batching in Scan object, ClientSmallScanner may return
unexpected result because data from same row may appear in multiple Result
objects but ClientSmallScanner considers different Results to correspond to
different rows.
Small scan with batching should be disallowed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12745) Visibility Labels: support visibility labels for user groups.
[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291971#comment-14291971
]
Anoop Sam John commented on HBASE-12745:
Ping [~enis] [~jerryhe]. Pls see addendum2
Visibility Labels: support visibility labels for user groups.
--
Key: HBASE-12745
URL: https://issues.apache.org/jira/browse/HBASE-12745
Project: HBase
Issue Type: Improvement
Components: security
Affects Versions: 1.0.0, 0.98.9, 0.99.2
Reporter: Jerry He
Assignee: Jerry He
Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0
Attachments: HBASE-12745-master-v1.patch,
HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
HBASE-12745-v7-0.98-with-update.patch, HBASE-12745-v7-0.98.patch,
HBASE-12745-v7-branch1.patch, hbase-12745_branch-1-addendum.patch,
hbase-12745_branch-1-addendum2.patch
The thinking is that we should support visibility labels to be associated
with user groups.
We will then be able grant visibility labels to a group in addition to
individual users, which provides convenience and usability.
We will use '@group' to denote a group name, as similarly done in
AcccessController.
For example,
{code}
set_auths '@group1', ['SECRET','PRIVATE']
{code}
{code}
get_auth '@group1'
{code}
A user belonging to 'group1' will have all the visibility labels granted to
'group1'
We'll also support super user groups as specified in hbase-site.xml.
The code update will mainly be on the server side VisibilityLabelService
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12922) Post-asciidoc conversion fix-ups part 2
[ https://issues.apache.org/jira/browse/HBASE-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated HBASE-12922: - Attachment: HBASE-12922.1.patch Post-asciidoc conversion fix-ups part 2 --- Key: HBASE-12922 URL: https://issues.apache.org/jira/browse/HBASE-12922 Project: HBase Issue Type: Bug Components: documentation Reporter: Lars Francke Assignee: Lars Francke Attachments: HBASE-12922.1.patch I did read through large parts of the documentation and fixed what I found. Some of it is AsciiDoc stuff, some is contents, some is grammar, some typos fixed etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12922) Post-asciidoc conversion fix-ups part 2
[ https://issues.apache.org/jira/browse/HBASE-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated HBASE-12922: - Status: Patch Available (was: Open) Post-asciidoc conversion fix-ups part 2 --- Key: HBASE-12922 URL: https://issues.apache.org/jira/browse/HBASE-12922 Project: HBase Issue Type: Bug Components: documentation Reporter: Lars Francke Assignee: Lars Francke Attachments: HBASE-12922.1.patch I did read through large parts of the documentation and fixed what I found. Some of it is AsciiDoc stuff, some is contents, some is grammar, some typos fixed etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12919) Compilation with Hadoop-2.4- is broken again
[
https://issues.apache.org/jira/browse/HBASE-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-12919:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
I've pushed this to branch-1.0+. Thanks Srikanth for quick patch.
Compilation with Hadoop-2.4- is broken again
Key: HBASE-12919
URL: https://issues.apache.org/jira/browse/HBASE-12919
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Srikanth Srungarapu
Attachments: HBASE-12919.patch
This is from the 1.0.0RC1 testing. I should have done the compilation before
the RC. Sorry for the noise.
{code}
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/Users/enis/projects/rc-test/hbase-1.0.0/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftHttpServlet.java:[98,18]
error: method authorize in class ProxyUsers cannot be applied to given types;
{code}
HBASE-12640 seems to be the offender. [~srikanth235], [~jxiang] FYI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12919) Compilation with Hadoop-2.4- is broken again
[
https://issues.apache.org/jira/browse/HBASE-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-12919:
--
Fix Version/s: 1.1.0
2.0.0
1.0.0
Compilation with Hadoop-2.4- is broken again
Key: HBASE-12919
URL: https://issues.apache.org/jira/browse/HBASE-12919
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Srikanth Srungarapu
Fix For: 1.0.0, 2.0.0, 1.1.0
Attachments: HBASE-12919.patch
This is from the 1.0.0RC1 testing. I should have done the compilation before
the RC. Sorry for the noise.
{code}
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/Users/enis/projects/rc-test/hbase-1.0.0/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftHttpServlet.java:[98,18]
error: method authorize in class ProxyUsers cannot be applied to given types;
{code}
HBASE-12640 seems to be the offender. [~srikanth235], [~jxiang] FYI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12921) Port HBASE-5356 'region_mover.rb can hang if table region it belongs to is deleted' to 0.94
[ https://issues.apache.org/jira/browse/HBASE-12921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292286#comment-14292286 ] Lars Hofhansl commented on HBASE-12921: --- +1 Sorry we missed backporting this back then. Would you like a new 0.94 release [~liushaohui]? Port HBASE-5356 'region_mover.rb can hang if table region it belongs to is deleted' to 0.94 --- Key: HBASE-12921 URL: https://issues.apache.org/jira/browse/HBASE-12921 Project: HBase Issue Type: Bug Affects Versions: 0.94.11 Environment: Reporter: Liu Shaohui Assignee: Liu Shaohui Priority: Minor Fix For: 0.94.28 Attachments: HBASE-12921-v1.diff This is backport of HBASE-5356 'region_mover.rb can hang if table region it belongs to is deleted' to 0.94. [~lhofhansl] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-7541) Convert all tests that use HBaseTestingUtility.createMultiRegions to HBA.createTable
[
https://issues.apache.org/jira/browse/HBASE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Lawlor updated HBASE-7541:
---
Attachment: HBASE_7541_v2_branch-1.txt
No worries; Just rebased, here's the patch
Convert all tests that use HBaseTestingUtility.createMultiRegions to
HBA.createTable
Key: HBASE-7541
URL: https://issues.apache.org/jira/browse/HBASE-7541
Project: HBase
Issue Type: Improvement
Reporter: Jean-Daniel Cryans
Assignee: Jonathan Lawlor
Fix For: 2.0.0
Attachments: HBASE7541_patch_v1.txt, HBASE_7541_v2.txt,
HBASE_7541_v2.txt, HBASE_7541_v2_branch-1.txt, HBASE_7541_v2_branch-1.txt
Like I discussed in HBASE-7534, {{HBaseTestingUtility.createMultiRegions}}
should disappear and not come back. There's about 25 different places in the
code that rely on it that need to be changed the same way I changed
TestReplication.
Perfect for someone that wants to get started with HBase dev :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292347#comment-14292347 ] Hudson commented on HBASE-12915: FAILURE: Integrated in HBase-TRUNK #6056 (See [https://builds.apache.org/job/HBase-TRUNK/6056/]) HBASE-12915 Disallow small scan with batching (tedyu: rev 26b8b48b4262695d900207adc13b32af6ed77875) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12919) Compilation with Hadoop-2.4- is broken again
[
https://issues.apache.org/jira/browse/HBASE-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292348#comment-14292348
]
Hudson commented on HBASE-12919:
FAILURE: Integrated in HBase-TRUNK #6056 (See
[https://builds.apache.org/job/HBase-TRUNK/6056/])
HBASE-12919 Compilation with Hadoop-2.4- is broken again (Srikanth Srungarapu)
(enis: rev 8241531f4390f9652770f8a82e1e3ea450941bbb)
*
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftHttpServlet.java
Compilation with Hadoop-2.4- is broken again
Key: HBASE-12919
URL: https://issues.apache.org/jira/browse/HBASE-12919
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Srikanth Srungarapu
Fix For: 1.0.0, 2.0.0, 1.1.0
Attachments: HBASE-12919.patch
This is from the 1.0.0RC1 testing. I should have done the compilation before
the RC. Sorry for the noise.
{code}
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/Users/enis/projects/rc-test/hbase-1.0.0/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftHttpServlet.java:[98,18]
error: method authorize in class ProxyUsers cannot be applied to given types;
{code}
HBASE-12640 seems to be the offender. [~srikanth235], [~jxiang] FYI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12902) Post-asciidoc conversion fix-ups
[
https://issues.apache.org/jira/browse/HBASE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291866#comment-14291866
]
Sean Busbey commented on HBASE-12902:
-
New issue please.
Post-asciidoc conversion fix-ups
Key: HBASE-12902
URL: https://issues.apache.org/jira/browse/HBASE-12902
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Misty Stanley-Jones
Assignee: Misty Stanley-Jones
Fix For: 2.0.0
Attachments: HBASE-12902.patch
- Put HBase logo back on book
- Remove docbkx building instructions and make sure asciidoc building
instructions are solid
- Several feedback items from [~larsgeorge]:
{quote}
Lars George
Jan-19 8:45 pm
@misty Something is off with Table1, no?
https://github.com/apache/hbase/blob/master/src/main/asciidoc/_chapters/getting_started.adoc#24-adva...
Lars George
Jan-19 8:45 pm
Is seems like a header for a table, but has no content
Misty Stanley-Jones
Jan-19 8:47 pm
yes you are right
Lars George
Jan-19 8:47 pm
@misty yeah, it is missing the node-a etc in the first column and the Xs (I
presume) in the others for the assignment
{quote}
{quote}
Lars George
Jan-19 11:53 pm
@misty 2.4 (or was it 2.3, but it is at the end of that section) and 5. are
messing up the ports for the UIs
Lars George
Jan-19 11:56 pm
@misty there is a stray section between 2.5 and 3. that seems lost and out of
place.
Tuesday January 20, 2015
Lars George
Jan-20 12:04 am
@misty hbase.balancer.period in the section with the parsed hbase-default.xml
is borked
Lars George
Jan-20 12:05 am
A few more below that are also borked
Lars George
Jan-20 12:15 am
This is 6.2 btw
Lars George
Jan-20 12:16 am
There are quite a few where Description is missing and the actual
description is printed as Courier font text, like the property name
Lars George
Jan-20 12:17 am
@misty That dangling section between 2.5 and 3. seems redundant, as 6.x
explain them all. Unless the former is for the quickstart section?
Lars George
Jan-20 12:41 am
@misty 11.1 also stuffs up the ports, the new master port in this case
Lars George
Jan-20 12:43 am
@misty in general the upgrading sections should be subsections (11, 12, 13,
etc should be no major sections)
Lars George
Jan-20 12:45 am
@misty between 17. and 18. is another dangling section with no numbering
Lars George
Jan-20 12:47 am
And again, 18., 19., 20. etc should be one major section with subsections,
not all major section on their own
Lars George
Jan-20 12:47 am
I presume now that that dangling section between 17. and 18. is the Intro and
the other should be beneath it. I guess also then this is the same for
earlier issues with section placements.
Lars George
Jan-20 12:51 am
Yeah, same for 23.5 to 24., the Data Model is the intro but shows up dangling
and all else is moved up the hierarchy
Lars George
Jan-20 1:19 am
@misty 38. (or whatever that really is now that I noticed the broken
hierarchy) is also out of date.
Lars George
Jan-20 1:20 am
(well decoupled flushing is still being worked on though)
{quote}
{quote}
Lars George
Jan-20 8:05 pm
@misty 70.5 the lead into the bulleted list is borked, it appears as part of
the first item
Lars George
Jan-20 8:06 pm
@misty and did you see those other 20+ message I sent earlier? Just checking
you se them
Lars George
Jan-20 8:08 pm
oh, and a spell check run would not be the worst idea. Some later content is
off.
Lars George
Jan-20 8:27 pm
@misty Same issue with bulleted list in 70.7.7 - I assume this is a wider
issue after conversion?
Lars George
Jan-20 8:39 pm
@misty Parameters Used by Compaction Algorithm the table is broken
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12919) Compilation with Hadoop-2.4- is broken again
[
https://issues.apache.org/jira/browse/HBASE-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-12919:
--
Assignee: Srikanth Srungarapu (was: Enis Soztutar)
Compilation with Hadoop-2.4- is broken again
Key: HBASE-12919
URL: https://issues.apache.org/jira/browse/HBASE-12919
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Srikanth Srungarapu
Attachments: HBASE-12919.patch
This is from the 1.0.0RC1 testing. I should have done the compilation before
the RC. Sorry for the noise.
{code}
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/Users/enis/projects/rc-test/hbase-1.0.0/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftHttpServlet.java:[98,18]
error: method authorize in class ProxyUsers cannot be applied to given types;
{code}
HBASE-12640 seems to be the offender. [~srikanth235], [~jxiang] FYI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12919) Compilation with Hadoop-2.4- is broken again
[
https://issues.apache.org/jira/browse/HBASE-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292297#comment-14292297
]
Hudson commented on HBASE-12919:
FAILURE: Integrated in HBase-1.1 #108 (See
[https://builds.apache.org/job/HBase-1.1/108/])
HBASE-12919 Compilation with Hadoop-2.4- is broken again (Srikanth Srungarapu)
(enis: rev 9aac2555090677d80628bc2bd8f4b5dafe3e9090)
*
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftHttpServlet.java
Compilation with Hadoop-2.4- is broken again
Key: HBASE-12919
URL: https://issues.apache.org/jira/browse/HBASE-12919
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Srikanth Srungarapu
Fix For: 1.0.0, 2.0.0, 1.1.0
Attachments: HBASE-12919.patch
This is from the 1.0.0RC1 testing. I should have done the compilation before
the RC. Sorry for the noise.
{code}
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/Users/enis/projects/rc-test/hbase-1.0.0/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftHttpServlet.java:[98,18]
error: method authorize in class ProxyUsers cannot be applied to given types;
{code}
HBASE-12640 seems to be the offender. [~srikanth235], [~jxiang] FYI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292299#comment-14292299 ] Ted Yu commented on HBASE-12915: Integrated to 0.98 as well now that compilation is fixed. Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12035) Client does an RPC to master everytime a region is relocated
[
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292319#comment-14292319
]
Hadoop QA commented on HBASE-12035:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694586/HBASE-12035.patch
against master branch at commit 1c1a306b2e4bdd5a4ff877634c5064097637e2f2.
ATTACHMENT ID: 12694586
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 27 new
or modified tests.
{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:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1942 checkstyle errors (more than the master's current 1938 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:
org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot
org.apache.hadoop.hbase.master.TestDistributedLogSplitting
{color:red}-1 core zombie tests{color}. There are 5 zombie test(s):
at
org.apache.hadoop.hbase.security.access.TestAccessController.testAccessControllerUserPermsRegexHandling(TestAccessController.java:2613)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testHbckThreadpooling(TestHBaseFsck.java:492)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testQuarantineMissingRegionDir(TestHBaseFsck.java:2197)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testMissingFirstRegion(TestHBaseFsck.java:1775)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testDegenerateRegions(TestHBaseFsck.java:848)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testNotInMetaOrDeployedHole(TestHBaseFsck.java:1174)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testNotInHdfs(TestHBaseFsck.java:1299)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testTableWithNoRegions(TestHBaseFsck.java:2533)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testRegionHole(TestHBaseFsck.java:1102)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testOverlapAndOrphan(TestHBaseFsck.java:1026)
at
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles.testRegionCrossingHFileSplit(TestLoadIncrementalHFiles.java:193)
at
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles.testRegionCrossingHFileSplitRowColBloom(TestLoadIncrementalHFiles.java:189)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12587//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
[jira] [Commented] (HBASE-12918) Backport asciidoc changes
[ https://issues.apache.org/jira/browse/HBASE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292320#comment-14292320 ] Enis Soztutar commented on HBASE-12918: --- bq. I'm going to need to do this today to get the 0.98.10 RC out in time. Cool. 1.0.0RC2 will also benefit from this. Let me know if you need help. Backport asciidoc changes - Key: HBASE-12918 URL: https://issues.apache.org/jira/browse/HBASE-12918 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Labels: beginner Fix For: 1.0.0, 0.98.10, 1.1.0 For releases, we usually whole-sale copy the docs from master to the release branch, and do the release with the latest-in-time documentation. With the asciidoc change, we cannot do that anymore unless we also get the pom.xml changes, etc. [~misty] FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292234#comment-14292234 ] Ted Yu commented on HBASE-12915: Integrated to branch-1.0 + Got compilation error in hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/CreateSnapshot.java in 0.98 Will integrate to 0.98 once compilation issue is fixed. Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 2.0.0, 0.98.10, 1.0.1, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12918) Backport asciidoc changes
[ https://issues.apache.org/jira/browse/HBASE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-12918: -- Fix Version/s: (was: 1.0.1) 1.0.0 Backport asciidoc changes - Key: HBASE-12918 URL: https://issues.apache.org/jira/browse/HBASE-12918 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Labels: beginner Fix For: 1.0.0, 0.98.10, 1.1.0 For releases, we usually whole-sale copy the docs from master to the release branch, and do the release with the latest-in-time documentation. With the asciidoc change, we cannot do that anymore unless we also get the pom.xml changes, etc. [~misty] FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11354) HConnectionImplementation#DelayedClosing does not start
[
https://issues.apache.org/jira/browse/HBASE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292358#comment-14292358
]
Hadoop QA commented on HBASE-11354:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694590/HBASE_11354.patch
against master branch at commit 1c1a306b2e4bdd5a4ff877634c5064097637e2f2.
ATTACHMENT ID: 12694590
{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 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:
{color:red}-1 core zombie tests{color}. There are 2 zombie test(s):
at
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles.testRegionCrossingRowColBloom(TestLoadIncrementalHFiles.java:140)
at
org.apache.camel.dataformat.rss.RssDataFormatTest.testUnmarshalling(RssDataFormatTest.java:46)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12589//console
This message is automatically generated.
HConnectionImplementation#DelayedClosing does not start
---
Key: HBASE-11354
URL: https://issues.apache.org/jira/browse/HBASE-11354
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 0.99.0, 0.98.3
Reporter: Qianxi Zhang
Assignee: Qianxi Zhang
Priority: Minor
Attachments: HBASE_11354.patch, HBASE_11354.patch, HBASE_11354.patch
The method createAndStart in class DelayedClosing only creates a instance,
but forgets to start it. So thread delayedClosing is not running all the time.
ConnectionManager#1623
{code}
static DelayedClosing createAndStart(HConnectionImplementation hci){
Stoppable stoppable = new Stoppable() {
private volatile boolean isStopped = false;
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292261#comment-14292261 ] Andrew Purtell commented on HBASE-12915: I'm doing that now Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292296#comment-14292296 ] Hudson commented on HBASE-12915: FAILURE: Integrated in HBase-1.1 #108 (See [https://builds.apache.org/job/HBase-1.1/108/]) HBASE-12915 Disallow small scan with batching (tedyu: rev 87a5ad4aa4f023487af05c5aaad814fbb72c79f5) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12923) ResultScanner is not closed in ModifyTableHandler#removeReplicaColumnsIfNeeded()
[
https://issues.apache.org/jira/browse/HBASE-12923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292335#comment-14292335
]
Hadoop QA commented on HBASE-12923:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694589/12923-v1.txt
against master branch at commit 1c1a306b2e4bdd5a4ff877634c5064097637e2f2.
ATTACHMENT ID: 12694589
{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 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:
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12588//console
This message is automatically generated.
ResultScanner is not closed in
ModifyTableHandler#removeReplicaColumnsIfNeeded()
Key: HBASE-12923
URL: https://issues.apache.org/jira/browse/HBASE-12923
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 12923-v1.txt
In ModifyTableHandler#removeReplicaColumnsIfNeeded():
{code}
ResultScanner resScanner = metaTable.getScanner(scan);
for (Result result : resScanner) {
{code}
The ResultScanner is not closed upon exit from the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-12915: -- Fix Version/s: (was: 1.0.1) 1.0.0 Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-12915: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12035) Client does an RPC to master everytime a region is relocated
[ https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-12035: - Attachment: HBASE-12035.patch TableState now only in META TableState in HTD now deprecated and can be removed from protobuf in future versions. Removed HTD from meta Using RetryCallable Various tests are fixed rebuild meta now know about states and rebuild them MetaTableAccessor renamed to reflect what they actually scan. migration not yet done. Client does an RPC to master everytime a region is relocated Key: HBASE-12035 URL: https://issues.apache.org/jira/browse/HBASE-12035 Project: HBase Issue Type: Improvement Components: Client, master Affects Versions: 2.0.0 Reporter: Enis Soztutar Assignee: Andrey Stepachev Priority: Critical Fix For: 2.0.0 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of zookeeper. isTableDisabled() which is used in HConnectionImplementation.relocateRegion() now became a master RPC call rather than a zookeeper client call. Since we do relocateRegion() calls everytime we want to relocate a region (region moved, RS down, etc) this implies that when the master is down, the some of the clients for uncached regions will be affected. See HBASE-7767 and HBASE-11974 for some more background. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11431) Add support of running from command line for 'hbase shell'
[ https://issues.apache.org/jira/browse/HBASE-11431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292154#comment-14292154 ] Yi Deng commented on HBASE-11431: - [~amitkabraiiit] I'm ok with close this Jira now. Add support of running from command line for 'hbase shell' -- Key: HBASE-11431 URL: https://issues.apache.org/jira/browse/HBASE-11431 Project: HBase Issue Type: New Feature Components: Admin Affects Versions: 0.89-fb Reporter: @deprecated Yi Deng Priority: Minor Labels: shell Fix For: 0.89-fb Add support of running from command line for 'hbase shell'. Now you can execute shell command from the bash like this: bin/hbase shell --exec='scan .META' The result can be piped to grep or other command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12923) ResultScanner is not closed in ModifyTableHandler#removeReplicaColumnsIfNeeded()
Ted Yu created HBASE-12923:
--
Summary: ResultScanner is not closed in
ModifyTableHandler#removeReplicaColumnsIfNeeded()
Key: HBASE-12923
URL: https://issues.apache.org/jira/browse/HBASE-12923
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
In ModifyTableHandler#removeReplicaColumnsIfNeeded():
{code}
ResultScanner resScanner = metaTable.getScanner(scan);
for (Result result : resScanner) {
{code}
The ResultScanner is not closed upon exit from the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12035) Client does an RPC to master everytime a region is relocated
[ https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-12035: - Status: Open (was: Patch Available) Client does an RPC to master everytime a region is relocated Key: HBASE-12035 URL: https://issues.apache.org/jira/browse/HBASE-12035 Project: HBase Issue Type: Improvement Components: Client, master Affects Versions: 2.0.0 Reporter: Enis Soztutar Assignee: Andrey Stepachev Priority: Critical Fix For: 2.0.0 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of zookeeper. isTableDisabled() which is used in HConnectionImplementation.relocateRegion() now became a master RPC call rather than a zookeeper client call. Since we do relocateRegion() calls everytime we want to relocate a region (region moved, RS down, etc) this implies that when the master is down, the some of the clients for uncached regions will be affected. See HBASE-7767 and HBASE-11974 for some more background. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-8410) Basic quota support for namespaces
[
https://issues.apache.org/jira/browse/HBASE-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292186#comment-14292186
]
Vandana Ayyalasomayajula commented on HBASE-8410:
-
I have added release notes to this jira. Please let me know if I need to modify
something. Also should I be creating a backport jira for branch-1 and 98 ? The
code base seems quite different and some work needs to be done for the
backport.
Thanks Ted for committing the patch.
Basic quota support for namespaces
--
Key: HBASE-8410
URL: https://issues.apache.org/jira/browse/HBASE-8410
Project: HBase
Issue Type: Sub-task
Reporter: Francis Liu
Assignee: Vandana Ayyalasomayajula
Fix For: 2.0.0
Attachments: 8410-master.9.patch, HBASE-8410-master.1.patch,
HBASE-8410-master.4.patch, HBASE-8410-master.5.patch,
HBASE-8410-master.6.patch, HBASE-8410-master.7.patch,
HBASE-8410-master.9.patch, HBASE-8410-master.patch, HBASE-8410.docx,
HBASE-8410_trunk_14.patch
This task involves creating an observer which provides basic quota support to
namespaces in terms of (1) number of tables and (2) number of regions. The
quota support can be enabled by setting:
property
namehbase.coprocessor.region.classes/name
valueorg.apache.hadoop.hbase.namespace.NamespaceController/value
/property
property
namehbase.coprocessor.master.classes/name
valueorg.apache.hadoop.hbase.namespace.NamespaceController/value
/property
in the hbase-site.xml.
To add quotas to namespace, while creating namespace properties need to be
added.
Examples:
1. namespace_create 'ns1', {'hbase.namespace.quota.maxregion'='10'}
2. 1. namespace_create 'ns2', {'hbase.namespace.quota.maxtables'='2'},
{'hbase.namespace.quota.maxregion'='5'}
The quotas can be modified/added to namespace at any point of time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-11354) HConnectionImplementation#DelayedClosing does not start
[
https://issues.apache.org/jira/browse/HBASE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-11354:
--
Attachment: HBASE_11354.patch
Retry
HConnectionImplementation#DelayedClosing does not start
---
Key: HBASE-11354
URL: https://issues.apache.org/jira/browse/HBASE-11354
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 0.99.0, 0.98.3
Reporter: Qianxi Zhang
Assignee: Qianxi Zhang
Priority: Minor
Attachments: HBASE_11354.patch, HBASE_11354.patch, HBASE_11354.patch
The method createAndStart in class DelayedClosing only creates a instance,
but forgets to start it. So thread delayedClosing is not running all the time.
ConnectionManager#1623
{code}
static DelayedClosing createAndStart(HConnectionImplementation hci){
Stoppable stoppable = new Stoppable() {
private volatile boolean isStopped = false;
@Override public void stop(String why) { isStopped = true;}
@Override public boolean isStopped() {return isStopped;}
};
return new DelayedClosing(hci, stoppable);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-8410) Basic quota support for namespaces
[
https://issues.apache.org/jira/browse/HBASE-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vandana Ayyalasomayajula updated HBASE-8410:
Release Note:
Namespace auditor provides basic quota support for namespaces in terms of
number of tables and number of regions. In order to use namespace quotas, quota
support must be enabled by setting
hbase.quota.enabled property to true in hbase-site.xml file.
The users can add quota information to namespace, while creating new namespaces
or by altering existing ones.
Examples:
1. namespace_create 'ns1', {'hbase.namespace.quota.maxregions'='10'}
2. namespace_create 'ns2',
{'hbase.namespace.quota.maxtables'='2','hbase.namespace.quota.maxregion'='5'}
3. alter_namespace 'ns3', {METHOD = 'set',
'hbase.namespace.quota.maxtables'='5','hbase.namespace.quota.maxregion'='25'}
The quotas can be modified/added to namespace at any point of time.
Basic quota support for namespaces
--
Key: HBASE-8410
URL: https://issues.apache.org/jira/browse/HBASE-8410
Project: HBase
Issue Type: Sub-task
Reporter: Francis Liu
Assignee: Vandana Ayyalasomayajula
Fix For: 2.0.0
Attachments: 8410-master.9.patch, HBASE-8410-master.1.patch,
HBASE-8410-master.4.patch, HBASE-8410-master.5.patch,
HBASE-8410-master.6.patch, HBASE-8410-master.7.patch,
HBASE-8410-master.9.patch, HBASE-8410-master.patch, HBASE-8410.docx,
HBASE-8410_trunk_14.patch
This task involves creating an observer which provides basic quota support to
namespaces in terms of (1) number of tables and (2) number of regions. The
quota support can be enabled by setting:
property
namehbase.coprocessor.region.classes/name
valueorg.apache.hadoop.hbase.namespace.NamespaceController/value
/property
property
namehbase.coprocessor.master.classes/name
valueorg.apache.hadoop.hbase.namespace.NamespaceController/value
/property
in the hbase-site.xml.
To add quotas to namespace, while creating namespace properties need to be
added.
Examples:
1. namespace_create 'ns1', {'hbase.namespace.quota.maxregion'='10'}
2. 1. namespace_create 'ns2', {'hbase.namespace.quota.maxtables'='2'},
{'hbase.namespace.quota.maxregion'='5'}
The quotas can be modified/added to namespace at any point of time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12914) Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade section
[ https://issues.apache.org/jira/browse/HBASE-12914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292194#comment-14292194 ] Andrew Purtell commented on HBASE-12914: Adding to Ram's list: - HFile encryption Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade section --- Key: HBASE-12914 URL: https://issues.apache.org/jira/browse/HBASE-12914 Project: HBase Issue Type: Bug Components: API, documentation Affects Versions: 0.98.6, 0.98.7, 0.98.8, 0.98.9 Reporter: Sean Busbey Priority: Critical Fix For: 0.98.10, 1.0.1 There are several features in 0.98 that require enabling HFilev3 support. Some of those features include new extendable components that are marked IA.Public. Current practice has been to treat these features as experimental. This has included pushing non-compatible changes to branch-1 as the API got worked out through use in 0.98. * Update all of the IA.Public classes involved to make sure they are IS.Unstable in 0.98. * Update the ref guide section on upgrading from 0.98 - 1.0 to make folks aware of these changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292208#comment-14292208 ] Andrew Purtell commented on HBASE-12915: +1 for 0.98 Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12035) Client does an RPC to master everytime a region is relocated
[ https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-12035: - Status: Patch Available (was: Open) Client does an RPC to master everytime a region is relocated Key: HBASE-12035 URL: https://issues.apache.org/jira/browse/HBASE-12035 Project: HBase Issue Type: Improvement Components: Client, master Affects Versions: 2.0.0 Reporter: Enis Soztutar Assignee: Andrey Stepachev Priority: Critical Fix For: 2.0.0 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of zookeeper. isTableDisabled() which is used in HConnectionImplementation.relocateRegion() now became a master RPC call rather than a zookeeper client call. Since we do relocateRegion() calls everytime we want to relocate a region (region moved, RS down, etc) this implies that when the master is down, the some of the clients for uncached regions will be affected. See HBASE-7767 and HBASE-11974 for some more background. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-12917) HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to recursive loop in createCell function
[
https://issues.apache.org/jira/browse/HBASE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-12917:
---
Comment: was deleted
(was: {quote}
here is quotable
content to be quoted
{quote})
HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to
recursive loop in createCell function
---
Key: HBASE-12917
URL: https://issues.apache.org/jira/browse/HBASE-12917
Project: HBase
Issue Type: Bug
Components: hbase
Affects Versions: 2.0.0
Environment: Ubuntu
Reporter: Vikas Vishwakarma
Assignee: Vikas Vishwakarma
Fix For: 2.0.0
Attachments: HBASE-12917.patch
While trying to run HFilePerformanceEvaluation with hbase-2.0.0
UniformRandomSmallScan is failing with StackOverflowError. Lookes related to
the byte array to Cell based HFile changes.
2015-01-26 12:42:09,551 WARN [main] util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
2015-01-26 12:42:09,760 INFO [main] hbase.HFilePerformanceEvaluation:
Running SequentialWriteBenchmark for 100 rows.
2015-01-26 12:42:10,007 INFO [main] hfile.CacheConfig: CacheConfig:disabled
2015-01-26 12:42:11,560 INFO [main] hbase.HFilePerformanceEvaluation:
Running SequentialWriteBenchmark for 100 rows took 1496ms.
2015-01-26 12:42:11,561 INFO [0] hbase.HFilePerformanceEvaluation: Running
UniformRandomSmallScan for 100 rows.
2015-01-26 12:42:11,561 INFO [0] hfile.CacheConfig: CacheConfig:disabled
Exception in thread 0 java.lang.StackOverflowError
at
org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78)
at
org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78)
at
org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78)
at
org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-12917) HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to recursive loop in createCell function
[ https://issues.apache.org/jira/browse/HBASE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-12917: --- Comment: was deleted (was: sorry ignore above .. i thought i will be able to delete the comment.) HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to recursive loop in createCell function --- Key: HBASE-12917 URL: https://issues.apache.org/jira/browse/HBASE-12917 Project: HBase Issue Type: Bug Components: hbase Affects Versions: 2.0.0 Environment: Ubuntu Reporter: Vikas Vishwakarma Assignee: Vikas Vishwakarma Fix For: 2.0.0 Attachments: HBASE-12917.patch While trying to run HFilePerformanceEvaluation with hbase-2.0.0 UniformRandomSmallScan is failing with StackOverflowError. Lookes related to the byte array to Cell based HFile changes. 2015-01-26 12:42:09,551 WARN [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable 2015-01-26 12:42:09,760 INFO [main] hbase.HFilePerformanceEvaluation: Running SequentialWriteBenchmark for 100 rows. 2015-01-26 12:42:10,007 INFO [main] hfile.CacheConfig: CacheConfig:disabled 2015-01-26 12:42:11,560 INFO [main] hbase.HFilePerformanceEvaluation: Running SequentialWriteBenchmark for 100 rows took 1496ms. 2015-01-26 12:42:11,561 INFO [0] hbase.HFilePerformanceEvaluation: Running UniformRandomSmallScan for 100 rows. 2015-01-26 12:42:11,561 INFO [0] hfile.CacheConfig: CacheConfig:disabled Exception in thread 0 java.lang.StackOverflowError at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12916) No access control for replicating WAL entries
[
https://issues.apache.org/jira/browse/HBASE-12916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292206#comment-14292206
]
Andrew Purtell commented on HBASE-12916:
RSO seems like a good place to hang a new hook.
The style of pre- CP hooks is to give the observer access to available
information to make an informed authoritative decision. So
RegionServerObserver#preReplicateLogEntries should accept the same arguments as
ReplicationSinkService#replicateLogEntries, like:
{code}
+ void preReplicateLogEntries(final
ObserverContextRegionServerCoprocessorEnvironment ctx,
+ ListWALEntry entries, CellScanner cells) throws IOException;
{code}
No access control for replicating WAL entries
-
Key: HBASE-12916
URL: https://issues.apache.org/jira/browse/HBASE-12916
Project: HBase
Issue Type: Bug
Components: Replication
Affects Versions: 2.0.0, 0.94.26, 0.98.12
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Attachments: HBASE-12916-v1.diff
Currently, there is no access control for replicating WAL entries in secure
HBase cluster. Any authenticated user can write any data they want to any
table of a secure cluster by using the replication api.
Simple solution is to add permission check before replicating WAL entries.
And only user with global write permission can replicate WAL entries to this
cluster.
Another option is adding Replication action in hbase and only user with
Replication permission can replicate WAL entries to this cluster?
[~apurtell]
What's your suggestion? Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-6778) Deprecate Chore; its a thread per task when we should have one thread to do all tasks
[ https://issues.apache.org/jira/browse/HBASE-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292211#comment-14292211 ] stack commented on HBASE-6778: -- Looking at your patch and given the recent radical refactor of Connection, I'd say purge DelayedClosing rather than add it back in as HBASE-11354 has it. The discussion in HBASE-11354 is too nebulous on what DelayedClosing brings and its allowed we purge till we figure what is needed in new world. Don't need 'Thread' on end of name here, redundant: _ChoreServiceThread_ Add this to Server rather than MasterServices and then to RegionServerServices? ChoreService getChoreService(); Do you not remove the classes you are replacing? This patch is really good. Let me run it by hadoopqa. Deprecate Chore; its a thread per task when we should have one thread to do all tasks - Key: HBASE-6778 URL: https://issues.apache.org/jira/browse/HBASE-6778 Project: HBase Issue Type: Bug Reporter: stack Assignee: Jonathan Lawlor Fix For: 2.0.0, 1.1.0 Attachments: AFTER_thread_dump.txt, BEFORE_thread_dump.txt, HBASE_6778_WIP_v1.patch, HBASE_6778_WIP_v2.patch, thread_dump_HMaster.local.out Should use something like ScheduledThreadPoolExecutor instead (Elliott said this first I think; J-D said something similar just now). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-6778) Deprecate Chore; its a thread per task when we should have one thread to do all tasks
[ https://issues.apache.org/jira/browse/HBASE-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6778: - Fix Version/s: 1.1.0 2.0.0 Hadoop Flags: Incompatible change Status: Patch Available (was: Open) Deprecate Chore; its a thread per task when we should have one thread to do all tasks - Key: HBASE-6778 URL: https://issues.apache.org/jira/browse/HBASE-6778 Project: HBase Issue Type: Bug Reporter: stack Assignee: Jonathan Lawlor Fix For: 2.0.0, 1.1.0 Attachments: AFTER_thread_dump.txt, BEFORE_thread_dump.txt, HBASE_6778_WIP_v1.patch, HBASE_6778_WIP_v2.patch, thread_dump_HMaster.local.out Should use something like ScheduledThreadPoolExecutor instead (Elliott said this first I think; J-D said something similar just now). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292098#comment-14292098 ] Ted Yu commented on HBASE-12915: Looks like I should have checked more builds before making judgment. TestHCM failed in trunk build #6055. It also failed in some QA runs. What I wanted to say is that the patch is not related to TestHCM flakiness. Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12035) Client does an RPC to master everytime a region is relocated
[ https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292118#comment-14292118 ] Andrey Stepachev commented on HBASE-12035: -- btw, keeping state in meta only will lead to all tables enabled on meta rebuild (unless we add some command line argument to specify table states or make hbck able to sideline table status info into some place where it can be read while hbase is offline, or we can read meta offline and get states from there) Client does an RPC to master everytime a region is relocated Key: HBASE-12035 URL: https://issues.apache.org/jira/browse/HBASE-12035 Project: HBase Issue Type: Improvement Components: Client, master Affects Versions: 2.0.0 Reporter: Enis Soztutar Assignee: Andrey Stepachev Priority: Critical Fix For: 2.0.0 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of zookeeper. isTableDisabled() which is used in HConnectionImplementation.relocateRegion() now became a master RPC call rather than a zookeeper client call. Since we do relocateRegion() calls everytime we want to relocate a region (region moved, RS down, etc) this implies that when the master is down, the some of the clients for uncached regions will be affected. See HBASE-7767 and HBASE-11974 for some more background. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12923) ResultScanner is not closed in ModifyTableHandler#removeReplicaColumnsIfNeeded()
[
https://issues.apache.org/jira/browse/HBASE-12923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-12923:
---
Attachment: 12923-v1.txt
ResultScanner is not closed in
ModifyTableHandler#removeReplicaColumnsIfNeeded()
Key: HBASE-12923
URL: https://issues.apache.org/jira/browse/HBASE-12923
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 12923-v1.txt
In ModifyTableHandler#removeReplicaColumnsIfNeeded():
{code}
ResultScanner resScanner = metaTable.getScanner(scan);
for (Result result : resScanner) {
{code}
The ResultScanner is not closed upon exit from the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-7541) Convert all tests that use HBaseTestingUtility.createMultiRegions to HBA.createTable
[
https://issues.apache.org/jira/browse/HBASE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292171#comment-14292171
]
stack commented on HBASE-7541:
--
[~jonathan.lawlor] My fault. The branch-1 patch has rotted. Mind rebasing?
Thanks.
Convert all tests that use HBaseTestingUtility.createMultiRegions to
HBA.createTable
Key: HBASE-7541
URL: https://issues.apache.org/jira/browse/HBASE-7541
Project: HBase
Issue Type: Improvement
Reporter: Jean-Daniel Cryans
Assignee: Jonathan Lawlor
Fix For: 2.0.0
Attachments: HBASE7541_patch_v1.txt, HBASE_7541_v2.txt,
HBASE_7541_v2.txt, HBASE_7541_v2_branch-1.txt
Like I discussed in HBASE-7534, {{HBaseTestingUtility.createMultiRegions}}
should disappear and not come back. There's about 25 different places in the
code that rely on it that need to be changed the same way I changed
TestReplication.
Perfect for someone that wants to get started with HBase dev :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12923) ResultScanner is not closed in ModifyTableHandler#removeReplicaColumnsIfNeeded()
[
https://issues.apache.org/jira/browse/HBASE-12923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-12923:
---
Status: Patch Available (was: Open)
ResultScanner is not closed in
ModifyTableHandler#removeReplicaColumnsIfNeeded()
Key: HBASE-12923
URL: https://issues.apache.org/jira/browse/HBASE-12923
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 12923-v1.txt
In ModifyTableHandler#removeReplicaColumnsIfNeeded():
{code}
ResultScanner resScanner = metaTable.getScanner(scan);
for (Result result : resScanner) {
{code}
The ResultScanner is not closed upon exit from the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-6778) Deprecate Chore; its a thread per task when we should have one thread to do all tasks
[
https://issues.apache.org/jira/browse/HBASE-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292185#comment-14292185
]
stack commented on HBASE-6778:
--
Just read your write up. Its great. MovedRegionsCleaner not being started looks
like a bug. Suggest fix in new issue. Have the chore run once a day since
seems like it not running has not been an issue up to this. I reattached the
patch on HBASE-11354 to trigger a rebuild. Will commit it if it passes.
Nice stuff like this should go into release note:
{code}
Chore.interrupt() - ScheduledChore.cancel(mayInterruptWhileRunning = true)
Threads.setDaemonThreadRunning(Chore) -
ChoreService.scheduleChore(ScheduledChore)
Chore.isAlive - ScheduledChore.isScheduled()
Chore.getSleeper().skipSleepCycle() - ScheduledChore.triggerNow()
{code}
Nice numbers on cut in thread count.
Let me give you a bit of feedback on the patch.
Deprecate Chore; its a thread per task when we should have one thread to do
all tasks
-
Key: HBASE-6778
URL: https://issues.apache.org/jira/browse/HBASE-6778
Project: HBase
Issue Type: Bug
Reporter: stack
Assignee: Jonathan Lawlor
Attachments: AFTER_thread_dump.txt, BEFORE_thread_dump.txt,
HBASE_6778_WIP_v1.patch, HBASE_6778_WIP_v2.patch,
thread_dump_HMaster.local.out
Should use something like ScheduledThreadPoolExecutor instead (Elliott said
this first I think; J-D said something similar just now).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292053#comment-14292053 ] stack commented on HBASE-12915: --- bq. This test fails in trunk consistently. Since which commit? Looking at trunk, it fails rare. It is reliable fail now? Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12902) Post-asciidoc conversion fix-ups
[
https://issues.apache.org/jira/browse/HBASE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292144#comment-14292144
]
stack commented on HBASE-12902:
---
[~larsgeorge] New issue (as per [~busbey] above)
Post-asciidoc conversion fix-ups
Key: HBASE-12902
URL: https://issues.apache.org/jira/browse/HBASE-12902
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Misty Stanley-Jones
Assignee: Misty Stanley-Jones
Fix For: 2.0.0
Attachments: HBASE-12902.patch
- Put HBase logo back on book
- Remove docbkx building instructions and make sure asciidoc building
instructions are solid
- Several feedback items from [~larsgeorge]:
{quote}
Lars George
Jan-19 8:45 pm
@misty Something is off with Table1, no?
https://github.com/apache/hbase/blob/master/src/main/asciidoc/_chapters/getting_started.adoc#24-adva...
Lars George
Jan-19 8:45 pm
Is seems like a header for a table, but has no content
Misty Stanley-Jones
Jan-19 8:47 pm
yes you are right
Lars George
Jan-19 8:47 pm
@misty yeah, it is missing the node-a etc in the first column and the Xs (I
presume) in the others for the assignment
{quote}
{quote}
Lars George
Jan-19 11:53 pm
@misty 2.4 (or was it 2.3, but it is at the end of that section) and 5. are
messing up the ports for the UIs
Lars George
Jan-19 11:56 pm
@misty there is a stray section between 2.5 and 3. that seems lost and out of
place.
Tuesday January 20, 2015
Lars George
Jan-20 12:04 am
@misty hbase.balancer.period in the section with the parsed hbase-default.xml
is borked
Lars George
Jan-20 12:05 am
A few more below that are also borked
Lars George
Jan-20 12:15 am
This is 6.2 btw
Lars George
Jan-20 12:16 am
There are quite a few where Description is missing and the actual
description is printed as Courier font text, like the property name
Lars George
Jan-20 12:17 am
@misty That dangling section between 2.5 and 3. seems redundant, as 6.x
explain them all. Unless the former is for the quickstart section?
Lars George
Jan-20 12:41 am
@misty 11.1 also stuffs up the ports, the new master port in this case
Lars George
Jan-20 12:43 am
@misty in general the upgrading sections should be subsections (11, 12, 13,
etc should be no major sections)
Lars George
Jan-20 12:45 am
@misty between 17. and 18. is another dangling section with no numbering
Lars George
Jan-20 12:47 am
And again, 18., 19., 20. etc should be one major section with subsections,
not all major section on their own
Lars George
Jan-20 12:47 am
I presume now that that dangling section between 17. and 18. is the Intro and
the other should be beneath it. I guess also then this is the same for
earlier issues with section placements.
Lars George
Jan-20 12:51 am
Yeah, same for 23.5 to 24., the Data Model is the intro but shows up dangling
and all else is moved up the hierarchy
Lars George
Jan-20 1:19 am
@misty 38. (or whatever that really is now that I noticed the broken
hierarchy) is also out of date.
Lars George
Jan-20 1:20 am
(well decoupled flushing is still being worked on though)
{quote}
{quote}
Lars George
Jan-20 8:05 pm
@misty 70.5 the lead into the bulleted list is borked, it appears as part of
the first item
Lars George
Jan-20 8:06 pm
@misty and did you see those other 20+ message I sent earlier? Just checking
you se them
Lars George
Jan-20 8:08 pm
oh, and a spell check run would not be the worst idea. Some later content is
off.
Lars George
Jan-20 8:27 pm
@misty Same issue with bulleted list in 70.7.7 - I assume this is a wider
issue after conversion?
Lars George
Jan-20 8:39 pm
@misty Parameters Used by Compaction Algorithm the table is broken
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12918) Backport asciidoc changes
[ https://issues.apache.org/jira/browse/HBASE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292179#comment-14292179 ] Andrew Purtell commented on HBASE-12918: I'm going to need to do this today to get the 0.98.10 RC out in time. Backport asciidoc changes - Key: HBASE-12918 URL: https://issues.apache.org/jira/browse/HBASE-12918 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Labels: beginner Fix For: 0.98.10, 1.0.1, 1.1.0 For releases, we usually whole-sale copy the docs from master to the release branch, and do the release with the latest-in-time documentation. With the asciidoc change, we cannot do that anymore unless we also get the pom.xml changes, etc. [~misty] FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12918) Backport asciidoc changes
[ https://issues.apache.org/jira/browse/HBASE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-12918: --- Fix Version/s: 0.98.10 Backport asciidoc changes - Key: HBASE-12918 URL: https://issues.apache.org/jira/browse/HBASE-12918 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Labels: beginner Fix For: 0.98.10, 1.0.1, 1.1.0 For releases, we usually whole-sale copy the docs from master to the release branch, and do the release with the latest-in-time documentation. With the asciidoc change, we cannot do that anymore unless we also get the pom.xml changes, etc. [~misty] FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12918) Backport asciidoc changes
[ https://issues.apache.org/jira/browse/HBASE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292178#comment-14292178 ] Andrew Purtell commented on HBASE-12918: Yes, I copy docs from master for 0.98 releases. What we can do is one big backport of docs from trunk to branch including the POM changes, and then resync at each release going forward. Backport asciidoc changes - Key: HBASE-12918 URL: https://issues.apache.org/jira/browse/HBASE-12918 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Labels: beginner Fix For: 0.98.10, 1.0.1, 1.1.0 For releases, we usually whole-sale copy the docs from master to the release branch, and do the release with the latest-in-time documentation. With the asciidoc change, we cannot do that anymore unless we also get the pom.xml changes, etc. [~misty] FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-12915: --- Fix Version/s: 1.1.0 1.0.1 0.98.10 2.0.0 Set fix versions Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 2.0.0, 0.98.10, 1.0.1, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12922) Post-asciidoc conversion fix-ups part 2
[
https://issues.apache.org/jira/browse/HBASE-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292100#comment-14292100
]
Hadoop QA commented on HBASE-12922:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694559/HBASE-12922.1.patch
against master branch at commit 1c1a306b2e4bdd5a4ff877634c5064097637e2f2.
ATTACHMENT ID: 12694559
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 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:
+NoSQL is a general term meaning that the database isn't an RDBMS which
supports SQL as its primary access language, but there are many types of NoSQL
databases: BerkeleyDB is an example of a local NoSQL database, whereas HBase is
very much a distributed database.
+Technically speaking, HBase is really more a Data Store than Data Base
because it lacks many of the features you find in an RDBMS, such as typed
columns, secondary indexes, triggers, and advanced query languages, etc.
+* Automatic sharding: HBase tables are distributed on the cluster via regions,
and regions are automatically split and re-distributed as your data grows.
+* MapReduce: HBase supports massively parallelized processing via MapReduce
for using HBase as both source and sink.
+* Block Cache and Bloom Filters: HBase supports a Block Cache and Bloom
Filters for high volume query optimization.
+* Operational Management: HBase provides build-in web-pages for operational
insight as well as JMX metrics.
+If you only have a few thousand/million rows, then using a traditional RDBMS
might be a better choice due to the fact that all of your data might wind up on
a single node (or two) and the rest of the cluster may be sitting idle.
+Even HDFS doesn't do well with anything less than 5 DataNodes (due to things
such as HDFS block replication which has a default of 3), plus a NameNode.
+HBase can run quite well stand-alone on a laptop - but this should be
considered a development configuration only.
+See the datamodel and the rest of this chapter for more information on how
HBase achieves its goals.
{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/12586//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12586//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
[jira] [Resolved] (HBASE-11431) Add support of running from command line for 'hbase shell'
[ https://issues.apache.org/jira/browse/HBASE-11431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-11431. Resolution: Not a Problem Add support of running from command line for 'hbase shell' -- Key: HBASE-11431 URL: https://issues.apache.org/jira/browse/HBASE-11431 Project: HBase Issue Type: New Feature Components: Admin Affects Versions: 0.89-fb Reporter: @deprecated Yi Deng Priority: Minor Labels: shell Fix For: 0.89-fb Add support of running from command line for 'hbase shell'. Now you can execute shell command from the bash like this: bin/hbase shell --exec='scan .META' The result can be piped to grep or other command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-6778) Deprecate Chore; its a thread per task when we should have one thread to do all tasks
[
https://issues.apache.org/jira/browse/HBASE-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292388#comment-14292388
]
Hadoop QA commented on HBASE-6778:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694298/HBASE_6778_WIP_v2.patch
against master branch at commit 1c1a306b2e4bdd5a4ff877634c5064097637e2f2.
ATTACHMENT ID: 12694298
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 46 new
or modified tests.
{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:red}-1 findbugs{color}. The patch appears to introduce 2 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:
+ /** The minimum number of threads in the core pool of the underlying
ScheduledThreadPoolExecutor */
+new ScheduledThreadPoolExecutor(corePoolSize, new
ChoreServiceThreadFactory(coreThreadPoolPrefix));
+ public CountingChore(String name, Stoppable stopper, int period, final
boolean outputOnTicks) {
+assertEquals(Should not create more pools than scheduled chores, 3,
service.getCorePoolSize());
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestEndToEndSplitTransaction
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.hadoop.hbase.namespace.TestNamespaceAuditor.testTableOperations(TestNamespaceAuditor.java:123)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12590//console
This message is automatically generated.
Deprecate Chore; its a thread per task when we should have one thread to do
all tasks
-
Key: HBASE-6778
URL: https://issues.apache.org/jira/browse/HBASE-6778
Project: HBase
Issue Type: Bug
Reporter: stack
Assignee: Jonathan Lawlor
Fix For: 2.0.0, 1.1.0
Attachments: AFTER_thread_dump.txt, BEFORE_thread_dump.txt,
HBASE_6778_WIP_v1.patch, HBASE_6778_WIP_v2.patch,
thread_dump_HMaster.local.out
Should use something like
[jira] [Created] (HBASE-12924) HRegionServer#MovedRegionsCleaner Chore does not start
Jonathan Lawlor created HBASE-12924:
---
Summary: HRegionServer#MovedRegionsCleaner Chore does not start
Key: HBASE-12924
URL: https://issues.apache.org/jira/browse/HBASE-12924
Project: HBase
Issue Type: Bug
Reporter: Jonathan Lawlor
Priority: Minor
This issue is very similar to the one described in HBASE-11354. The method
createAndStart in MovedRegionsCleaner creates an instance of the chore but
never starts the underlying thread:
{code}
static MovedRegionsCleaner createAndStart(HRegionServer rs){
Stoppable stoppable = new Stoppable() {
private volatile boolean isStopped = false;
@Override public void stop(String why) { isStopped = true;}
@Override public boolean isStopped() {return isStopped;}
};
return new MovedRegionsCleaner(rs, stoppable);
}
{code}
Nobody has noticed this issue so far so the Chore may not be that important
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12918) Backport asciidoc changes
[ https://issues.apache.org/jira/browse/HBASE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292423#comment-14292423 ] Misty Stanley-Jones commented on HBASE-12918: - Let me know if you guys need help with this. I didn't even think about it ! Backport asciidoc changes - Key: HBASE-12918 URL: https://issues.apache.org/jira/browse/HBASE-12918 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Labels: beginner Fix For: 1.0.0, 0.98.10, 1.1.0 For releases, we usually whole-sale copy the docs from master to the release branch, and do the release with the latest-in-time documentation. With the asciidoc change, we cannot do that anymore unless we also get the pom.xml changes, etc. [~misty] FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12918) Backport asciidoc changes
[ https://issues.apache.org/jira/browse/HBASE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292427#comment-14292427 ] Andrew Purtell commented on HBASE-12918: Thanks, I think I'm good. I have a working patch for 0.98 and am just testing one for branch-1.0 now. Backport asciidoc changes - Key: HBASE-12918 URL: https://issues.apache.org/jira/browse/HBASE-12918 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Labels: beginner Fix For: 1.0.0, 0.98.10, 1.1.0 For releases, we usually whole-sale copy the docs from master to the release branch, and do the release with the latest-in-time documentation. With the asciidoc change, we cannot do that anymore unless we also get the pom.xml changes, etc. [~misty] FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12923) ResultScanner is not closed in ModifyTableHandler#removeReplicaColumnsIfNeeded()
[
https://issues.apache.org/jira/browse/HBASE-12923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292463#comment-14292463
]
Ted Yu commented on HBASE-12923:
TestLoadIncrementalHFiles passes locally with the patch.
ResultScanner is not closed in
ModifyTableHandler#removeReplicaColumnsIfNeeded()
Key: HBASE-12923
URL: https://issues.apache.org/jira/browse/HBASE-12923
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Attachments: 12923-v1.txt
In ModifyTableHandler#removeReplicaColumnsIfNeeded():
{code}
ResultScanner resScanner = metaTable.getScanner(scan);
for (Result result : resScanner) {
{code}
The ResultScanner is not closed upon exit from the method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
[
https://issues.apache.org/jira/browse/HBASE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-12925:
Attachment: (was: HBASE-12925.patch)
Use acl cache for doing access control checks in prepare and clean phases of
Bulkloading.
-
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess,
which performs scan on ACL table, instead of using TableAuthManager. Also,
the method hasSomeAccess has a logical error, as it doesn't filter the acl
scan results by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
userPerm.getUser.equals(requestUser). This issue will help us in getting rid
of this problematic implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12924) HRegionServer#MovedRegionsCleaner Chore does not start
[
https://issues.apache.org/jira/browse/HBASE-12924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292506#comment-14292506
]
stack commented on HBASE-12924:
---
You have a patch [~jonathan.lawlor]? Thanks boss.
HRegionServer#MovedRegionsCleaner Chore does not start
--
Key: HBASE-12924
URL: https://issues.apache.org/jira/browse/HBASE-12924
Project: HBase
Issue Type: Bug
Reporter: Jonathan Lawlor
Priority: Minor
This issue is very similar to the one described in HBASE-11354. The method
createAndStart in MovedRegionsCleaner creates an instance of the chore but
never starts the underlying thread:
{code}
static MovedRegionsCleaner createAndStart(HRegionServer rs){
Stoppable stoppable = new Stoppable() {
private volatile boolean isStopped = false;
@Override public void stop(String why) { isStopped = true;}
@Override public boolean isStopped() {return isStopped;}
};
return new MovedRegionsCleaner(rs, stoppable);
}
{code}
Nobody has noticed this issue so far so the Chore may not be that important
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12915) Disallow small scan with batching
[ https://issues.apache.org/jira/browse/HBASE-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292385#comment-14292385 ] Hudson commented on HBASE-12915: FAILURE: Integrated in HBase-0.98 #817 (See [https://builds.apache.org/job/HBase-0.98/817/]) HBASE-12915 Disallow small scan with batching (tedyu: rev dc145552c10273bec9679052ed1008872c9bb031) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java Disallow small scan with batching - Key: HBASE-12915 URL: https://issues.apache.org/jira/browse/HBASE-12915 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: 12915-001.txt, 12915-001.txt If user sets batching in Scan object, ClientSmallScanner may return unexpected result because data from same row may appear in multiple Result objects but ClientSmallScanner considers different Results to correspond to different rows. Small scan with batching should be disallowed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12745) Visibility Labels: support visibility labels for user groups.
[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292412#comment-14292412
]
Jerry He commented on HBASE-12745:
--
Looks good, [~anoop.hbase]
Visibility Labels: support visibility labels for user groups.
--
Key: HBASE-12745
URL: https://issues.apache.org/jira/browse/HBASE-12745
Project: HBase
Issue Type: Improvement
Components: security
Affects Versions: 1.0.0, 0.98.9, 0.99.2
Reporter: Jerry He
Assignee: Jerry He
Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0
Attachments: HBASE-12745-master-v1.patch,
HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
HBASE-12745-v7-0.98-with-update.patch, HBASE-12745-v7-0.98.patch,
HBASE-12745-v7-branch1.patch, hbase-12745_branch-1-addendum.patch,
hbase-12745_branch-1-addendum2.patch
The thinking is that we should support visibility labels to be associated
with user groups.
We will then be able grant visibility labels to a group in addition to
individual users, which provides convenience and usability.
We will use '@group' to denote a group name, as similarly done in
AcccessController.
For example,
{code}
set_auths '@group1', ['SECRET','PRIVATE']
{code}
{code}
get_auth '@group1'
{code}
A user belonging to 'group1' will have all the visibility labels granted to
'group1'
We'll also support super user groups as specified in hbase-site.xml.
The code update will mainly be on the server side VisibilityLabelService
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12902) Post-asciidoc conversion fix-ups
[
https://issues.apache.org/jira/browse/HBASE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292437#comment-14292437
]
Misty Stanley-Jones commented on HBASE-12902:
-
[~larsgeorge] The current structure actually reflects a big usability win for
readers (IMHO), since it exposes more information they are likely to be looking
for, with only a single click or Ctrl+F. It also allows people to learn the
structure of the book, and exposes current layout issues, such as half of the
book occurring after the Appendixes start. Anecdotally, we have had very
positive feedback on the new layout, with very little negative feedback indeed.
I actually think that we should remove *all* of the numbering, continue to
expose the top-level sections within chapters, and additionally add the
ability to permalink to each top-level section in the book. I chose to remove
the numbering from the chapters because they are way bigger than chapters
should be, and should more properly be called Parts. The chunking in the book
is all wrong.
Permalinks, along with quick-links to report bugs against a given section,
would make reporting problems easier and less error-prone. Using numbers as
though it were a printed book makes bugs harder to find and fix, and reduces
the archival value of searching reported and fixed/notfixed bugs over time.
As far as the structure in general, it won't get a rework (by me) until the v2
book is started. There are too many other things that need doing. Patches
accepted, of course.
Post-asciidoc conversion fix-ups
Key: HBASE-12902
URL: https://issues.apache.org/jira/browse/HBASE-12902
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Misty Stanley-Jones
Assignee: Misty Stanley-Jones
Fix For: 2.0.0
Attachments: HBASE-12902.patch
- Put HBase logo back on book
- Remove docbkx building instructions and make sure asciidoc building
instructions are solid
- Several feedback items from [~larsgeorge]:
{quote}
Lars George
Jan-19 8:45 pm
@misty Something is off with Table1, no?
https://github.com/apache/hbase/blob/master/src/main/asciidoc/_chapters/getting_started.adoc#24-adva...
Lars George
Jan-19 8:45 pm
Is seems like a header for a table, but has no content
Misty Stanley-Jones
Jan-19 8:47 pm
yes you are right
Lars George
Jan-19 8:47 pm
@misty yeah, it is missing the node-a etc in the first column and the Xs (I
presume) in the others for the assignment
{quote}
{quote}
Lars George
Jan-19 11:53 pm
@misty 2.4 (or was it 2.3, but it is at the end of that section) and 5. are
messing up the ports for the UIs
Lars George
Jan-19 11:56 pm
@misty there is a stray section between 2.5 and 3. that seems lost and out of
place.
Tuesday January 20, 2015
Lars George
Jan-20 12:04 am
@misty hbase.balancer.period in the section with the parsed hbase-default.xml
is borked
Lars George
Jan-20 12:05 am
A few more below that are also borked
Lars George
Jan-20 12:15 am
This is 6.2 btw
Lars George
Jan-20 12:16 am
There are quite a few where Description is missing and the actual
description is printed as Courier font text, like the property name
Lars George
Jan-20 12:17 am
@misty That dangling section between 2.5 and 3. seems redundant, as 6.x
explain them all. Unless the former is for the quickstart section?
Lars George
Jan-20 12:41 am
@misty 11.1 also stuffs up the ports, the new master port in this case
Lars George
Jan-20 12:43 am
@misty in general the upgrading sections should be subsections (11, 12, 13,
etc should be no major sections)
Lars George
Jan-20 12:45 am
@misty between 17. and 18. is another dangling section with no numbering
Lars George
Jan-20 12:47 am
And again, 18., 19., 20. etc should be one major section with subsections,
not all major section on their own
Lars George
Jan-20 12:47 am
I presume now that that dangling section between 17. and 18. is the Intro and
the other should be beneath it. I guess also then this is the same for
earlier issues with section placements.
Lars George
Jan-20 12:51 am
Yeah, same for 23.5 to 24., the Data Model is the intro but shows up dangling
and all else is moved up the hierarchy
Lars George
Jan-20 1:19 am
@misty 38. (or whatever that really is now that I noticed the broken
hierarchy) is also out of date.
Lars George
Jan-20 1:20 am
(well decoupled flushing is still being worked on though)
{quote}
{quote}
Lars George
Jan-20 8:05 pm
@misty 70.5 the lead into the bulleted list is borked, it appears as part of
the first item
Lars George
Jan-20 8:06 pm
@misty and did you see those other 20+ message I sent earlier? Just checking
you se them
Lars George
Jan-20 8:08 pm
oh, and a spell check run would not be the worst
[jira] [Updated] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
[
https://issues.apache.org/jira/browse/HBASE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-12925:
Attachment: HBASE-12925.patch
Use acl cache for doing access control checks in prepare and clean phases of
Bulkloading.
-
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Attachments: HBASE-12925.patch
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess,
which performs scan on ACL table, instead of using TableAuthManager. Also,
the method hasSomeAccess has a logical error, as it doesn't filter the acl
scan results by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
userPerm.getUser.equals(requestUser). This issue will help us in getting rid
of this problematic implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-7541) Convert all tests that use HBaseTestingUtility.createMultiRegions to HBA.createTable
[
https://issues.apache.org/jira/browse/HBASE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-7541:
-
Fix Version/s: 1.1.0
Convert all tests that use HBaseTestingUtility.createMultiRegions to
HBA.createTable
Key: HBASE-7541
URL: https://issues.apache.org/jira/browse/HBASE-7541
Project: HBase
Issue Type: Improvement
Reporter: Jean-Daniel Cryans
Assignee: Jonathan Lawlor
Fix For: 2.0.0, 1.1.0
Attachments: HBASE7541_patch_v1.txt, HBASE_7541_v2.txt,
HBASE_7541_v2.txt, HBASE_7541_v2_branch-1.txt, HBASE_7541_v2_branch-1.txt
Like I discussed in HBASE-7534, {{HBaseTestingUtility.createMultiRegions}}
should disappear and not come back. There's about 25 different places in the
code that rely on it that need to be changed the same way I changed
TestReplication.
Perfect for someone that wants to get started with HBase dev :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12892) Add a class to allow taking a snapshot from the command line
[ https://issues.apache.org/jira/browse/HBASE-12892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292384#comment-14292384 ] Hudson commented on HBASE-12892: FAILURE: Integrated in HBase-0.98 #817 (See [https://builds.apache.org/job/HBase-0.98/817/]) Revert HBASE-12892 Add a class to allow taking a snapshot from the command line (apurtell: rev de01f6f4d58d3647496fcedbe8b51d8fe3534e27) * hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/CreateSnapshot.java * bin/hbase HBASE-12892 Add a class to allow taking a snapshot from the command line (apurtell: rev 98adbf186ee06089ff38083e8dc1358c712f4b44) * hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/CreateSnapshot.java * bin/hbase Add a class to allow taking a snapshot from the command line Key: HBASE-12892 URL: https://issues.apache.org/jira/browse/HBASE-12892 Project: HBase Issue Type: Bug Affects Versions: 2.0.0 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0 Attachments: HBASE-12892-v1.patch, HBASE-12892-v2.patch, HBASE-12892-v3.patch, HBASE-12892.patch It's easier to automate taking a snapshot from the command line than from the hbase shell. We should provide a command that can be called to snapshot a table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12745) Visibility Labels: support visibility labels for user groups.
[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-12745:
-
Release Note:
VisibilityClient API and shell commands can be used to grant and clear
visibility authorizations of a group.
e.g.
set_auths '@group1', ['SECRET','PRIVATE']
get_auths '@group1'
clear_auths '@group1', ['SECRET','PRIVATE']
When checking visibility authorizations of a user, the server will include the
visibility authorizations of the groups of which the user is a member, together
with the user's own.
On the other hand, get_auths 'user1' will only get user1's own visibility
authorizations.
clear_auths 'user1' will only clear user1's own visibility authorizations.
The visibility authorizations of a group can be changed by invoking the API or
command on the '@group1' itself.
Note:
The following two methods have been deprecated in VisibilityLabelService from
0.98.10 and will be removed in 2.0+ releases.
getAuths(byte[], boolean)
havingSystemAuth(byte[])
Use the following methods instead:
getUserAuths(byte[], boolean)
getGroupAuths(String[], boolean)
havingSystemAuth(User)
was:
VisibilityClient API and shell commands can be used to grant and clear
visibility authorizations of a group.
e.g.
set_auths '@group1', ['SECRET','PRIVATE']
get_auths '@group1'
clear_auths '@group1', ['SECRET','PRIVATE']
When checking visibility authorizations of a user, the server will include the
visibility authorizations of the groups of which the user is a member, together
with the user's own.
On the other hand, get_auths 'user1' will only get user1's own visibility
authorizations.
clear_auths 'user1' will only clear user1's own visibility authorizations.
The visibility authorizations of a group can be changed by invoking the API or
command on the '@group1' itself.
Visibility Labels: support visibility labels for user groups.
--
Key: HBASE-12745
URL: https://issues.apache.org/jira/browse/HBASE-12745
Project: HBase
Issue Type: Improvement
Components: security
Affects Versions: 1.0.0, 0.98.9, 0.99.2
Reporter: Jerry He
Assignee: Jerry He
Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0
Attachments: HBASE-12745-master-v1.patch,
HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
HBASE-12745-v7-0.98-with-update.patch, HBASE-12745-v7-0.98.patch,
HBASE-12745-v7-branch1.patch, hbase-12745_branch-1-addendum.patch,
hbase-12745_branch-1-addendum2.patch
The thinking is that we should support visibility labels to be associated
with user groups.
We will then be able grant visibility labels to a group in addition to
individual users, which provides convenience and usability.
We will use '@group' to denote a group name, as similarly done in
AcccessController.
For example,
{code}
set_auths '@group1', ['SECRET','PRIVATE']
{code}
{code}
get_auth '@group1'
{code}
A user belonging to 'group1' will have all the visibility labels granted to
'group1'
We'll also support super user groups as specified in hbase-site.xml.
The code update will mainly be on the server side VisibilityLabelService
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
Srikanth Srungarapu created HBASE-12925:
---
Summary: Use acl cache for doing access control checks in prepare
and clean phases of Bulkloading.
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess, which
performs scan on ACL table, instead of using TableAuthManager. Also, the method
hasSomeAccess has a logical error, as it doesn't filter the acl scan results
by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
userPerm.getUser.equals(requestUser). This issue will help us in getting rid of
this problematic implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
[
https://issues.apache.org/jira/browse/HBASE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-12925:
Status: Open (was: Patch Available)
Use acl cache for doing access control checks in prepare and clean phases of
Bulkloading.
-
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess,
which performs scan on ACL table, instead of using TableAuthManager. Also,
the method hasSomeAccess has a logical error, as it doesn't filter the acl
scan results by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
userPerm.getUser.equals(requestUser). This issue will help us in getting rid
of this problematic implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
[
https://issues.apache.org/jira/browse/HBASE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-12925:
Attachment: HBASE-12925.patch
Use acl cache for doing access control checks in prepare and clean phases of
Bulkloading.
-
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Attachments: HBASE-12925.patch
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess,
which performs scan on ACL table, instead of using TableAuthManager. Also,
the method hasSomeAccess has a logical error, as it doesn't filter the acl
scan results by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
userPerm.getUser.equals(requestUser). This issue will help us in getting rid
of this problematic implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
[
https://issues.apache.org/jira/browse/HBASE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-12925:
Status: Patch Available (was: Open)
Use acl cache for doing access control checks in prepare and clean phases of
Bulkloading.
-
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Attachments: HBASE-12925.patch
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess,
which performs scan on ACL table, instead of using TableAuthManager. Also,
the method hasSomeAccess has a logical error, as it doesn't filter the acl
scan results by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
userPerm.getUser.equals(requestUser). This issue will help us in getting rid
of this problematic implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
[
https://issues.apache.org/jira/browse/HBASE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-12925:
Attachment: (was: HBASE-12925.patch)
Use acl cache for doing access control checks in prepare and clean phases of
Bulkloading.
-
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess,
which performs scan on ACL table, instead of using TableAuthManager. Also,
the method hasSomeAccess has a logical error, as it doesn't filter the acl
scan results by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
userPerm.getUser.equals(requestUser). This issue will help us in getting rid
of this problematic implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-7541) Convert all tests that use HBaseTestingUtility.createMultiRegions to HBA.createTable
[
https://issues.apache.org/jira/browse/HBASE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292501#comment-14292501
]
stack commented on HBASE-7541:
--
Pushed to branch-1. Thanks [~jonathan.lawlor]
Convert all tests that use HBaseTestingUtility.createMultiRegions to
HBA.createTable
Key: HBASE-7541
URL: https://issues.apache.org/jira/browse/HBASE-7541
Project: HBase
Issue Type: Improvement
Reporter: Jean-Daniel Cryans
Assignee: Jonathan Lawlor
Fix For: 2.0.0, 1.1.0
Attachments: HBASE7541_patch_v1.txt, HBASE_7541_v2.txt,
HBASE_7541_v2.txt, HBASE_7541_v2_branch-1.txt, HBASE_7541_v2_branch-1.txt
Like I discussed in HBASE-7534, {{HBaseTestingUtility.createMultiRegions}}
should disappear and not come back. There's about 25 different places in the
code that rely on it that need to be changed the same way I changed
TestReplication.
Perfect for someone that wants to get started with HBase dev :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-6778) Deprecate Chore; its a thread per task when we should have one thread to do all tasks
[ https://issues.apache.org/jira/browse/HBASE-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292508#comment-14292508 ] stack commented on HBASE-6778: -- Are the findbugs and/or tests yours [~jonathan.lawlor]? Thanks. Deprecate Chore; its a thread per task when we should have one thread to do all tasks - Key: HBASE-6778 URL: https://issues.apache.org/jira/browse/HBASE-6778 Project: HBase Issue Type: Bug Reporter: stack Assignee: Jonathan Lawlor Fix For: 2.0.0, 1.1.0 Attachments: AFTER_thread_dump.txt, BEFORE_thread_dump.txt, HBASE_6778_WIP_v1.patch, HBASE_6778_WIP_v2.patch, thread_dump_HMaster.local.out Should use something like ScheduledThreadPoolExecutor instead (Elliott said this first I think; J-D said something similar just now). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12927) TestFromClientSide#testScanMetrics() failing due to duplicate createTable commands
[ https://issues.apache.org/jira/browse/HBASE-12927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-12927: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the patch, Jonathan. TestFromClientSide#testScanMetrics() failing due to duplicate createTable commands -- Key: HBASE-12927 URL: https://issues.apache.org/jira/browse/HBASE-12927 Project: HBase Issue Type: Bug Affects Versions: 1.1.0 Reporter: Jonathan Lawlor Assignee: Jonathan Lawlor Priority: Minor Fix For: 1.1.0 Attachments: HBASE_12927_v1.patch The testScanMetrics test is failing because a createTable command was not removed in the branch-1 patch from HBASE-7541. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12927) TestFromClientSide#testScanMetrics() failing due to duplicate createTable commands
[ https://issues.apache.org/jira/browse/HBASE-12927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Lawlor updated HBASE-12927: Status: Patch Available (was: Open) retrying: failed because patch tried to apply to master instead of branch-1 TestFromClientSide#testScanMetrics() failing due to duplicate createTable commands -- Key: HBASE-12927 URL: https://issues.apache.org/jira/browse/HBASE-12927 Project: HBase Issue Type: Bug Affects Versions: 1.1.0 Reporter: Jonathan Lawlor Assignee: Jonathan Lawlor Priority: Minor Fix For: 1.1.0 Attachments: HBASE_12927_v1.patch The testScanMetrics test is failing because a createTable command was not removed in the branch-1 patch from HBASE-7541. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12745) Visibility Labels: support visibility labels for user groups.
[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292840#comment-14292840
]
Hudson commented on HBASE-12745:
SUCCESS: Integrated in HBase-1.0 #689 (See
[https://builds.apache.org/job/HBase-1.0/689/])
HBASE-12745 Visibility Labels: support visibility labels for user groups.
(Addendum2 for BC between 0.98 and branch-1) (Anoop Sam John) (enis: rev
bf8287ebe9a92dea4959f5910ab52ca3d56c96d0)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityController.java
Visibility Labels: support visibility labels for user groups.
--
Key: HBASE-12745
URL: https://issues.apache.org/jira/browse/HBASE-12745
Project: HBase
Issue Type: Improvement
Components: security
Affects Versions: 1.0.0, 0.98.9, 0.99.2
Reporter: Jerry He
Assignee: Jerry He
Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0
Attachments: HBASE-12745-master-v1.patch,
HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
HBASE-12745-v7-0.98-with-update.patch, HBASE-12745-v7-0.98.patch,
HBASE-12745-v7-branch1.patch, hbase-12745_branch-1-addendum.patch,
hbase-12745_branch-1-addendum2.patch
The thinking is that we should support visibility labels to be associated
with user groups.
We will then be able grant visibility labels to a group in addition to
individual users, which provides convenience and usability.
We will use '@group' to denote a group name, as similarly done in
AcccessController.
For example,
{code}
set_auths '@group1', ['SECRET','PRIVATE']
{code}
{code}
get_auth '@group1'
{code}
A user belonging to 'group1' will have all the visibility labels granted to
'group1'
We'll also support super user groups as specified in hbase-site.xml.
The code update will mainly be on the server side VisibilityLabelService
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12745) Visibility Labels: support visibility labels for user groups.
[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292857#comment-14292857
]
Hudson commented on HBASE-12745:
FAILURE: Integrated in HBase-1.1 #111 (See
[https://builds.apache.org/job/HBase-1.1/111/])
HBASE-12745 Visibility Labels: support visibility labels for user groups.
(Addendum2 for BC between 0.98 and branch-1) (Anoop Sam John) (enis: rev
a84233ae350ea921740d532cfdc2b79731f96555)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityController.java
Visibility Labels: support visibility labels for user groups.
--
Key: HBASE-12745
URL: https://issues.apache.org/jira/browse/HBASE-12745
Project: HBase
Issue Type: Improvement
Components: security
Affects Versions: 1.0.0, 0.98.9, 0.99.2
Reporter: Jerry He
Assignee: Jerry He
Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0
Attachments: HBASE-12745-master-v1.patch,
HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
HBASE-12745-v7-0.98-with-update.patch, HBASE-12745-v7-0.98.patch,
HBASE-12745-v7-branch1.patch, hbase-12745_branch-1-addendum.patch,
hbase-12745_branch-1-addendum2.patch
The thinking is that we should support visibility labels to be associated
with user groups.
We will then be able grant visibility labels to a group in addition to
individual users, which provides convenience and usability.
We will use '@group' to denote a group name, as similarly done in
AcccessController.
For example,
{code}
set_auths '@group1', ['SECRET','PRIVATE']
{code}
{code}
get_auth '@group1'
{code}
A user belonging to 'group1' will have all the visibility labels granted to
'group1'
We'll also support super user groups as specified in hbase-site.xml.
The code update will mainly be on the server side VisibilityLabelService
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12916) No access control for replicating WAL entries
[
https://issues.apache.org/jira/browse/HBASE-12916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292889#comment-14292889
]
Srikanth Srungarapu commented on HBASE-12916:
-
nit: In AccessController, is the following code block necessary?
{code}
+ @Override
+ public void
postReplicateLogEntries(ObserverContextRegionServerCoprocessorEnvironment ctx,
+ ListWALEntry entries, CellScanner cells) throws IOException {
+ }
{code}
Also, is the post hook call in testReplicateLogEntries() really needed?
No access control for replicating WAL entries
-
Key: HBASE-12916
URL: https://issues.apache.org/jira/browse/HBASE-12916
Project: HBase
Issue Type: Bug
Components: Replication
Affects Versions: 2.0.0, 0.94.26, 0.98.12
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Attachments: HBASE-12916-v1.diff, HBASE-12916-v2.diff
Currently, there is no access control for replicating WAL entries in secure
HBase cluster. Any authenticated user can write any data they want to any
table of a secure cluster by using the replication api.
Simple solution is to add permission check before replicating WAL entries.
And only user with global write permission can replicate WAL entries to this
cluster.
Another option is adding Replication action in hbase and only user with
Replication permission can replicate WAL entries to this cluster?
[~apurtell]
What's your suggestion? Thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12925) Use acl cache for doing access control checks in prepare and clean phases of Bulkloading.
[
https://issues.apache.org/jira/browse/HBASE-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292921#comment-14292921
]
Hadoop QA commented on HBASE-12925:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694673/HBASE-12925_v2.patch
against master branch at commit 1b9367d465dc99559b4ac36b30be5e2e98ff67a7.
ATTACHMENT ID: 12694673
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 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:
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.hadoop.hbase.TestAcidGuarantees.testScanAtomicity(TestAcidGuarantees.java:354)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12594//console
This message is automatically generated.
Use acl cache for doing access control checks in prepare and clean phases of
Bulkloading.
-
Key: HBASE-12925
URL: https://issues.apache.org/jira/browse/HBASE-12925
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Attachments: HBASE-12925.patch, HBASE-12925_v2.patch
Currently, prepareBulkLoad and cleanupBulkLoad are using hasSomeAccess,
which performs scan on ACL table, instead of using TableAuthManager. Also,
the method hasSomeAccess has a logical error, as it doesn't filter the acl
scan results by the current active user. More specifically
{code}
for (UserPermission userPerm: perms) {
for (Action userAction: userPerm.getActions()) {
if (userAction.equals(action)) {
return AuthResult.allow(method, Access allowed, requestUser,
action, tableName, null, null);
}
}
}
{code}
The if clause ideally should be having something like
[jira] [Commented] (HBASE-7847) Use zookeeper multi to clear znodes
[ https://issues.apache.org/jira/browse/HBASE-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293035#comment-14293035 ] Rakesh R commented on HBASE-7847: - Thanks a lot [~saint@gmail.com], [~tedyu], [~rajeshbabu] for the great support! Use zookeeper multi to clear znodes --- Key: HBASE-7847 URL: https://issues.apache.org/jira/browse/HBASE-7847 Project: HBase Issue Type: Sub-task Reporter: Ted Yu Assignee: Rakesh R Fix For: 2.0.0, 1.1.0 Attachments: 7847-v1.txt, 7847_v6.patch, 7847_v6.patch, HBASE-7847.patch, HBASE-7847.patch, HBASE-7847.patch, HBASE-7847_v4.patch, HBASE-7847_v5.patch, HBASE-7847_v6.patch, HBASE-7847_v7.1.patch, HBASE-7847_v7.patch, HBASE-7847_v9.patch In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) should utilize zookeeper multi so that they're atomic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[
https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293052#comment-14293052
]
stack commented on HBASE-4368:
--
That works:
{code}
hbase(main):002:0 processlist
1 tasks as of: 2015-01-26 22:35:35
+-+-+--+--+--+
| Host| Start Time | State| Description
| Status |
+-+-+--+--+--+
| c2022.halxg | 2015-01-26 22:34:09 | COMPLETE | Compacting meta in
Integratio... | Compaction complete (since 57 sec... |
+-+-+--+--+--+
{code}
Expose processlist in shell (per regionserver and perhaps by cluster)
-
Key: HBASE-4368
URL: https://issues.apache.org/jira/browse/HBASE-4368
Project: HBase
Issue Type: Task
Components: shell
Reporter: stack
Assignee: Talat UYARER
Labels: beginner
Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch,
HBASE-4368v2.patch, HBASE-4368v3.patch
HBASE-4057 adds processlist and it shows in the RS UI. This issue is about
getting the processlist to show in the shell, like it does in mysql.
Labelling it noob; this is a pretty substantial issue but it shouldn't be too
hard -- it'd mostly be plumbing from RS into the shell.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293049#comment-14293049 ] Talat UYARER commented on HBASE-4368: - In shell I addressed to processlist command. Can you use *processlist* ? Expose processlist in shell (per regionserver and perhaps by cluster) - Key: HBASE-4368 URL: https://issues.apache.org/jira/browse/HBASE-4368 Project: HBase Issue Type: Task Components: shell Reporter: stack Assignee: Talat UYARER Labels: beginner Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, HBASE-4368v2.patch, HBASE-4368v3.patch HBASE-4057 adds processlist and it shows in the RS UI. This issue is about getting the processlist to show in the shell, like it does in mysql. Labelling it noob; this is a pretty substantial issue but it shouldn't be too hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12893) IntegrationTestBigLinkedListWithVisibility should use buffered writes
[ https://issues.apache.org/jira/browse/HBASE-12893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293081#comment-14293081 ] Hudson commented on HBASE-12893: FAILURE: Integrated in HBase-TRUNK #6060 (See [https://builds.apache.org/job/HBase-TRUNK/6060/]) HBASE-12893 - IntegrationTestBigLinkedListWithVisibility should use (ramkrishna: rev cfb0cf72d4b12a22af7a8267de8baaeef6dfc570) * hbase-it/src/test/java/org/apache/hadoop/hbase/test/IntegrationTestBigLinkedListWithVisibility.java IntegrationTestBigLinkedListWithVisibility should use buffered writes - Key: HBASE-12893 URL: https://issues.apache.org/jira/browse/HBASE-12893 Project: HBase Issue Type: Improvement Components: integration tests Reporter: Nick Dimiduk Assignee: Jingcheng Du Priority: Minor Attachments: HBASE-12893-V2.diff, HBASE-12893.diff This was noticed in review over on HBASE-12728. This test is not doing client-side buffering of writes, so probably we can speed it up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-7847) Use zookeeper multi to clear znodes
[ https://issues.apache.org/jira/browse/HBASE-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293082#comment-14293082 ] Hudson commented on HBASE-7847: --- FAILURE: Integrated in HBase-TRUNK #6060 (See [https://builds.apache.org/job/HBase-TRUNK/6060/]) HBASE-7847 Use zookeeper multi to clear znodes (Rakesh R) (tedyu: rev aaeafca9206341761094b1bcd27580f3978356bb) * hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java * hbase-server/src/test/java/org/apache/hadoop/hbase/zookeeper/TestZKMulti.java Use zookeeper multi to clear znodes --- Key: HBASE-7847 URL: https://issues.apache.org/jira/browse/HBASE-7847 Project: HBase Issue Type: Sub-task Reporter: Ted Yu Assignee: Rakesh R Fix For: 2.0.0, 1.1.0 Attachments: 7847-v1.txt, 7847_v6.patch, 7847_v6.patch, HBASE-7847.patch, HBASE-7847.patch, HBASE-7847.patch, HBASE-7847_v4.patch, HBASE-7847_v5.patch, HBASE-7847_v6.patch, HBASE-7847_v7.1.patch, HBASE-7847_v7.patch, HBASE-7847_v9.patch In ZKProcedureUtil, clearChildZNodes() and clearZNodes(String procedureName) should utilize zookeeper multi so that they're atomic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11354) HConnectionImplementation#DelayedClosing does not start
[
https://issues.apache.org/jira/browse/HBASE-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293106#comment-14293106
]
Hadoop QA commented on HBASE-11354:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12694714/HBASE_11354%20%281%29.patch
against master branch at commit cfb0cf72d4b12a22af7a8267de8baaeef6dfc570.
ATTACHMENT ID: 12694714
{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 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:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
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/12598//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/checkstyle-aggregate.html
Javadoc warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12598//console
This message is automatically generated.
HConnectionImplementation#DelayedClosing does not start
---
Key: HBASE-11354
URL: https://issues.apache.org/jira/browse/HBASE-11354
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 0.99.0, 0.98.3
Reporter: Qianxi Zhang
Assignee: Qianxi Zhang
Priority: Minor
Attachments: HBASE_11354 (1).patch, HBASE_11354.patch,
HBASE_11354.patch, HBASE_11354.patch
The method createAndStart in class DelayedClosing only creates a instance,
but forgets to start it. So thread delayedClosing is not running all the time.
ConnectionManager#1623
{code}
static DelayedClosing createAndStart(HConnectionImplementation hci){
Stoppable stoppable = new Stoppable() {
private volatile boolean isStopped = false;
@Override public void stop(String why) { isStopped = true;}
@Override public boolean isStopped() {return isStopped;}
};
[jira] [Updated] (HBASE-12927) TestFromClientSide#testScanMetrics() failing due to duplicate createTable commands
[ https://issues.apache.org/jira/browse/HBASE-12927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Lawlor updated HBASE-12927: Status: Open (was: Patch Available) TestFromClientSide#testScanMetrics() failing due to duplicate createTable commands -- Key: HBASE-12927 URL: https://issues.apache.org/jira/browse/HBASE-12927 Project: HBase Issue Type: Bug Affects Versions: 1.1.0 Reporter: Jonathan Lawlor Assignee: Jonathan Lawlor Priority: Minor Fix For: 1.1.0 Attachments: HBASE_12927_v1.patch The testScanMetrics test is failing because a createTable command was not removed in the branch-1 patch from HBASE-7541. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11908) Region replicas should be added to the meta table at the time of table creation
[ https://issues.apache.org/jira/browse/HBASE-11908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292854#comment-14292854 ] Devaraj Das commented on HBASE-11908: - +1 Region replicas should be added to the meta table at the time of table creation --- Key: HBASE-11908 URL: https://issues.apache.org/jira/browse/HBASE-11908 Project: HBase Issue Type: Sub-task Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 2.0.0, 1.1.0 Attachments: hbase-11908_v1.patch While testing async replication handling and failover handling for region replicas, we've found that sometimes the secondary region replicas do not open and update meta quickly enough, and hence meta would not contain any information about the region replica id. If a reader caches the meta row before all region replicas are open the first time (such as the async wal replication endpoint), then it may miss the region replica and won't know about it until it refreshes it's cache again. Instead, we should add entries to the meta for all of the region replicas at the time of create table (just like primary regions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12917) HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to recursive call in createCell function
[ https://issues.apache.org/jira/browse/HBASE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292907#comment-14292907 ] Hudson commented on HBASE-12917: FAILURE: Integrated in HBase-1.0 #690 (See [https://builds.apache.org/job/HBase-1.0/690/]) HBASE-12917 HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to recursive call in createCell function (Vikas Vishwakarma) (enis: rev 2f5e6e47f30e64d34e1db5734c9d91fe03ef4e1b) * hbase-server/src/test/java/org/apache/hadoop/hbase/HFilePerformanceEvaluation.java HFilePerformanceEvaluation Scan tests fail with StackOverflowError due to recursive call in createCell function --- Key: HBASE-12917 URL: https://issues.apache.org/jira/browse/HBASE-12917 Project: HBase Issue Type: Bug Components: hbase Affects Versions: 2.0.0 Environment: Ubuntu Reporter: Vikas Vishwakarma Assignee: Vikas Vishwakarma Fix For: 1.0.0, 2.0.0, 1.1.0 Attachments: HBASE-12917.patch While trying to run HFilePerformanceEvaluation with hbase-2.0.0 UniformRandomSmallScan is failing with StackOverflowError. Lookes related to the byte array to Cell based HFile changes. 2015-01-26 12:42:09,551 WARN [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable 2015-01-26 12:42:09,760 INFO [main] hbase.HFilePerformanceEvaluation: Running SequentialWriteBenchmark for 100 rows. 2015-01-26 12:42:10,007 INFO [main] hfile.CacheConfig: CacheConfig:disabled 2015-01-26 12:42:11,560 INFO [main] hbase.HFilePerformanceEvaluation: Running SequentialWriteBenchmark for 100 rows took 1496ms. 2015-01-26 12:42:11,561 INFO [0] hbase.HFilePerformanceEvaluation: Running UniformRandomSmallScan for 100 rows. 2015-01-26 12:42:11,561 INFO [0] hfile.CacheConfig: CacheConfig:disabled Exception in thread 0 java.lang.StackOverflowError at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) at org.apache.hadoop.hbase.HFilePerformanceEvaluation.createCell(HFilePerformanceEvaluation.java:78) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12627) Add back snapshot batching facility from HBASE-11360 dropped by HBASE-11742
[ https://issues.apache.org/jira/browse/HBASE-12627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292927#comment-14292927 ] Enis Soztutar commented on HBASE-12627: --- bq. I have it staged for branch-1.0, ok to push now Enis Soztutar? Should be ok if snapshot tests pass. Add back snapshot batching facility from HBASE-11360 dropped by HBASE-11742 --- Key: HBASE-12627 URL: https://issues.apache.org/jira/browse/HBASE-12627 Project: HBase Issue Type: Improvement Components: master, scaling Reporter: stack Assignee: churro morales Fix For: 2.0.0, 0.98.10, 1.1.0 Attachments: HBASE-12627-v1.patch, HBASE-12627.patch HBASE-11742 dropped the batching facility from HBASE-11360. It is less necessary now we do manifests rather than file-per but on big clusters the batching will come in handy. This issue is about studying and porting over the HBASE-11360 batching. This issue comes of discussion up on dev list http://search-hadoop.com/m/DHED40jnXP Marked as component 'scaling'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12627) Add back snapshot batching facility from HBASE-11360 dropped by HBASE-11742
[ https://issues.apache.org/jira/browse/HBASE-12627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292950#comment-14292950 ] Hudson commented on HBASE-12627: FAILURE: Integrated in HBase-TRUNK #6058 (See [https://builds.apache.org/job/HBase-TRUNK/6058/]) HBASE-12627 Add back snapshot batching facility (apurtell: rev a85cb0f89a01495897e513df37e435d013e152ce) * hbase-server/src/test/java/org/apache/hadoop/hbase/master/snapshot/TestSnapshotFileCache.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotLogCleaner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotFileCache.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotHFileCleaner.java Add back snapshot batching facility from HBASE-11360 dropped by HBASE-11742 --- Key: HBASE-12627 URL: https://issues.apache.org/jira/browse/HBASE-12627 Project: HBase Issue Type: Improvement Components: master, scaling Reporter: stack Assignee: churro morales Fix For: 2.0.0, 0.98.10, 1.1.0 Attachments: HBASE-12627-v1.patch, HBASE-12627.patch HBASE-11742 dropped the batching facility from HBASE-11360. It is less necessary now we do manifests rather than file-per but on big clusters the batching will come in handy. This issue is about studying and porting over the HBASE-11360 batching. This issue comes of discussion up on dev list http://search-hadoop.com/m/DHED40jnXP Marked as component 'scaling'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
