[jira] [Commented] (HBASE-13270) Setter for Result#getStats is #addResults; confusing!
[
https://issues.apache.org/jira/browse/HBASE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370874#comment-14370874
]
Lars George commented on HBASE-13270:
-
Since the I am not sure what the original intent was, maybe [~jesse_yates]
could chime in?
>From the usage which does this
{code}
} else if (roe.hasResult()) {
responseValue = ProtobufUtil.toResult(roe.getResult(), cells);
// add the load stats, if we got any
if (roe.hasLoadStats()) {
((Result) responseValue).addResults(roe.getLoadStats());
}
{code}
it looks like a one off call, i.e. straight assignment as the code does
internally already. In this case I am +1 for naming it {{setStats()}} instead
as you suggest.
In fact, I am a hater for these short names anyways (all IDEs with
autocompletion take this pain away these days) and would rather suggest we use
{{setStatistics()/getStatistics()}} - and since this is arbitrary, even better
{{setRegionLoadStatistics()/getRegionLoadStatistics()}}. This makes it much
more user friendly without having to resort to JavaDoc and other measures.
> Setter for Result#getStats is #addResults; confusing!
> -
>
> Key: HBASE-13270
> URL: https://issues.apache.org/jira/browse/HBASE-13270
> Project: HBase
> Issue Type: Improvement
>Reporter: stack
> Labels: beginner
> Attachments: HBASE-13270.patch
>
>
> Below is our [~larsgeorge] on a finding he made reviewing our API:
> "Result class having getStats() and addResults(Stats) makes little sense..."
> "...the naming is just weird. You have a getStats() getter and an
> addResults(Stats) setter???"
> "...Especially in the Result class and addResult() is plain misleading..."
> This issue is about deprecating addResults and replacing it with addStats in
> its place.
> The getStats/addResult is recent. It came in with:
> {code}
> commit a411227b0ebf78b4ee8ae7179e162b54734e77de
> Author: Jesse Yates
> Date: Tue Oct 28 16:14:16 2014 -0700
> HBASE-5162 Basic client pushback mechanism
> ...
> {code}
> RegionLoadStats don't belong in Result if you ask me but better in the
> enveloping on invocations... but that is another issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13283) Document the steps for rolling back the security on hbase.
[
https://issues.apache.org/jira/browse/HBASE-13283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370883#comment-14370883
]
Srikanth Srungarapu commented on HBASE-13283:
-
[~apurtell] You might have used wrong jira number while making the commit. The
commit(38286ec3a0d39f4a14777a81a99024bc8266c8d7) has the following changes
{code}
+Groups can be granted visibility labels the same way as users. Groups are
prefixed with an @ symbol. When checking visibility labels of a user, the
server wi
+When the visibility labels are retrieved using API `VisibilityClient#getAuths`
or Shell command `get_auths` for a user, we will return labels added specifica
+
Visibility label access checking is performed by the VisibilityController
coprocessor.
You can use interface `VisibilityLabelService` to provide a custom
implementation and/or control the way that visibility labels are stored with
cells.
See the source file
_hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithCustomVisLabService.java_
for one
@@ -1171,12 +1174,16 @@ hbase> set_auths 'service', [ 'service' ]
-gbase> set_auths 'testuser', [ 'test' ]
+hbase> set_auths 'testuser', [ 'test' ]
hbase> set_auths 'qa', [ 'test', 'developer' ]
+
+
+hbase> set_auths '@qagroup', [ 'test' ]
+
+
.Java API
@@ -1213,6 +1220,10 @@ hbase> clear_auths 'testuser', [ 'test' ]
hbase> clear_auths 'qa', [ 'test', 'developer' ]
+
+
+hbase> clear_auths '@qagroup', [ 'test', 'developer' ]
+
{code}
> Document the steps for rolling back the security on hbase.
> --
>
> Key: HBASE-13283
> URL: https://issues.apache.org/jira/browse/HBASE-13283
> Project: HBase
> Issue Type: Sub-task
>Reporter: Srikanth Srungarapu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
>
> Would be great to document the steps the user should follow to rollback the
> security. The following are
>* shutdown hbase
>* run hbase clean up script with --cleanAcls introduced in HBASE-13162.
>* remove from the hbase-site.xml conf
> {code}
> hbase.security.authentication
> hbase.regionserver.kerberos.principal
> hbase.regionserver.keytab.file
> hbase.master.kerberos.principal
> hbase.master.keytab.file
> {code}
> * Removing AccessController coprocessors from hbase-site.xml
> * Address "hbase.security.authorization" based on outcome of HBASE-13275.
> cc: [~misty]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13297) 0.98 and 1.0: Remove client side result size calculation
[ https://issues.apache.org/jira/browse/HBASE-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370891#comment-14370891 ] Lars Hofhansl commented on HBASE-13297: --- Actually, lemme think about the extra RPC. That would be would be one more RPC for every region touched by a scanner. If the scanner touches one region only, we've doubled the number of RPC. Also need to fix ClientSmallScanner... Not sure there _is_ a better solution for 0.98... Or we can also document for 0.98 that one must make 100% sure that client and server have the exact same value for hbase.client.scanner.max.result.size. Ideally - like caching - this could be driven from the client, then there would not be a problem either, I guess. Let's do the RC as is, and we'll think about this for 0.98.13. > 0.98 and 1.0: Remove client side result size calculation > > > Key: HBASE-13297 > URL: https://issues.apache.org/jira/browse/HBASE-13297 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 1.0.1, 0.98.13 > > Attachments: 13297-0.98.txt > > > As described in parent, this can lead to missed rows when the client and > server calculate different size values. > The patch here proposes a backwards compatible patch for 0.98 and 1.0.x. > Parent will do a patch for 1.1 and 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12972) Region, a supportable public/evolving subset of HRegion
[
https://issues.apache.org/jira/browse/HBASE-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370897#comment-14370897
]
James Taylor commented on HBASE-12972:
--
I think this change benefits not just Phoenix, but any application using these
coprocessor interfaces.
As far as the Phoenix code base, the coprocessors classes are pretty isolated
and do not change very often. They're used more as entry points that invoke
common core classes (which is where the bulk of changes occur). I don't think
the burden would be high if Phoenix had to have another branch.
> Region, a supportable public/evolving subset of HRegion
> ---
>
> Key: HBASE-12972
> URL: https://issues.apache.org/jira/browse/HBASE-12972
> Project: HBase
> Issue Type: New Feature
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-12972-0.98.patch, HBASE-12972.patch,
> HBASE-12972.patch
>
>
> On HBASE-12566, [~lhofhansl] proposed:
> {quote}
> Maybe we can have a {{Region}} interface that is to {{HRegion}} is what
> {{Store}} is to {{HStore}}. Store marked with {{@InterfaceAudience.Private}}
> but used in some coprocessor hooks.
> {quote}
> By example, now coprocessors have to reach into HRegion in order to
> participate in row and region locking protocols, this is one area where the
> functionality is legitimate for coprocessors but not for users, so an
> in-between interface make sense.
> In addition we should promote {{Store}}'s interface audience to
> LimitedPrivate(COPROC).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13272) Get.setClosestRowBefore() breaks specific column Get
[
https://issues.apache.org/jira/browse/HBASE-13272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370899#comment-14370899
]
Lars George commented on HBASE-13272:
-
Is it really so hard to fix (did not check yet). We already find the proper
row, we just have to only load the columns that was asked for. Could we not
replace this server side with a reverse scan instead and document the slight
penalty? This is _not_ the old {{HTable.getRowOrBefore()}} function, it is a
new thing that was added to Get in HBASE-5162 for some reason (which I missed
to see documented). [~nkeywal] you deprecated the one on HTable, but the latter
is the one that is in question.
I would suggest leaving it, it is handy. But use the reverse scanner and
simplify the code? {{RSRpcServices}} uses this code right now
{code}
byte[] row = get.getRow().toByteArray();
byte[] family = get.getColumn(0).getFamily().toByteArray();
r = region.getClosestRowBefore(row, family);
{code}
which then in turn calls
{code}
Cell key = store.getRowKeyAtOrBefore(row);
{code}
I am not sure what the plan with these methods is, or if the reverse scanner
still needs them.
As an alternative approach, the code does return a row and has that cached now,
why not issuing a subsequent
{code}
if (r != null && !r.isEmpty()) {
Get newGet = new Get(r.getRow());
...
// complicated copy over of all fields from one Get to another since there is
no such method in get
...
r = region.get(newGet);
}
{code}
Does that cause any issues besides the unnecessary first load of the entire
row? We could change it a little to set the _cjeck for existence only_ flag on
the first call, but looking at HRegion.get() it loads all cells anyways and
then drops them if the flag is set. So nothing gained here?
> Get.setClosestRowBefore() breaks specific column Get
>
>
> Key: HBASE-13272
> URL: https://issues.apache.org/jira/browse/HBASE-13272
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Priority: Trivial
>
> Via [~larsgeorge]
> Get.setClosestRowBefore() is breaking a specific Get that specifies a column.
> If you set the latter to "true" it will return the _entire_ row!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13274) Fix misplaced deprecation in Delete#addXYZ
[
https://issues.apache.org/jira/browse/HBASE-13274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars George updated HBASE-13274:
Fix Version/s: 1.1.0
1.0.1
2.0.0
> Fix misplaced deprecation in Delete#addXYZ
> --
>
> Key: HBASE-13274
> URL: https://issues.apache.org/jira/browse/HBASE-13274
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0, 2.0.0
>Reporter: stack
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.0.1, 1.1.0
>
> Attachments: HBASE-13274.patch
>
>
> Found by [~larsgeorge]
> {code}
> All deleteXYZ() were deprecated in Delete in favour of the matching addXYZ()
> (to mirror Put, Get, etc.) - _but_ for deleteFamilyVersion(). What is worse
> is, the @deprecated for it was added to the addFamilyVersion() replacement!
> Oh man.
> * @deprecated Since hbase-1.0.0. Use {@link #addFamilyVersion(byte[], long)}
> */
@Deprecated
public Delete addFamilyVersion(final byte [] family,
> final long timestamp) {
> The deprecated message is right, but on the wrong method
> (areyoukiddingme)
> Well, I presume it was done right, and will steer clear of deleteXYZ() in
> favor of addXYZ()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13006) Document visibility label support for groups
[ https://issues.apache.org/jira/browse/HBASE-13006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370916#comment-14370916 ] Hudson commented on HBASE-13006: FAILURE: Integrated in HBase-1.0 #816 (See [https://builds.apache.org/job/HBase-1.0/816/]) HBASE-13006 Document visibility label support for groups. (Jerry He) (anoopsamjohn: rev 663d276d5475b51f82e552782ffb297508977610) * hbase-shell/src/main/ruby/shell/commands/clear_auths.rb * hbase-shell/src/main/ruby/shell/commands/set_auths.rb * hbase-shell/src/main/ruby/shell/commands/get_auths.rb > Document visibility label support for groups > > > Key: HBASE-13006 > URL: https://issues.apache.org/jira/browse/HBASE-13006 > Project: HBase > Issue Type: Sub-task >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13006-v2.patch, HBASE-13006-v3.patch, > HBASE-13006.patch, shell-update-only.patch > > > This is to document the changes added from HBASE-12745. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[ https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-13273: Attachment: HBASE-13273.patch updated per [~larsgeorge] suggestion > Make Result.EMPTY_RESULT read-only; currently it can be modified > > > Key: HBASE-13273 > URL: https://issues.apache.org/jira/browse/HBASE-13273 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 1.0.0 >Reporter: stack >Assignee: Mikhail Antonov > Labels: beginner > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch, > HBASE-13273.patch > > > Again from [~larsgeorge] > Result result2 = Result.EMPTY_RESULT; > System.out.println(result2); > result2.copyFrom(result1); > System.out.println(result2); > "What do you think happens when result1 has cells? Yep, you just modified the > shared public EMPTY_RESULT to be not empty anymore." > Fix. Result should be non-modifiable post-construction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[ https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-13273: Status: Open (was: Patch Available) > Make Result.EMPTY_RESULT read-only; currently it can be modified > > > Key: HBASE-13273 > URL: https://issues.apache.org/jira/browse/HBASE-13273 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.0, 0.98.0 >Reporter: stack >Assignee: Mikhail Antonov > Labels: beginner > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch, > HBASE-13273.patch > > > Again from [~larsgeorge] > Result result2 = Result.EMPTY_RESULT; > System.out.println(result2); > result2.copyFrom(result1); > System.out.println(result2); > "What do you think happens when result1 has cells? Yep, you just modified the > shared public EMPTY_RESULT to be not empty anymore." > Fix. Result should be non-modifiable post-construction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[ https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-13273: Status: Patch Available (was: Open) > Make Result.EMPTY_RESULT read-only; currently it can be modified > > > Key: HBASE-13273 > URL: https://issues.apache.org/jira/browse/HBASE-13273 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.0, 0.98.0 >Reporter: stack >Assignee: Mikhail Antonov > Labels: beginner > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch, > HBASE-13273.patch > > > Again from [~larsgeorge] > Result result2 = Result.EMPTY_RESULT; > System.out.println(result2); > result2.copyFrom(result1); > System.out.println(result2); > "What do you think happens when result1 has cells? Yep, you just modified the > shared public EMPTY_RESULT to be not empty anymore." > Fix. Result should be non-modifiable post-construction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13219) Issues with PE tool in trunk
[
https://issues.apache.org/jira/browse/HBASE-13219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370951#comment-14370951
]
ramkrishna.s.vasudevan commented on HBASE-13219:
+1 on patch. But I would still like to know why the multicon false option does
not work as it was working previously.
> Issues with PE tool in trunk
>
>
> Key: HBASE-13219
> URL: https://issues.apache.org/jira/browse/HBASE-13219
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Attachments: 13219.txt, t1
>
>
> -> PE tool tries to create the TEstTable and waits for it to be enabled and
> just hangs there
> Previously this was not happening and the PE tool used to run fine after the
> table creation.
> -> When we try to scan with 25 threads the PE tool fails after some time
> saying Unable to create native threads.
> I lost the Stack trace now. But I could get it easily. It happens here
> {code}
> public void submit(RetryingCallable task, int callTimeout, int id) {
> QueueingFuture newFuture = new QueueingFuture(task, callTimeout);
> executor.execute(Trace.wrap(newFuture));
> tasks[id] = newFuture;
> }
> {code}
> in ResultBoundedCompletionService. This is also new. Previously it used to
> work with 25 threads without any issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13281) 'hbase.bucketcache.size' description in hbase book is not correct
[
https://issues.apache.org/jira/browse/HBASE-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370958#comment-14370958
]
Hadoop QA commented on HBASE-13281:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705848/HBASE-13281.patch
against master branch at commit 0d766544166fc9630bb00ae14a4a34a69d93f127.
ATTACHMENT ID: 12705848
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color: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.camel.component.jetty.jettyproducer.HttpJettyProducerRecipientListCustomThreadPoolTest.testRecipientList(HttpJettyProducerRecipientListCustomThreadPoolTest.java:40)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13326//console
This message is automatically generated.
> 'hbase.bucketcache.size' description in hbase book is not correct
> -
>
> Key: HBASE-13281
> URL: https://issues.apache.org/jira/browse/HBASE-13281
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13281.patch
>
>
> The description about 'hbase.bucketcache.size' is not correct. We either
> specify it as a float or in MB's and the default value that is mentioned is
> never used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13103) [ergonomics] add region size balancing as a feature of master
[
https://issues.apache.org/jira/browse/HBASE-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370963#comment-14370963
]
Mikhail Antonov commented on HBASE-13103:
-
Is it fair to say this one supersedes the one I linked?
> [ergonomics] add region size balancing as a feature of master
> -
>
> Key: HBASE-13103
> URL: https://issues.apache.org/jira/browse/HBASE-13103
> Project: HBase
> Issue Type: Brainstorming
> Components: Usability
>Reporter: Nick Dimiduk
>
> Often enough, folks miss-judge split points or otherwise end up with a
> suboptimal number of regions. We should have an automated, reliable way to
> "reshape" or "balance" a table's region boundaries. This would be for tables
> that contain existing data. This might look like:
> {noformat}
> Admin#reshapeTable(TableName, int numSplits);
> {noformat}
> or from the shell:
> {noformat}
> > reshape TABLE, numSplits
> {noformat}
> Better still would be to have a maintenance process, similar to the existing
> Balancer that runs AssignmentManager on an interval, to run the above
> "reshape" operation on an interval. That way, the cluster will automatically
> self-correct toward a desirable state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13270) Setter for Result#getStats is #addResults; confusing!
[
https://issues.apache.org/jira/browse/HBASE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370964#comment-14370964
]
Jesse Yates commented on HBASE-13270:
-
I think the original naming came from the fact that the method calling
addResults is managing multiple Results, or maybe its adding the result load as
a result of the last requestsneither is necessarily a good reason, but
that's all I can think of :(
[~larsgeorge], generally I agree with your style of naming as well;
setStatistics()/getStatistics() would certainly be better in this case, but
this was to be the foundation of a more widespread statistics mechanism, so
setRegionLoadStatistics() didn't make as much sense in the longer view. Not
sure why I got lazy this time.
Sorry about this fellas - thanks for the cleanup.
+1 on the patch.
bq. RegionLoadStats don't belong in Result
There really wasn't a better place to put it, well, without completely
re-architecting the client (again). It was expedient, got the data where it
needed to go - back into the client's rpc caller. Happy to talk about how we
can do it better :)
> Setter for Result#getStats is #addResults; confusing!
> -
>
> Key: HBASE-13270
> URL: https://issues.apache.org/jira/browse/HBASE-13270
> Project: HBase
> Issue Type: Improvement
>Reporter: stack
> Labels: beginner
> Attachments: HBASE-13270.patch
>
>
> Below is our [~larsgeorge] on a finding he made reviewing our API:
> "Result class having getStats() and addResults(Stats) makes little sense..."
> "...the naming is just weird. You have a getStats() getter and an
> addResults(Stats) setter???"
> "...Especially in the Result class and addResult() is plain misleading..."
> This issue is about deprecating addResults and replacing it with addStats in
> its place.
> The getStats/addResult is recent. It came in with:
> {code}
> commit a411227b0ebf78b4ee8ae7179e162b54734e77de
> Author: Jesse Yates
> Date: Tue Oct 28 16:14:16 2014 -0700
> HBASE-5162 Basic client pushback mechanism
> ...
> {code}
> RegionLoadStats don't belong in Result if you ask me but better in the
> enveloping on invocations... but that is another issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13219) Issues with PE tool in trunk
[
https://issues.apache.org/jira/browse/HBASE-13219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370975#comment-14370975
]
zhangduo commented on HBASE-13219:
--
Did you run it using a 64bit jvm [~ram_krish] ? I used to create over 20,000
threads in one process, it is fine if you have enough memory.
Or maybe we have changed the thread pool usage at client side?
> Issues with PE tool in trunk
>
>
> Key: HBASE-13219
> URL: https://issues.apache.org/jira/browse/HBASE-13219
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Attachments: 13219.txt, t1
>
>
> -> PE tool tries to create the TEstTable and waits for it to be enabled and
> just hangs there
> Previously this was not happening and the PE tool used to run fine after the
> table creation.
> -> When we try to scan with 25 threads the PE tool fails after some time
> saying Unable to create native threads.
> I lost the Stack trace now. But I could get it easily. It happens here
> {code}
> public void submit(RetryingCallable task, int callTimeout, int id) {
> QueueingFuture newFuture = new QueueingFuture(task, callTimeout);
> executor.execute(Trace.wrap(newFuture));
> tasks[id] = newFuture;
> }
> {code}
> in ResultBoundedCompletionService. This is also new. Previously it used to
> work with 25 threads without any issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13270) Setter for Result#getStats is #addResults; confusing!
[
https://issues.apache.org/jira/browse/HBASE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370976#comment-14370976
]
Mikhail Antonov commented on HBASE-13270:
-
To me setRegionLoadStatistics sounds a bit too long for that field (though
nobody pays for bytes.. :) ). setStatistics() sounds about right?
> Setter for Result#getStats is #addResults; confusing!
> -
>
> Key: HBASE-13270
> URL: https://issues.apache.org/jira/browse/HBASE-13270
> Project: HBase
> Issue Type: Improvement
>Reporter: stack
> Labels: beginner
> Attachments: HBASE-13270.patch
>
>
> Below is our [~larsgeorge] on a finding he made reviewing our API:
> "Result class having getStats() and addResults(Stats) makes little sense..."
> "...the naming is just weird. You have a getStats() getter and an
> addResults(Stats) setter???"
> "...Especially in the Result class and addResult() is plain misleading..."
> This issue is about deprecating addResults and replacing it with addStats in
> its place.
> The getStats/addResult is recent. It came in with:
> {code}
> commit a411227b0ebf78b4ee8ae7179e162b54734e77de
> Author: Jesse Yates
> Date: Tue Oct 28 16:14:16 2014 -0700
> HBASE-5162 Basic client pushback mechanism
> ...
> {code}
> RegionLoadStats don't belong in Result if you ask me but better in the
> enveloping on invocations... but that is another issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13270) Setter for Result#getStats is #addResults; confusing!
[
https://issues.apache.org/jira/browse/HBASE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370977#comment-14370977
]
Jesse Yates commented on HBASE-13270:
-
bq. setStatistics() sounds about right?
Yup!
> Setter for Result#getStats is #addResults; confusing!
> -
>
> Key: HBASE-13270
> URL: https://issues.apache.org/jira/browse/HBASE-13270
> Project: HBase
> Issue Type: Improvement
>Reporter: stack
> Labels: beginner
> Attachments: HBASE-13270.patch
>
>
> Below is our [~larsgeorge] on a finding he made reviewing our API:
> "Result class having getStats() and addResults(Stats) makes little sense..."
> "...the naming is just weird. You have a getStats() getter and an
> addResults(Stats) setter???"
> "...Especially in the Result class and addResult() is plain misleading..."
> This issue is about deprecating addResults and replacing it with addStats in
> its place.
> The getStats/addResult is recent. It came in with:
> {code}
> commit a411227b0ebf78b4ee8ae7179e162b54734e77de
> Author: Jesse Yates
> Date: Tue Oct 28 16:14:16 2014 -0700
> HBASE-5162 Basic client pushback mechanism
> ...
> {code}
> RegionLoadStats don't belong in Result if you ask me but better in the
> enveloping on invocations... but that is another issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[ https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370995#comment-14370995 ] Lars George commented on HBASE-13273: - I am +1 on that. :) > Make Result.EMPTY_RESULT read-only; currently it can be modified > > > Key: HBASE-13273 > URL: https://issues.apache.org/jira/browse/HBASE-13273 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 1.0.0 >Reporter: stack >Assignee: Mikhail Antonov > Labels: beginner > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch, > HBASE-13273.patch > > > Again from [~larsgeorge] > Result result2 = Result.EMPTY_RESULT; > System.out.println(result2); > result2.copyFrom(result1); > System.out.println(result2); > "What do you think happens when result1 has cells? Yep, you just modified the > shared public EMPTY_RESULT to be not empty anymore." > Fix. Result should be non-modifiable post-construction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[ https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371019#comment-14371019 ] Mikhail Antonov commented on HBASE-13273: - Thanks for taking a look Lars :) > Make Result.EMPTY_RESULT read-only; currently it can be modified > > > Key: HBASE-13273 > URL: https://issues.apache.org/jira/browse/HBASE-13273 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 1.0.0 >Reporter: stack >Assignee: Mikhail Antonov > Labels: beginner > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch, > HBASE-13273.patch > > > Again from [~larsgeorge] > Result result2 = Result.EMPTY_RESULT; > System.out.println(result2); > result2.copyFrom(result1); > System.out.println(result2); > "What do you think happens when result1 has cells? Yep, you just modified the > shared public EMPTY_RESULT to be not empty anymore." > Fix. Result should be non-modifiable post-construction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13294) Fix the critical ancient loopholes in security testing infrastructure.
[
https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-13294:
Attachment: HBASE-13294_v3.patch
Looking at the test failures related to ACL cell tags, verifyDenied is expected
to handle null. This is a bit misleading because javadoc for AccessTestAction
says that verifyAllowed should handle null.
{code}
/**
* An AccessTestAction performs an action that will be examined to confirm
* the results conform to expected access rights.
*
* To indicate an action was allowed, return null or a non empty list of
* KeyValues.
*
* To indicate the action was not allowed, either throw an
AccessDeniedException
* or return an empty list of KeyValues.
*/
{code}
So, instead I created verifyIfNull and replaced verifyDenied with it. The
semantics for verify methods are as follows.
* verifyAllowed -> passes only in case of null or non-empty list
* verifyDenied -> passes only in case of ADE.
* verifyIfNull -> passes in case of null or ADE.
* verifyIfEmptyList -> passes in case of emtpy list or ADE.
> Fix the critical ancient loopholes in security testing infrastructure.
> --
>
> Key: HBASE-13294
> URL: https://issues.apache.org/jira/browse/HBASE-13294
> Project: HBase
> Issue Type: Bug
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
> Attachments: HBASE-13294.patch, HBASE-13294_v2.patch,
> HBASE-13294_v3.patch
>
>
> Unfortunately, the "verifyDenied" method doesn't fail when action parameter
> returns null. The relevant code snippet
> {code}
> try {
> Object obj = user.runAs(action);
> if (requireException) {
> fail("Expected exception was not thrown for user '" +
> user.getShortName() + "'");
> }
> if (obj != null && obj instanceof List) {
> List results = (List) obj;
> if (results != null && !results.isEmpty()) {
> fail("Unexpected results for user '" + user.getShortName() + "'");
> }
> }
> }
> {code}
> As you can see, when obj is null, it returns silently.
> Fixing this issue has uncovered another major bug. While constructing
> actions, we're using TEST_UTIL.getConnection(), which replaces the "doAs"
> user with the user who initiated the connection. I really am grateful to
> [~mbertozzi] without whom debugging this would have been a nightmare.
> Now, fixing these two issues have uncovered more issues in our tests :). The
> main one is we're allowing the table owner to truncate table in code. But, in
> test, we're not allowing him. We should either remove the code that allows
> owner or document that the table owner can truncate table.
> The other minor issues include granting permissions to namespace, but
> checking whether user was able to access tables inside other namespace.
> That's it, folks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13219) Issues with PE tool in trunk
[
https://issues.apache.org/jira/browse/HBASE-13219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371030#comment-14371030
]
ramkrishna.s.vasudevan commented on HBASE-13219:
Ya it is a 64 bit JVM. I am using the same setup. I have not changed the
thread pool usage - but was something changed in the client side. Even I could
see that some time the TestAcidGuarentees was failing due to native memory
issue.
> Issues with PE tool in trunk
>
>
> Key: HBASE-13219
> URL: https://issues.apache.org/jira/browse/HBASE-13219
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Attachments: 13219.txt, t1
>
>
> -> PE tool tries to create the TEstTable and waits for it to be enabled and
> just hangs there
> Previously this was not happening and the PE tool used to run fine after the
> table creation.
> -> When we try to scan with 25 threads the PE tool fails after some time
> saying Unable to create native threads.
> I lost the Stack trace now. But I could get it easily. It happens here
> {code}
> public void submit(RetryingCallable task, int callTimeout, int id) {
> QueueingFuture newFuture = new QueueingFuture(task, callTimeout);
> executor.execute(Trace.wrap(newFuture));
> tasks[id] = newFuture;
> }
> {code}
> in ResultBoundedCompletionService. This is also new. Previously it used to
> work with 25 threads without any issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13297) 0.98 and 1.0: Remove client side result size calculation
[ https://issues.apache.org/jira/browse/HBASE-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371031#comment-14371031 ] Anoop Sam John commented on HBASE-13297: bq. Or we can also document for 0.98 that one must make 100% sure that client and server have the exact same value for hbase.client.scanner.max.result.size Still if HFile V3 is turned ON, there can be issue because of the tags length size (2 bytes) difference coming with every Cell. In server this 2 bytes might be there in Cells but in client side this will NEVER be there. > 0.98 and 1.0: Remove client side result size calculation > > > Key: HBASE-13297 > URL: https://issues.apache.org/jira/browse/HBASE-13297 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 1.0.1, 0.98.13 > > Attachments: 13297-0.98.txt > > > As described in parent, this can lead to missed rows when the client and > server calculate different size values. > The patch here proposes a backwards compatible patch for 0.98 and 1.0.x. > Parent will do a patch for 1.1 and 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (HBASE-13103) [ergonomics] add region size balancing as a feature of master
[
https://issues.apache.org/jira/browse/HBASE-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-13103 started by Mikhail Antonov.
---
> [ergonomics] add region size balancing as a feature of master
> -
>
> Key: HBASE-13103
> URL: https://issues.apache.org/jira/browse/HBASE-13103
> Project: HBase
> Issue Type: Brainstorming
> Components: Usability
>Reporter: Nick Dimiduk
>Assignee: Mikhail Antonov
>
> Often enough, folks miss-judge split points or otherwise end up with a
> suboptimal number of regions. We should have an automated, reliable way to
> "reshape" or "balance" a table's region boundaries. This would be for tables
> that contain existing data. This might look like:
> {noformat}
> Admin#reshapeTable(TableName, int numSplits);
> {noformat}
> or from the shell:
> {noformat}
> > reshape TABLE, numSplits
> {noformat}
> Better still would be to have a maintenance process, similar to the existing
> Balancer that runs AssignmentManager on an interval, to run the above
> "reshape" operation on an interval. That way, the cluster will automatically
> self-correct toward a desirable state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-13103) [ergonomics] add region size balancing as a feature of master
[
https://issues.apache.org/jira/browse/HBASE-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Antonov reassigned HBASE-13103:
---
Assignee: Mikhail Antonov
> [ergonomics] add region size balancing as a feature of master
> -
>
> Key: HBASE-13103
> URL: https://issues.apache.org/jira/browse/HBASE-13103
> Project: HBase
> Issue Type: Brainstorming
> Components: Usability
>Reporter: Nick Dimiduk
>Assignee: Mikhail Antonov
>
> Often enough, folks miss-judge split points or otherwise end up with a
> suboptimal number of regions. We should have an automated, reliable way to
> "reshape" or "balance" a table's region boundaries. This would be for tables
> that contain existing data. This might look like:
> {noformat}
> Admin#reshapeTable(TableName, int numSplits);
> {noformat}
> or from the shell:
> {noformat}
> > reshape TABLE, numSplits
> {noformat}
> Better still would be to have a maintenance process, similar to the existing
> Balancer that runs AssignmentManager on an interval, to run the above
> "reshape" operation on an interval. That way, the cluster will automatically
> self-correct toward a desirable state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13006) Document visibility label support for groups
[ https://issues.apache.org/jira/browse/HBASE-13006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-13006: --- Resolution: Fixed Fix Version/s: 0.98.13 1.1.0 1.0.1 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to other branches as well. Thanks Jerry. > Document visibility label support for groups > > > Key: HBASE-13006 > URL: https://issues.apache.org/jira/browse/HBASE-13006 > Project: HBase > Issue Type: Sub-task >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13006-v2.patch, HBASE-13006-v3.patch, > HBASE-13006.patch, shell-update-only.patch > > > This is to document the changes added from HBASE-12745. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[
https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371091#comment-14371091
]
Hadoop QA commented on HBASE-13273:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705865/HBASE-13273.patch
against master branch at commit 0d766544166fc9630bb00ae14a4a34a69d93f127.
ATTACHMENT ID: 12705865
{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 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13327//console
This message is automatically generated.
> Make Result.EMPTY_RESULT read-only; currently it can be modified
>
>
> Key: HBASE-13273
> URL: https://issues.apache.org/jira/browse/HBASE-13273
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 1.0.0
>Reporter: stack
>Assignee: Mikhail Antonov
> Labels: beginner
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
>
> Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch,
> HBASE-13273.patch
>
>
> Again from [~larsgeorge]
> Result result2 = Result.EMPTY_RESULT;
> System.out.println(result2);
> result2.copyFrom(result1);
> System.out.println(result2);
> "What do you think happens when result1 has cells? Yep, you just modified the
> shared public EMPTY_RESULT to be not empty anymore."
> Fix. Result should be non-modifiable post-construction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13283) Document the steps for rolling back the security on hbase.
[
https://issues.apache.org/jira/browse/HBASE-13283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371098#comment-14371098
]
Hudson commented on HBASE-13283:
SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #866 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/866/])
Update branch documentation with changes from HBASE-13283 (apurtell: rev
38286ec3a0d39f4a14777a81a99024bc8266c8d7)
* src/main/asciidoc/_chapters/security.adoc
> Document the steps for rolling back the security on hbase.
> --
>
> Key: HBASE-13283
> URL: https://issues.apache.org/jira/browse/HBASE-13283
> Project: HBase
> Issue Type: Sub-task
>Reporter: Srikanth Srungarapu
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
>
>
> Would be great to document the steps the user should follow to rollback the
> security. The following are
>* shutdown hbase
>* run hbase clean up script with --cleanAcls introduced in HBASE-13162.
>* remove from the hbase-site.xml conf
> {code}
> hbase.security.authentication
> hbase.regionserver.kerberos.principal
> hbase.regionserver.keytab.file
> hbase.master.kerberos.principal
> hbase.master.keytab.file
> {code}
> * Removing AccessController coprocessors from hbase-site.xml
> * Address "hbase.security.authorization" based on outcome of HBASE-13275.
> cc: [~misty]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13199) Some small improvements on canary tool
[ https://issues.apache.org/jira/browse/HBASE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371135#comment-14371135 ] Matteo Bertozzi commented on HBASE-13199: - [~liushaohui] with the addendum don't we end up with the same "redundant null-check" problem? I'm specifically talking about the if table != null line 211 in the first try catch we return if there is an error, so we know that after that code the table is always != null. and we already do table.get() or table.getScanner() without checking for null. > Some small improvements on canary tool > -- > > Key: HBASE-13199 > URL: https://issues.apache.org/jira/browse/HBASE-13199 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Fix For: 2.0.0 > > Attachments: HBASE-13199-addendum.diff, HBASE-13199-v1.diff, > HBASE-13199-v2.diff, HBASE-13199-v3.diff, HBASE-13199-v4.diff > > > Improvements > - Make the sniff of region and regionserver parallel to support large cluster > with 1+ region and 500+ regionservers using thread pool. > - Set cacheblock to false in get and scan to avoid influence to block cache. > - Add FirstKeyOnlyFilter to get and scan to avoid read and translate too many > data from HBase. There may be many column under a column family in a > flat-wide table. > - Select the region randomly when sniffing a regionserver. > - Make the sink class of canary configurable > [~stack] > Suggestions are welcomed. Thanks~ > Another question is that why to check each column family with separate > requests when sniffing a region? Can we just check a column family of a > region? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13199) Some small improvements on canary tool
[ https://issues.apache.org/jira/browse/HBASE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Shaohui updated HBASE-13199: Attachment: HBASE-13199-addendum-v2.diff Remove the null check. [~mbertozzi] Please help to review the new addendum. Thanks~ > Some small improvements on canary tool > -- > > Key: HBASE-13199 > URL: https://issues.apache.org/jira/browse/HBASE-13199 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Fix For: 2.0.0 > > Attachments: HBASE-13199-addendum-v2.diff, HBASE-13199-addendum.diff, > HBASE-13199-v1.diff, HBASE-13199-v2.diff, HBASE-13199-v3.diff, > HBASE-13199-v4.diff > > > Improvements > - Make the sniff of region and regionserver parallel to support large cluster > with 1+ region and 500+ regionservers using thread pool. > - Set cacheblock to false in get and scan to avoid influence to block cache. > - Add FirstKeyOnlyFilter to get and scan to avoid read and translate too many > data from HBase. There may be many column under a column family in a > flat-wide table. > - Select the region randomly when sniffing a regionserver. > - Make the sink class of canary configurable > [~stack] > Suggestions are welcomed. Thanks~ > Another question is that why to check each column family with separate > requests when sniffing a region? Can we just check a column family of a > region? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13294) Fix the critical ancient loopholes in security testing infrastructure.
[
https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371142#comment-14371142
]
Matteo Bertozzi commented on HBASE-13294:
-
i really like the split,
in general when I write the tests I always assume that verifyDenied() requires
the ADE exception.
and for cases like the list names or similar the verifyIfEmptyList() seems to
be a nice helper.
if we are going with that, can we remove verifyDeniedWithException() and just
have the verifyDenied()?
should this code
{code}
Object obj = user.runAs(action);
if (requireException || obj == null) {
fail("Expected exception was not thrown for user '" + user.getShortName() +
"'");
}
if (obj != null && obj instanceof List) {
{code}
be instead
{code}
Object obj = user.runAs(action);
if (obj != null && obj instanceof List) {
...
} else if (requireException || obj == null) {
fail("Expected exception was not thrown for user '" + user.getShortName() +
"'");
}
{code}
or when someone returns a list we always have requireException = false?
what about requireException = false, obj != null but not a list? should we
throw something like "your test code is wrong"? otherwise that will silently
pass
> Fix the critical ancient loopholes in security testing infrastructure.
> --
>
> Key: HBASE-13294
> URL: https://issues.apache.org/jira/browse/HBASE-13294
> Project: HBase
> Issue Type: Bug
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
> Attachments: HBASE-13294.patch, HBASE-13294_v2.patch,
> HBASE-13294_v3.patch
>
>
> Unfortunately, the "verifyDenied" method doesn't fail when action parameter
> returns null. The relevant code snippet
> {code}
> try {
> Object obj = user.runAs(action);
> if (requireException) {
> fail("Expected exception was not thrown for user '" +
> user.getShortName() + "'");
> }
> if (obj != null && obj instanceof List) {
> List results = (List) obj;
> if (results != null && !results.isEmpty()) {
> fail("Unexpected results for user '" + user.getShortName() + "'");
> }
> }
> }
> {code}
> As you can see, when obj is null, it returns silently.
> Fixing this issue has uncovered another major bug. While constructing
> actions, we're using TEST_UTIL.getConnection(), which replaces the "doAs"
> user with the user who initiated the connection. I really am grateful to
> [~mbertozzi] without whom debugging this would have been a nightmare.
> Now, fixing these two issues have uncovered more issues in our tests :). The
> main one is we're allowing the table owner to truncate table in code. But, in
> test, we're not allowing him. We should either remove the code that allows
> owner or document that the table owner can truncate table.
> The other minor issues include granting permissions to namespace, but
> checking whether user was able to access tables inside other namespace.
> That's it, folks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13199) Some small improvements on canary tool
[ https://issues.apache.org/jira/browse/HBASE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371144#comment-14371144 ] Matteo Bertozzi commented on HBASE-13199: - [~liushaohui] +1 tried findbugs locally, with v2 that warn is gone. thanks! > Some small improvements on canary tool > -- > > Key: HBASE-13199 > URL: https://issues.apache.org/jira/browse/HBASE-13199 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Fix For: 2.0.0 > > Attachments: HBASE-13199-addendum-v2.diff, HBASE-13199-addendum.diff, > HBASE-13199-v1.diff, HBASE-13199-v2.diff, HBASE-13199-v3.diff, > HBASE-13199-v4.diff > > > Improvements > - Make the sniff of region and regionserver parallel to support large cluster > with 1+ region and 500+ regionservers using thread pool. > - Set cacheblock to false in get and scan to avoid influence to block cache. > - Add FirstKeyOnlyFilter to get and scan to avoid read and translate too many > data from HBase. There may be many column under a column family in a > flat-wide table. > - Select the region randomly when sniffing a regionserver. > - Make the sink class of canary configurable > [~stack] > Suggestions are welcomed. Thanks~ > Another question is that why to check each column family with separate > requests when sniffing a region? Can we just check a column family of a > region? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13294) Fix the critical ancient loopholes in security testing infrastructure.
[
https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371147#comment-14371147
]
Hadoop QA commented on HBASE-13294:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705876/HBASE-13294_v3.patch
against master branch at commit 0d766544166fc9630bb00ae14a4a34a69d93f127.
ATTACHMENT ID: 12705876
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 15 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13328//console
This message is automatically generated.
> Fix the critical ancient loopholes in security testing infrastructure.
> --
>
> Key: HBASE-13294
> URL: https://issues.apache.org/jira/browse/HBASE-13294
> Project: HBase
> Issue Type: Bug
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
> Attachments: HBASE-13294.patch, HBASE-13294_v2.patch,
> HBASE-13294_v3.patch
>
>
> Unfortunately, the "verifyDenied" method doesn't fail when action parameter
> returns null. The relevant code snippet
> {code}
> try {
> Object obj = user.runAs(action);
> if (requireException) {
> fail("Expected exception was not thrown for user '" +
> user.getShortName() + "'");
> }
> if (obj != null && obj instanceof List) {
> List results = (List) obj;
> if (results != null && !results.isEmpty()) {
> fail("Unexpected results for user '" + user.getShortName() + "'");
> }
> }
> }
> {code}
> As you can see, when obj is null, it returns silently.
> Fixing this issue has uncovered another major bug. While constructing
> actions, we're using TEST_UTIL.getConnection(), which replaces the "doAs"
> user wi
[jira] [Commented] (HBASE-13199) Some small improvements on canary tool
[ https://issues.apache.org/jira/browse/HBASE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371155#comment-14371155 ] Liu Shaohui commented on HBASE-13199: - [~mbertozzi] Thanks. Commit it tomorrow if no objection. > Some small improvements on canary tool > -- > > Key: HBASE-13199 > URL: https://issues.apache.org/jira/browse/HBASE-13199 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Fix For: 2.0.0 > > Attachments: HBASE-13199-addendum-v2.diff, HBASE-13199-addendum.diff, > HBASE-13199-v1.diff, HBASE-13199-v2.diff, HBASE-13199-v3.diff, > HBASE-13199-v4.diff > > > Improvements > - Make the sniff of region and regionserver parallel to support large cluster > with 1+ region and 500+ regionservers using thread pool. > - Set cacheblock to false in get and scan to avoid influence to block cache. > - Add FirstKeyOnlyFilter to get and scan to avoid read and translate too many > data from HBase. There may be many column under a column family in a > flat-wide table. > - Select the region randomly when sniffing a regionserver. > - Make the sink class of canary configurable > [~stack] > Suggestions are welcomed. Thanks~ > Another question is that why to check each column family with separate > requests when sniffing a region? Can we just check a column family of a > region? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13298) Clarify if Table.{set|get}WriteBufferSize() is deprecated or not
Lars George created HBASE-13298:
---
Summary: Clarify if Table.{set|get}WriteBufferSize() is deprecated
or not
Key: HBASE-13298
URL: https://issues.apache.org/jira/browse/HBASE-13298
Project: HBase
Issue Type: Bug
Components: API
Affects Versions: 1.0.0
Reporter: Lars George
For some reason {{Table.{set|get}WriteBufferSize()}} is _not_ deprecated in
{{Table}}, but it is in {{HTable}} and {{HTableInterface}}. We need to settle
on what the right thing is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13271) Table#puts(List) operation is indeterminate; needs fixing
[
https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars George updated HBASE-13271:
Assignee: (was: Lars George)
> Table#puts(List) operation is indeterminate; needs fixing
> --
>
> Key: HBASE-13271
> URL: https://issues.apache.org/jira/browse/HBASE-13271
> Project: HBase
> Issue Type: Improvement
> Components: API
>Affects Versions: 1.0.0
>Reporter: stack
> Fix For: 2.0.0, 1.0.1, 1.1.0
>
>
> Another API issue found by [~larsgeorge]:
> "Table.put(List {code}
> [Mar-17 9:21 AM] Lars George: Table.put(List) is weird since you cannot
> flush partial lists
> [Mar-17 9:21 AM] Lars George: Say out of 5 the third is broken, then the
> put() call returns with a local exception (say empty Put) and then you have 2
> that are in the buffer
> [Mar-17 9:21 AM] Lars George: but how to you force commit them?
> [Mar-17 9:22 AM] Lars George: In the past you would call flushCache(), but
> that is "gone" now
> [Mar-17 9:22 AM] Lars George: and flush() is not available on a Table
> [Mar-17 9:22 AM] Lars George: And you cannot access the underlying
> BufferedMutation neither
> [Mar-17 9:23 AM] Lars George: You can *only* add more Puts if you can, or
> call close()
> [Mar-17 9:23 AM] Lars George: that is just weird to explain
> {code}
> So, Table needs to get flush back or we deprecate this method or it flushes
> immediately and does not return until complete in the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13299) Add setReturnResults() to Increment, like Append has
Lars George created HBASE-13299:
---
Summary: Add setReturnResults() to Increment, like Append has
Key: HBASE-13299
URL: https://issues.apache.org/jira/browse/HBASE-13299
Project: HBase
Issue Type: Bug
Components: API
Affects Versions: 1.0.0
Reporter: Lars George
It seems like a good idea to keep Mutations similar, in that vein, the
{{{set|get}ReturnResults()}} method of Append seems like something Increment
could also benefit from, no?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13272) Get.setClosestRowBefore() breaks specific column Get
[ https://issues.apache.org/jira/browse/HBASE-13272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371234#comment-14371234 ] Nicolas Liochon commented on HBASE-13272: - The HTable#getRowOrBefore does a get#setClosestRowBefore(true); Yeah, I should have deprecated both. I think setClosestRowBefore is really old, but may be I'm wrong. >From the code - It seems it's not used in HBase now - I have not found a test as well. - it seems it does not work if you're hitting a region boundary (i.e. the closest_row_before is in another region). - It's limited to single family as well (RSRpcServices.java) "get ClosestRowBefore supports one and only one family now, not " + get.getColumnCount() + " families"); I think this can be replaced by the reverseScanner, hopefully reverseScanner covers more usages. My guess is that it leaked getRowOrBefore was purely internal and got deprecated in 0.92: * @deprecated As of version 0.92 this method is deprecated without * replacement. Since version 0.96+, you can use reversed scan. * getRowOrBefore is used internally to find entries in hbase:meta and makes * various assumptions about the table (which are true for hbase:meta but not * in general) to be efficient. My guess is that Get#setClosestRowBefore was there only for the meta table and has been forgotten on the deprecation path. Now I'm not against a fix, we're open source :-) and anyway we can't remove the feature in less than two hbase releases. But from the client code point of view using the reverse scanner seems safer. imho setClosestRowBefore should be deprecated as soon as possible: very ad-hoc, not used in the internal code, not tested, fails on cross boundaries calls, fails on multiple families, and this jira as a bounty: these are good reasons imho. > Get.setClosestRowBefore() breaks specific column Get > > > Key: HBASE-13272 > URL: https://issues.apache.org/jira/browse/HBASE-13272 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Trivial > > Via [~larsgeorge] > Get.setClosestRowBefore() is breaking a specific Get that specifies a column. > If you set the latter to "true" it will return the _entire_ row! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13300) Fix casing in getTimeStamp() and setTimestamp() for Mutations
Lars George created HBASE-13300: --- Summary: Fix casing in getTimeStamp() and setTimestamp() for Mutations Key: HBASE-13300 URL: https://issues.apache.org/jira/browse/HBASE-13300 Project: HBase Issue Type: Bug Components: API Affects Versions: 1.0.0 Reporter: Lars George For some reason we have two ways of writing this method. It should be consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12867) Shell does not support custom replication endpoint specification
[
https://issues.apache.org/jira/browse/HBASE-12867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated HBASE-12867:
-
Assignee: (was: Kevin Risden)
> Shell does not support custom replication endpoint specification
>
>
> Key: HBASE-12867
> URL: https://issues.apache.org/jira/browse/HBASE-12867
> Project: HBase
> Issue Type: Bug
>Reporter: Andrew Purtell
> Labels: beginner, beginners
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-12867-v1.patch, HBASE-12867-v2.patch,
> HBASE-12867-v3.patch, HBASE-12867-v3.patch, HBASE-12867-v3.patch,
> HBASE-12867.patch
>
>
> On HBASE-12254 and also at
> https://github.com/risdenk/hbase-custom-replication-endpoint-example
> [~risdenk] made the following observations and suggestions regarding custom
> replication endpoints that I think are a reasonable blueprint for improvement:
> {quote}
> I was trying out the pluggable replication endpoint feature and found the
> following:
> - you must use the ReplicationAdmin to add the new ReplicationEndpoint
> - hbase shell add_peer command doesn't support specifying a custom class
> - hbase shell add_peer relies on the newly deprecated ReplicationAdmin
> addPeer methods
> - ReplicationAdmin addPeer tableCfs is now a Map Collection> instead of a string
> {quote}
> We should fix the add_peer command in the shell at least.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (HBASE-12867) Shell does not support custom replication endpoint specification
[
https://issues.apache.org/jira/browse/HBASE-12867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden reopened HBASE-12867:
--
This was reverted due to some test failures so hasn't been resolved.
> Shell does not support custom replication endpoint specification
>
>
> Key: HBASE-12867
> URL: https://issues.apache.org/jira/browse/HBASE-12867
> Project: HBase
> Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Kevin Risden
> Labels: beginner, beginners
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-12867-v1.patch, HBASE-12867-v2.patch,
> HBASE-12867-v3.patch, HBASE-12867-v3.patch, HBASE-12867-v3.patch,
> HBASE-12867.patch
>
>
> On HBASE-12254 and also at
> https://github.com/risdenk/hbase-custom-replication-endpoint-example
> [~risdenk] made the following observations and suggestions regarding custom
> replication endpoints that I think are a reasonable blueprint for improvement:
> {quote}
> I was trying out the pluggable replication endpoint feature and found the
> following:
> - you must use the ReplicationAdmin to add the new ReplicationEndpoint
> - hbase shell add_peer command doesn't support specifying a custom class
> - hbase shell add_peer relies on the newly deprecated ReplicationAdmin
> addPeer methods
> - ReplicationAdmin addPeer tableCfs is now a Map Collection> instead of a string
> {quote}
> We should fix the add_peer command in the shell at least.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12940) Expose listPeerConfigs and getPeerConfig to the HBase shell
[ https://issues.apache.org/jira/browse/HBASE-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated HBASE-12940: - Assignee: (was: Kevin Risden) > Expose listPeerConfigs and getPeerConfig to the HBase shell > --- > > Key: HBASE-12940 > URL: https://issues.apache.org/jira/browse/HBASE-12940 > Project: HBase > Issue Type: Bug > Components: shell >Reporter: Kevin Risden > > In HBASE-12867 found that listPeerConfigs and getPeerConfig from > ReplicationAdmin are not exposed to the HBase shell. This makes looking at > details for custom replication endpoints and testing of add_peer from > HBASE-12867 impossible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13275) Setting hbase.security.authorization to false does not disable authorization when AccessController is in the coprocessor class list
[
https://issues.apache.org/jira/browse/HBASE-13275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371284#comment-14371284
]
William Watson commented on HBASE-13275:
Should we make a new ticket for Ambari or will they update their docs when the
hbase docs are updated?
> Setting hbase.security.authorization to false does not disable authorization
> when AccessController is in the coprocessor class list
> ---
>
> Key: HBASE-13275
> URL: https://issues.apache.org/jira/browse/HBASE-13275
> Project: HBase
> Issue Type: Bug
>Reporter: William Watson
>Assignee: Andrew Purtell
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
>
>
> According to the docs provided by Cloudera (we're not running Cloudera, BTW),
> this is the list of configs to enable authorization in HBase:
> {code}
>
> hbase.security.authorization
> true
>
>
> hbase.coprocessor.master.classes
> org.apache.hadoop.hbase.security.access.AccessController
>
>
> hbase.coprocessor.region.classes
>
> org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.AccessController
>
> {code}
> We wanted to then disable authorization but simply setting
> hbase.security.authorization to false did not disable the authorization
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13006) Document visibility label support for groups
[ https://issues.apache.org/jira/browse/HBASE-13006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371321#comment-14371321 ] Hudson commented on HBASE-13006: SUCCESS: Integrated in HBase-0.98 #913 (See [https://builds.apache.org/job/HBase-0.98/913/]) HBASE-13006 Document visibility label support for groups. (Jerry He) (anoopsamjohn: rev 3566e7e9bf0b3fe6cd1ab9b01d42bc1136dd51f0) * hbase-shell/src/main/ruby/shell/commands/clear_auths.rb * hbase-shell/src/main/ruby/shell/commands/set_auths.rb * hbase-shell/src/main/ruby/shell/commands/get_auths.rb > Document visibility label support for groups > > > Key: HBASE-13006 > URL: https://issues.apache.org/jira/browse/HBASE-13006 > Project: HBase > Issue Type: Sub-task >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13006-v2.patch, HBASE-13006-v3.patch, > HBASE-13006.patch, shell-update-only.patch > > > This is to document the changes added from HBASE-12745. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13301) Possible memory leak in BucketCache
zhangduo created HBASE-13301:
Summary: Possible memory leak in BucketCache
Key: HBASE-13301
URL: https://issues.apache.org/jira/browse/HBASE-13301
Project: HBase
Issue Type: Bug
Components: BlockCache
Reporter: zhangduo
Assignee: zhangduo
{code:title=BucketCache.java}
public boolean evictBlock(BlockCacheKey cacheKey) {
...
if (bucketEntry.equals(backingMap.remove(cacheKey))) {
bucketAllocator.freeBlock(bucketEntry.offset());
realCacheSize.addAndGet(-1 * bucketEntry.getLength());
blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
if (removedBlock == null) {
this.blockNumber.decrementAndGet();
}
} else {
return false;
}
...
{code}
I think the problem is here. We remove a BucketEntry that should not remove by
us, but we do not put it back and also do not do any clean up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13301) Possible memory leak in BucketCache
[
https://issues.apache.org/jira/browse/HBASE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhangduo updated HBASE-13301:
-
Description:
{code:title=BucketCache.java}
public boolean evictBlock(BlockCacheKey cacheKey) {
...
if (bucketEntry.equals(backingMap.remove(cacheKey))) {
bucketAllocator.freeBlock(bucketEntry.offset());
realCacheSize.addAndGet(-1 * bucketEntry.getLength());
blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
if (removedBlock == null) {
this.blockNumber.decrementAndGet();
}
} else {
return false;
}
...
{code}
I think the problem is here. We remove a BucketEntry that should not be removed
by us, but we do not put it back and also do not do any clean up.
was:
{code:title=BucketCache.java}
public boolean evictBlock(BlockCacheKey cacheKey) {
...
if (bucketEntry.equals(backingMap.remove(cacheKey))) {
bucketAllocator.freeBlock(bucketEntry.offset());
realCacheSize.addAndGet(-1 * bucketEntry.getLength());
blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
if (removedBlock == null) {
this.blockNumber.decrementAndGet();
}
} else {
return false;
}
...
{code}
I think the problem is here. We remove a BucketEntry that should not remove by
us, but we do not put it back and also do not do any clean up.
> Possible memory leak in BucketCache
> ---
>
> Key: HBASE-13301
> URL: https://issues.apache.org/jira/browse/HBASE-13301
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
>Reporter: zhangduo
>Assignee: zhangduo
>
> {code:title=BucketCache.java}
> public boolean evictBlock(BlockCacheKey cacheKey) {
> ...
> if (bucketEntry.equals(backingMap.remove(cacheKey))) {
> bucketAllocator.freeBlock(bucketEntry.offset());
> realCacheSize.addAndGet(-1 * bucketEntry.getLength());
> blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
> if (removedBlock == null) {
> this.blockNumber.decrementAndGet();
> }
> } else {
> return false;
> }
> ...
> {code}
> I think the problem is here. We remove a BucketEntry that should not be
> removed by us, but we do not put it back and also do not do any clean up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13301) Possible memory leak in BucketCache
[
https://issues.apache.org/jira/browse/HBASE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhangduo updated HBASE-13301:
-
Attachment: HBASE-13301-testcase.patch
Only a testcase.
A little tricky so I really need other ones help confirming the problem.
The flow is:
t1 cache a block
t2 evict the block but stopped before acquiring offsetLock(this is done by
holding the offsetLock with t1 in this testcase)
t1 evict the block, and cache the block again.
t2 continue evicting the block and find that it is not the block which it
should deal with, so just give up and return false.
Then we have blockCount=1, and some used spaces in BucketAllocator, but no
block in BucketCache. So we have no chance to free the used spaces.
> Possible memory leak in BucketCache
> ---
>
> Key: HBASE-13301
> URL: https://issues.apache.org/jira/browse/HBASE-13301
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
>Reporter: zhangduo
>Assignee: zhangduo
> Attachments: HBASE-13301-testcase.patch
>
>
> {code:title=BucketCache.java}
> public boolean evictBlock(BlockCacheKey cacheKey) {
> ...
> if (bucketEntry.equals(backingMap.remove(cacheKey))) {
> bucketAllocator.freeBlock(bucketEntry.offset());
> realCacheSize.addAndGet(-1 * bucketEntry.getLength());
> blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
> if (removedBlock == null) {
> this.blockNumber.decrementAndGet();
> }
> } else {
> return false;
> }
> ...
> {code}
> I think the problem is here. We remove a BucketEntry that should not be
> removed by us, but we do not put it back and also do not do any clean up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13301) Possible memory leak in BucketCache
[
https://issues.apache.org/jira/browse/HBASE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371352#comment-14371352
]
zhangduo commented on HBASE-13301:
--
Do not submit the patch since it is not a fix.
Experts needed. [~stack] (I do not know who is the right person since
[~zjushch] seems not active for a long time, so...)
> Possible memory leak in BucketCache
> ---
>
> Key: HBASE-13301
> URL: https://issues.apache.org/jira/browse/HBASE-13301
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
>Reporter: zhangduo
>Assignee: zhangduo
> Attachments: HBASE-13301-testcase.patch
>
>
> {code:title=BucketCache.java}
> public boolean evictBlock(BlockCacheKey cacheKey) {
> ...
> if (bucketEntry.equals(backingMap.remove(cacheKey))) {
> bucketAllocator.freeBlock(bucketEntry.offset());
> realCacheSize.addAndGet(-1 * bucketEntry.getLength());
> blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
> if (removedBlock == null) {
> this.blockNumber.decrementAndGet();
> }
> } else {
> return false;
> }
> ...
> {code}
> I think the problem is here. We remove a BucketEntry that should not be
> removed by us, but we do not put it back and also do not do any clean up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13006) Document visibility label support for groups
[ https://issues.apache.org/jira/browse/HBASE-13006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371438#comment-14371438 ] Hudson commented on HBASE-13006: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #867 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/867/]) HBASE-13006 Document visibility label support for groups. (Jerry He) (anoopsamjohn: rev 3566e7e9bf0b3fe6cd1ab9b01d42bc1136dd51f0) * hbase-shell/src/main/ruby/shell/commands/set_auths.rb * hbase-shell/src/main/ruby/shell/commands/clear_auths.rb * hbase-shell/src/main/ruby/shell/commands/get_auths.rb > Document visibility label support for groups > > > Key: HBASE-13006 > URL: https://issues.apache.org/jira/browse/HBASE-13006 > Project: HBase > Issue Type: Sub-task >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13006-v2.patch, HBASE-13006-v3.patch, > HBASE-13006.patch, shell-update-only.patch > > > This is to document the changes added from HBASE-12745. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13299) Add setReturnResults() to Increment, like Append has
[
https://issues.apache.org/jira/browse/HBASE-13299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13299:
--
Priority: Critical (was: Major)
> Add setReturnResults() to Increment, like Append has
>
>
> Key: HBASE-13299
> URL: https://issues.apache.org/jira/browse/HBASE-13299
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
>
> It seems like a good idea to keep Mutations similar, in that vein, the
> {{{set|get}ReturnResults()}} method of Append seems like something Increment
> could also benefit from, no?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13299) Add setReturnResults() to Increment, like Append has
[
https://issues.apache.org/jira/browse/HBASE-13299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13299:
--
Fix Version/s: 1.0.1
> Add setReturnResults() to Increment, like Append has
>
>
> Key: HBASE-13299
> URL: https://issues.apache.org/jira/browse/HBASE-13299
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 1.0.1
>
>
> It seems like a good idea to keep Mutations similar, in that vein, the
> {{{set|get}ReturnResults()}} method of Append seems like something Increment
> could also benefit from, no?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13299) Add setReturnResults() to Increment, like Append has
[
https://issues.apache.org/jira/browse/HBASE-13299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371441#comment-14371441
]
stack commented on HBASE-13299:
---
Setting as fix for 1.0.1 critical. Seems important having a regular API.
> Add setReturnResults() to Increment, like Append has
>
>
> Key: HBASE-13299
> URL: https://issues.apache.org/jira/browse/HBASE-13299
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 1.0.1
>
>
> It seems like a good idea to keep Mutations similar, in that vein, the
> {{{set|get}ReturnResults()}} method of Append seems like something Increment
> could also benefit from, no?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13298) Clarify if Table.{set|get}WriteBufferSize() is deprecated or not
[
https://issues.apache.org/jira/browse/HBASE-13298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13298:
--
Fix Version/s: 1.0.1
> Clarify if Table.{set|get}WriteBufferSize() is deprecated or not
>
>
> Key: HBASE-13298
> URL: https://issues.apache.org/jira/browse/HBASE-13298
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 1.0.1
>
>
> For some reason {{Table.{set|get}WriteBufferSize()}} is _not_ deprecated in
> {{Table}}, but it is in {{HTable}} and {{HTableInterface}}. We need to settle
> on what the right thing is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13298) Clarify if Table.{set|get}WriteBufferSize() is deprecated or not
[
https://issues.apache.org/jira/browse/HBASE-13298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13298:
--
Priority: Critical (was: Major)
> Clarify if Table.{set|get}WriteBufferSize() is deprecated or not
>
>
> Key: HBASE-13298
> URL: https://issues.apache.org/jira/browse/HBASE-13298
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 1.0.1
>
>
> For some reason {{Table.{set|get}WriteBufferSize()}} is _not_ deprecated in
> {{Table}}, but it is in {{HTable}} and {{HTableInterface}}. We need to settle
> on what the right thing is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13298) Clarify if Table.{set|get}WriteBufferSize() is deprecated or not
[
https://issues.apache.org/jira/browse/HBASE-13298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371442#comment-14371442
]
stack commented on HBASE-13298:
---
Setting critical for 1.0.1. API clarification.
> Clarify if Table.{set|get}WriteBufferSize() is deprecated or not
>
>
> Key: HBASE-13298
> URL: https://issues.apache.org/jira/browse/HBASE-13298
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 1.0.1
>
>
> For some reason {{Table.{set|get}WriteBufferSize()}} is _not_ deprecated in
> {{Table}}, but it is in {{HTable}} and {{HTableInterface}}. We need to settle
> on what the right thing is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13297) 0.98 and 1.0: Remove client side result size calculation
[
https://issues.apache.org/jira/browse/HBASE-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371447#comment-14371447
]
Lars Hofhansl commented on HBASE-13297:
---
[~anoop.hbase] very true. So is there any alternative? I don't like having an
extra RPC for every region as this patch does.
Also ran the test suite over night; fails here:
{noformat}
Failed tests:
TestRegionServerMetrics.testRequestCount:163 Metrics Counters should be equal
expected:<111> but was:<112>
{noformat}
Will fix later.
> 0.98 and 1.0: Remove client side result size calculation
>
>
> Key: HBASE-13297
> URL: https://issues.apache.org/jira/browse/HBASE-13297
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 1.0.1, 0.98.13
>
> Attachments: 13297-0.98.txt
>
>
> As described in parent, this can lead to missed rows when the client and
> server calculate different size values.
> The patch here proposes a backwards compatible patch for 0.98 and 1.0.x.
> Parent will do a patch for 1.1 and 2.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13297) 0.98 and 1.0: Remove client side result size calculation
[ https://issues.apache.org/jira/browse/HBASE-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371489#comment-14371489 ] Andrew Purtell commented on HBASE-13297: On the parent the current idea of a better fix is a backport of the NextState stuff Correctness over performance until is the right choice, yes? > 0.98 and 1.0: Remove client side result size calculation > > > Key: HBASE-13297 > URL: https://issues.apache.org/jira/browse/HBASE-13297 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 1.0.1, 0.98.13 > > Attachments: 13297-0.98.txt > > > As described in parent, this can lead to missed rows when the client and > server calculate different size values. > The patch here proposes a backwards compatible patch for 0.98 and 1.0.x. > Parent will do a patch for 1.1 and 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13299) Add setReturnResults() to Increment, like Append has
[
https://issues.apache.org/jira/browse/HBASE-13299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi updated HBASE-13299:
--
Attachment: HBASE-13299.patch
> Add setReturnResults() to Increment, like Append has
>
>
> Key: HBASE-13299
> URL: https://issues.apache.org/jira/browse/HBASE-13299
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 1.0.1
>
> Attachments: HBASE-13299.patch
>
>
> It seems like a good idea to keep Mutations similar, in that vein, the
> {{{set|get}ReturnResults()}} method of Append seems like something Increment
> could also benefit from, no?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13299) Add setReturnResults() to Increment, like Append has
[
https://issues.apache.org/jira/browse/HBASE-13299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi updated HBASE-13299:
--
Status: Patch Available (was: Open)
> Add setReturnResults() to Increment, like Append has
>
>
> Key: HBASE-13299
> URL: https://issues.apache.org/jira/browse/HBASE-13299
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 1.0.1
>
> Attachments: HBASE-13299.patch
>
>
> It seems like a good idea to keep Mutations similar, in that vein, the
> {{{set|get}ReturnResults()}} method of Append seems like something Increment
> could also benefit from, no?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13277) add mob_threshold option to load test tool
[ https://issues.apache.org/jira/browse/HBASE-13277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-13277: --- Attachment: hbase-13277.v2-hbase-11339.patch v2 rewords the message (still using "desired" since the other options do this as well), and change > to >= wrt to mobThreshold. The javadoc errors will be addressed in another patch. (hooray for qabot) > add mob_threshold option to load test tool > -- > > Key: HBASE-13277 > URL: https://issues.apache.org/jira/browse/HBASE-13277 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Affects Versions: hbase-11339 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: hbase-11339 > > Attachments: HBASE-13277.hbase-11339.patch, > hbase-13277.v2-hbase-11339.patch > > > This adds '-mob_threshold ' option to the load test tool to simplify > mob load testing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13277) add mob_threshold option to load test tool
[ https://issues.apache.org/jira/browse/HBASE-13277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371584#comment-14371584 ] Sean Busbey commented on HBASE-13277: - +1 pending javadoc errors. > add mob_threshold option to load test tool > -- > > Key: HBASE-13277 > URL: https://issues.apache.org/jira/browse/HBASE-13277 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Affects Versions: hbase-11339 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Fix For: hbase-11339 > > Attachments: HBASE-13277.hbase-11339.patch, > hbase-13277.v2-hbase-11339.patch > > > This adds '-mob_threshold ' option to the load test tool to simplify > mob load testing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13302) fix new javadoc warns introduced by mob.
Jonathan Hsieh created HBASE-13302:
--
Summary: fix new javadoc warns introduced by mob.
Key: HBASE-13302
URL: https://issues.apache.org/jira/browse/HBASE-13302
Project: HBase
Issue Type: Sub-task
Affects Versions: hbase-11339
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Fix For: hbase-11339
now that we have the qabot able to work on branches, we've detected a few
javadoc issues. this will fix it.
{code}
[WARNING] Javadoc Warnings
[WARNING]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
warning - @param argument "path" is not a parameter name.
[WARNING]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
warning - @param argument "@param" is not a parameter name.
[WARNING]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
warning - @param argument "path" is not a parameter name.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13198) Remove HConnectionManager
[ https://issues.apache.org/jira/browse/HBASE-13198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-13198: -- Resolution: Fixed Fix Version/s: 2.0.0 Hadoop Flags: Incompatible change,Reviewed Status: Resolved (was: Patch Available) Pushed to master. Thanks for the patch [~mantonov] > Remove HConnectionManager > - > > Key: HBASE-13198 > URL: https://issues.apache.org/jira/browse/HBASE-13198 > Project: HBase > Issue Type: Sub-task > Components: API >Affects Versions: 2.0.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0 > > Attachments: HBASE-13198.patch, HBASE-13198.patch, HBASE-13198.patch, > HBASE-13198.patch > > > This one is marked as deprecated (i.e. to be removed?) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13274) Fix misplaced deprecation in Delete#addXYZ
[
https://issues.apache.org/jira/browse/HBASE-13274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13274:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to branch-1.0+ Thanks for the patch [~mantonov]
> Fix misplaced deprecation in Delete#addXYZ
> --
>
> Key: HBASE-13274
> URL: https://issues.apache.org/jira/browse/HBASE-13274
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0, 2.0.0
>Reporter: stack
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.0.1, 1.1.0
>
> Attachments: HBASE-13274.patch
>
>
> Found by [~larsgeorge]
> {code}
> All deleteXYZ() were deprecated in Delete in favour of the matching addXYZ()
> (to mirror Put, Get, etc.) - _but_ for deleteFamilyVersion(). What is worse
> is, the @deprecated for it was added to the addFamilyVersion() replacement!
> Oh man.
> * @deprecated Since hbase-1.0.0. Use {@link #addFamilyVersion(byte[], long)}
> */
@Deprecated
public Delete addFamilyVersion(final byte [] family,
> final long timestamp) {
> The deprecated message is right, but on the wrong method
> (areyoukiddingme)
> Well, I presume it was done right, and will steer clear of deleteXYZ() in
> favor of addXYZ()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13302) fix new javadoc warns introduced by mob.
[
https://issues.apache.org/jira/browse/HBASE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-13302:
---
Attachment: hbase-13302.hbase-11339.patch
> fix new javadoc warns introduced by mob.
> -
>
> Key: HBASE-13302
> URL: https://issues.apache.org/jira/browse/HBASE-13302
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Affects Versions: hbase-11339
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: hbase-11339
>
> Attachments: hbase-13302.hbase-11339.patch
>
>
> now that we have the qabot able to work on branches, we've detected a few
> javadoc issues. this will fix it.
> {code}
> [WARNING] Javadoc Warnings
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
> warning - @param argument "path" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "@param" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "path" is not a parameter name.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[
https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371605#comment-14371605
]
Sean Busbey commented on HBASE-13273:
-
Can someone tell me why TestResult is in hbase-server?
{quote}
-1 findbugs. The patch appears to introduce 1 new Findbugs (version 2.0.3)
warnings.
{quote}
I'm not seeing what in hbase-client generated a new warning. I'll chase it down
in a bit.
{code}
+ private void checkReadonly() {
+if (this.readonly == true) {
+ throw new UnsupportedOperationException("Attempting to modify readonly
EMPTY_RESULT!");
+}
+ }
{code}
Please add a javadoc about how all methods that mutate state in a result *must*
call this method.
{code}
+ private void checkReadonly() {
+if (this.readonly == true) {
+ throw new UnsupportedOperationException("Attempting to modify readonly
EMPTY_RESULT!");
+}
+ }
{code}
just use {{if(readonly)}} directly.
> Make Result.EMPTY_RESULT read-only; currently it can be modified
>
>
> Key: HBASE-13273
> URL: https://issues.apache.org/jira/browse/HBASE-13273
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 1.0.0
>Reporter: stack
>Assignee: Mikhail Antonov
> Labels: beginner
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
>
> Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch,
> HBASE-13273.patch
>
>
> Again from [~larsgeorge]
> Result result2 = Result.EMPTY_RESULT;
> System.out.println(result2);
> result2.copyFrom(result1);
> System.out.println(result2);
> "What do you think happens when result1 has cells? Yep, you just modified the
> shared public EMPTY_RESULT to be not empty anymore."
> Fix. Result should be non-modifiable post-construction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13302) fix new javadoc warns introduced by mob.
[
https://issues.apache.org/jira/browse/HBASE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-13302:
---
Status: Patch Available (was: Open)
> fix new javadoc warns introduced by mob.
> -
>
> Key: HBASE-13302
> URL: https://issues.apache.org/jira/browse/HBASE-13302
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Affects Versions: hbase-11339
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: hbase-11339
>
> Attachments: hbase-13302.hbase-11339.patch
>
>
> now that we have the qabot able to work on branches, we've detected a few
> javadoc issues. this will fix it.
> {code}
> [WARNING] Javadoc Warnings
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
> warning - @param argument "path" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "@param" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "path" is not a parameter name.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13297) 0.98 and 1.0: Remove client side result size calculation
[ https://issues.apache.org/jira/browse/HBASE-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371618#comment-14371618 ] Lars Hofhansl commented on HBASE-13297: --- bq. On the parent the current idea of a better fix is a backport of the NextState stuff Can we do that without breaking wire compatibility? (will check parent now) If we can (pb to the rescue for once?), and since in either case the _client_ would need to be updated, we might not need this patch here. > 0.98 and 1.0: Remove client side result size calculation > > > Key: HBASE-13297 > URL: https://issues.apache.org/jira/browse/HBASE-13297 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 1.0.1, 0.98.13 > > Attachments: 13297-0.98.txt > > > As described in parent, this can lead to missed rows when the client and > server calculate different size values. > The patch here proposes a backwards compatible patch for 0.98 and 1.0.x. > Parent will do a patch for 1.1 and 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13294) Fix the critical ancient loopholes in security testing infrastructure.
[
https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371621#comment-14371621
]
Andrew Purtell commented on HBASE-13294:
{quote}
The semantics for verify methods are as follows.
- verifyAllowed -> passes only in case of null or non-empty list
- verifyDenied -> passes only in case of ADE.
- verifyIfNull -> passes in case of null or ADE.
- verifyIfEmptyList -> passes in case of emtpy list or ADE.
{quote}
Yes this will make things clearer I think.
> Fix the critical ancient loopholes in security testing infrastructure.
> --
>
> Key: HBASE-13294
> URL: https://issues.apache.org/jira/browse/HBASE-13294
> Project: HBase
> Issue Type: Bug
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
> Attachments: HBASE-13294.patch, HBASE-13294_v2.patch,
> HBASE-13294_v3.patch
>
>
> Unfortunately, the "verifyDenied" method doesn't fail when action parameter
> returns null. The relevant code snippet
> {code}
> try {
> Object obj = user.runAs(action);
> if (requireException) {
> fail("Expected exception was not thrown for user '" +
> user.getShortName() + "'");
> }
> if (obj != null && obj instanceof List) {
> List results = (List) obj;
> if (results != null && !results.isEmpty()) {
> fail("Unexpected results for user '" + user.getShortName() + "'");
> }
> }
> }
> {code}
> As you can see, when obj is null, it returns silently.
> Fixing this issue has uncovered another major bug. While constructing
> actions, we're using TEST_UTIL.getConnection(), which replaces the "doAs"
> user with the user who initiated the connection. I really am grateful to
> [~mbertozzi] without whom debugging this would have been a nightmare.
> Now, fixing these two issues have uncovered more issues in our tests :). The
> main one is we're allowing the table owner to truncate table in code. But, in
> test, we're not allowing him. We should either remove the code that allows
> owner or document that the table owner can truncate table.
> The other minor issues include granting permissions to namespace, but
> checking whether user was able to access tables inside other namespace.
> That's it, folks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[
https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371623#comment-14371623
]
Ashish Singhi commented on HBASE-13273:
---
{quote}
bq. -1 findbugs. The patch appears to introduce 1 new Findbugs (version 2.0.3)
warnings.
I'm not seeing what in hbase-client generated a new warning. I'll chase it down
in a bit.
{quote}
This is not related to this patch. It is from HBASE-13199
> Make Result.EMPTY_RESULT read-only; currently it can be modified
>
>
> Key: HBASE-13273
> URL: https://issues.apache.org/jira/browse/HBASE-13273
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 1.0.0
>Reporter: stack
>Assignee: Mikhail Antonov
> Labels: beginner
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
>
> Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch,
> HBASE-13273.patch
>
>
> Again from [~larsgeorge]
> Result result2 = Result.EMPTY_RESULT;
> System.out.println(result2);
> result2.copyFrom(result1);
> System.out.println(result2);
> "What do you think happens when result1 has cells? Yep, you just modified the
> shared public EMPTY_RESULT to be not empty anymore."
> Fix. Result should be non-modifiable post-construction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13281) 'hbase.bucketcache.size' description in hbase book is not correct
[ https://issues.apache.org/jira/browse/HBASE-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371630#comment-14371630 ] ramkrishna.s.vasudevan commented on HBASE-13281: Will commit this unless objection. > 'hbase.bucketcache.size' description in hbase book is not correct > - > > Key: HBASE-13281 > URL: https://issues.apache.org/jira/browse/HBASE-13281 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0, 1.1.0 > > Attachments: HBASE-13281.patch > > > The description about 'hbase.bucketcache.size' is not correct. We either > specify it as a float or in MB's and the default value that is mentioned is > never used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[
https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371644#comment-14371644
]
Sean Busbey commented on HBASE-13273:
-
As a nit, please follow the guidelines for [submitting
patches|http://hbase.apache.org/book.html#submitting.patches]. Specifically,
please use {{git format-patch}} with a good commit message and version your
patches.
> Make Result.EMPTY_RESULT read-only; currently it can be modified
>
>
> Key: HBASE-13273
> URL: https://issues.apache.org/jira/browse/HBASE-13273
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 1.0.0
>Reporter: stack
>Assignee: Mikhail Antonov
> Labels: beginner
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
>
> Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch,
> HBASE-13273.patch
>
>
> Again from [~larsgeorge]
> Result result2 = Result.EMPTY_RESULT;
> System.out.println(result2);
> result2.copyFrom(result1);
> System.out.println(result2);
> "What do you think happens when result1 has cells? Yep, you just modified the
> shared public EMPTY_RESULT to be not empty anymore."
> Fix. Result should be non-modifiable post-construction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13302) fix new javadoc warns introduced by mob.
[
https://issues.apache.org/jira/browse/HBASE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371643#comment-14371643
]
Ashish Singhi commented on HBASE-13302:
---
Not related to patch, but since you are there.
{code}
* @return True if the file name has format of a del file.
{code}
I feel it is better to avoid short forms in the java doc for better clarity.
Can we expand what 'del' means ?
May be you can fix it while committing if you think so.
> fix new javadoc warns introduced by mob.
> -
>
> Key: HBASE-13302
> URL: https://issues.apache.org/jira/browse/HBASE-13302
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Affects Versions: hbase-11339
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: hbase-11339
>
> Attachments: hbase-13302.hbase-11339.patch
>
>
> now that we have the qabot able to work on branches, we've detected a few
> javadoc issues. this will fix it.
> {code}
> [WARNING] Javadoc Warnings
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
> warning - @param argument "path" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "@param" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "path" is not a parameter name.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (HBASE-13199) Some small improvements on canary tool
[ https://issues.apache.org/jira/browse/HBASE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reopened HBASE-13199: - Reopening issue until addendum is pushed. > Some small improvements on canary tool > -- > > Key: HBASE-13199 > URL: https://issues.apache.org/jira/browse/HBASE-13199 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Fix For: 2.0.0 > > Attachments: HBASE-13199-addendum-v2.diff, HBASE-13199-addendum.diff, > HBASE-13199-v1.diff, HBASE-13199-v2.diff, HBASE-13199-v3.diff, > HBASE-13199-v4.diff > > > Improvements > - Make the sniff of region and regionserver parallel to support large cluster > with 1+ region and 500+ regionservers using thread pool. > - Set cacheblock to false in get and scan to avoid influence to block cache. > - Add FirstKeyOnlyFilter to get and scan to avoid read and translate too many > data from HBase. There may be many column under a column family in a > flat-wide table. > - Select the region randomly when sniffing a regionserver. > - Make the sink class of canary configurable > [~stack] > Suggestions are welcomed. Thanks~ > Another question is that why to check each column family with separate > requests when sniffing a region? Can we just check a column family of a > region? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13201) Remove HTablePool from thrift-server
[ https://issues.apache.org/jira/browse/HBASE-13201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371657#comment-14371657 ] Solomon Duskis commented on HBASE-13201: [~ndimiduk] What say you about getting this into branch-1? > Remove HTablePool from thrift-server > > > Key: HBASE-13201 > URL: https://issues.apache.org/jira/browse/HBASE-13201 > Project: HBase > Issue Type: Sub-task >Reporter: Solomon Duskis >Assignee: Solomon Duskis > Fix For: 2.0.0 > > Attachments: HBASE-13201-1-branch-1.patch, HBASE-13201-1.patch, > HBASE-13201.patch > > > HTablePool is an old concept that was superseded by Connection. > thrift-server doesn't need HTablePool anymore and can use the ConnectionCache > directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13199) Some small improvements on canary tool
[ https://issues.apache.org/jira/browse/HBASE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-13199: Status: Patch Available (was: Reopened) > Some small improvements on canary tool > -- > > Key: HBASE-13199 > URL: https://issues.apache.org/jira/browse/HBASE-13199 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Fix For: 2.0.0 > > Attachments: HBASE-13199-addendum-v2.diff, HBASE-13199-addendum.diff, > HBASE-13199-v1.diff, HBASE-13199-v2.diff, HBASE-13199-v3.diff, > HBASE-13199-v4.diff > > > Improvements > - Make the sniff of region and regionserver parallel to support large cluster > with 1+ region and 500+ regionservers using thread pool. > - Set cacheblock to false in get and scan to avoid influence to block cache. > - Add FirstKeyOnlyFilter to get and scan to avoid read and translate too many > data from HBase. There may be many column under a column family in a > flat-wide table. > - Select the region randomly when sniffing a regionserver. > - Make the sink class of canary configurable > [~stack] > Suggestions are welcomed. Thanks~ > Another question is that why to check each column family with separate > requests when sniffing a region? Can we just check a column family of a > region? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13302) fix new javadoc warns introduced by mob.
[
https://issues.apache.org/jira/browse/HBASE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371665#comment-14371665
]
Jonathan Hsieh commented on HBASE-13302:
Thanks for the note. We save the deletions in the main write path so that mob
compactions can used them to clean up the mob hfiles. The can be called
"delete-tracking hfiles" but we've bee calling them "del files" in our design
docs and code.
> fix new javadoc warns introduced by mob.
> -
>
> Key: HBASE-13302
> URL: https://issues.apache.org/jira/browse/HBASE-13302
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Affects Versions: hbase-11339
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: hbase-11339
>
> Attachments: hbase-13302.hbase-11339.patch
>
>
> now that we have the qabot able to work on branches, we've detected a few
> javadoc issues. this will fix it.
> {code}
> [WARNING] Javadoc Warnings
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
> warning - @param argument "path" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "@param" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "path" is not a parameter name.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13302) fix new javadoc warns introduced by mob.
[
https://issues.apache.org/jira/browse/HBASE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371665#comment-14371665
]
Jonathan Hsieh edited comment on HBASE-13302 at 3/20/15 5:21 PM:
-
Thanks for the note. We save the deletions in the main write path so that mob
compactions can used them to clean up the mob hfiles. They can be called
"delete-tracking hfiles" but we've bee calling them "del files" in our design
docs and code.
was (Author: jmhsieh):
Thanks for the note. We save the deletions in the main write path so that mob
compactions can used them to clean up the mob hfiles. The can be called
"delete-tracking hfiles" but we've bee calling them "del files" in our design
docs and code.
> fix new javadoc warns introduced by mob.
> -
>
> Key: HBASE-13302
> URL: https://issues.apache.org/jira/browse/HBASE-13302
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Affects Versions: hbase-11339
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: hbase-11339
>
> Attachments: hbase-13302.hbase-11339.patch
>
>
> now that we have the qabot able to work on branches, we've detected a few
> javadoc issues. this will fix it.
> {code}
> [WARNING] Javadoc Warnings
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
> warning - @param argument "path" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "@param" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "path" is not a parameter name.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13302) fix new javadoc warns introduced by mob.
[
https://issues.apache.org/jira/browse/HBASE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371665#comment-14371665
]
Jonathan Hsieh edited comment on HBASE-13302 at 3/20/15 5:21 PM:
-
Thanks for the note. We save the deletions in the main write path so that mob
compactions can used them to clean up the mob hfiles. They can be called
"delete-tracking hfiles" but we've been calling them "del files" in our design
docs and code.
was (Author: jmhsieh):
Thanks for the note. We save the deletions in the main write path so that mob
compactions can used them to clean up the mob hfiles. They can be called
"delete-tracking hfiles" but we've bee calling them "del files" in our design
docs and code.
> fix new javadoc warns introduced by mob.
> -
>
> Key: HBASE-13302
> URL: https://issues.apache.org/jira/browse/HBASE-13302
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Affects Versions: hbase-11339
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: hbase-11339
>
> Attachments: hbase-13302.hbase-11339.patch
>
>
> now that we have the qabot able to work on branches, we've detected a few
> javadoc issues. this will fix it.
> {code}
> [WARNING] Javadoc Warnings
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
> warning - @param argument "path" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "@param" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "path" is not a parameter name.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[ https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371668#comment-14371668 ] Ashish Singhi commented on HBASE-13273: --- Please format the code. > Make Result.EMPTY_RESULT read-only; currently it can be modified > > > Key: HBASE-13273 > URL: https://issues.apache.org/jira/browse/HBASE-13273 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 1.0.0 >Reporter: stack >Assignee: Mikhail Antonov > Labels: beginner > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch, > HBASE-13273.patch > > > Again from [~larsgeorge] > Result result2 = Result.EMPTY_RESULT; > System.out.println(result2); > result2.copyFrom(result1); > System.out.println(result2); > "What do you think happens when result1 has cells? Yep, you just modified the > shared public EMPTY_RESULT to be not empty anymore." > Fix. Result should be non-modifiable post-construction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13297) 0.98 and 1.0: Remove client side result size calculation
[ https://issues.apache.org/jira/browse/HBASE-13297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371682#comment-14371682 ] Andrew Purtell commented on HBASE-13297: [~lhofhansl] and I were discussing this. There will be a new issue with a short term fix on the _server_ side forthcoming shortly. > 0.98 and 1.0: Remove client side result size calculation > > > Key: HBASE-13297 > URL: https://issues.apache.org/jira/browse/HBASE-13297 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 1.0.1, 0.98.13 > > Attachments: 13297-0.98.txt > > > As described in parent, this can lead to missed rows when the client and > server calculate different size values. > The patch here proposes a backwards compatible patch for 0.98 and 1.0.x. > Parent will do a patch for 1.1 and 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13302) fix new javadoc warns introduced by mob.
[
https://issues.apache.org/jira/browse/HBASE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371683#comment-14371683
]
Ashish Singhi commented on HBASE-13302:
---
Ok. Thanks for the clarification.
> fix new javadoc warns introduced by mob.
> -
>
> Key: HBASE-13302
> URL: https://issues.apache.org/jira/browse/HBASE-13302
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Affects Versions: hbase-11339
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: hbase-11339
>
> Attachments: hbase-13302.hbase-11339.patch
>
>
> now that we have the qabot able to work on branches, we've detected a few
> javadoc issues. this will fix it.
> {code}
> [WARNING] Javadoc Warnings
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileInfo.java:397:
> warning - @param argument "path" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "@param" is not a parameter name.
> [WARNING]
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java:578:
> warning - @param argument "path" is not a parameter name.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[
https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371686#comment-14371686
]
Sean Busbey commented on HBASE-13273:
-
Please also ensure we can't mutate state in EMPTY_RESULT via the
{{setExists(Boolean)}} method.
> Make Result.EMPTY_RESULT read-only; currently it can be modified
>
>
> Key: HBASE-13273
> URL: https://issues.apache.org/jira/browse/HBASE-13273
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 1.0.0
>Reporter: stack
>Assignee: Mikhail Antonov
> Labels: beginner
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
>
> Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch,
> HBASE-13273.patch
>
>
> Again from [~larsgeorge]
> Result result2 = Result.EMPTY_RESULT;
> System.out.println(result2);
> result2.copyFrom(result1);
> System.out.println(result2);
> "What do you think happens when result1 has cells? Yep, you just modified the
> shared public EMPTY_RESULT to be not empty anymore."
> Fix. Result should be non-modifiable post-construction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13273) Make Result.EMPTY_RESULT read-only; currently it can be modified
[ https://issues.apache.org/jira/browse/HBASE-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371689#comment-14371689 ] Sean Busbey commented on HBASE-13273: - Thanks for the heads up! > Make Result.EMPTY_RESULT read-only; currently it can be modified > > > Key: HBASE-13273 > URL: https://issues.apache.org/jira/browse/HBASE-13273 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 1.0.0 >Reporter: stack >Assignee: Mikhail Antonov > Labels: beginner > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13273.patch, HBASE-13273.patch, HBASE-13273.patch, > HBASE-13273.patch > > > Again from [~larsgeorge] > Result result2 = Result.EMPTY_RESULT; > System.out.println(result2); > result2.copyFrom(result1); > System.out.println(result2); > "What do you think happens when result1 has cells? Yep, you just modified the > shared public EMPTY_RESULT to be not empty anymore." > Fix. Result should be non-modifiable post-construction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13303) Fix size calculation of results on the region server
Lars Hofhansl created HBASE-13303: - Summary: Fix size calculation of results on the region server Key: HBASE-13303 URL: https://issues.apache.org/jira/browse/HBASE-13303 Project: HBase Issue Type: Sub-task Reporter: Lars Hofhansl One of the problems in the parent is due to different size calculation between client and server when HFilev3 is used. Since tags are _never_ shipped to the client in a scan, we can have special size function (or a flag on the current one) that does not include the tags and the tags meta information (the length is what causes the issue), so that client and server will always calculate the same size. I'll make a patch within the hour, unless somebody beats me to it. [~apurtell], FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13241) Add tests for group level grants
[ https://issues.apache.org/jira/browse/HBASE-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371695#comment-14371695 ] Ashish Singhi commented on HBASE-13241: --- [~mbertozzi] I have attached patch for 0.98 can we commit it. Thanks > Add tests for group level grants > > > Key: HBASE-13241 > URL: https://issues.apache.org/jira/browse/HBASE-13241 > Project: HBase > Issue Type: Improvement > Components: security, test >Reporter: Sean Busbey >Assignee: Ashish Singhi >Priority: Critical > Fix For: 2.0.0, 1.0.1, 1.1.0 > > Attachments: HBASE-13241-0.98.patch, HBASE-13241-v1.patch, > HBASE-13241-v2.patch, HBASE-13241-v3.patch, HBASE-13241-v4.patch, > HBASE-13241-v5.patch, HBASE-13241-v6.patch, HBASE-13241-v7.patch, > HBASE-13241.patch > > > We need to have tests for group-level grants for various scopes. ref: > HBASE-13239 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13262) ResultScanner doesn't return all rows in Scan
[
https://issues.apache.org/jira/browse/HBASE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371694#comment-14371694
]
Enis Soztutar commented on HBASE-13262:
---
bq. The sizing on the client is fickle and bad. It has to go.
+1.
bq. That will cause an extra RPC if the scanner caching is set such that it
would fire after the size limit, in that case we need the extra RPC to detect
that we're done with a region.
Maybe we can add a flag indicating that the client "knows" about the flag in
the openScanner() request. If the client knows about the flag, server sends the
flag, if not, the client does an extra RPC.
> ResultScanner doesn't return all rows in Scan
> -
>
> Key: HBASE-13262
> URL: https://issues.apache.org/jira/browse/HBASE-13262
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.0.0, 1.1.0
> Environment: Single node, pseduo-distributed 1.1.0-SNAPSHOT
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0, 1.1.0, 0.98.13
>
> Attachments: 13262-0.98-testpatch.txt, regionserver-logging.diff,
> testrun_0.98.txt, testrun_branch1.0.txt
>
>
> Tried to write a simple Java client again 1.1.0-SNAPSHOT.
> * Write 1M rows, each row with 1 family, and 10 qualifiers (values [0-9]),
> for a total of 10M cells written
> * Read back the data from the table, ensure I saw 10M cells
> Running it against {{04ac1891}} (and earlier) yesterday, I would get ~20% of
> the actual rows. Running against 1.0.0, returns all 10M records as expected.
> [Code I was
> running|https://github.com/joshelser/hbase-hwhat/blob/master/src/main/java/hbase/HBaseTest.java]
> for the curious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13241) Add tests for group level grants
[ https://issues.apache.org/jira/browse/HBASE-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-13241: Fix Version/s: 0.98.13 committed to 0.98, thanks! > Add tests for group level grants > > > Key: HBASE-13241 > URL: https://issues.apache.org/jira/browse/HBASE-13241 > Project: HBase > Issue Type: Improvement > Components: security, test >Reporter: Sean Busbey >Assignee: Ashish Singhi >Priority: Critical > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13241-0.98.patch, HBASE-13241-v1.patch, > HBASE-13241-v2.patch, HBASE-13241-v3.patch, HBASE-13241-v4.patch, > HBASE-13241-v5.patch, HBASE-13241-v6.patch, HBASE-13241-v7.patch, > HBASE-13241.patch > > > We need to have tests for group-level grants for various scopes. ref: > HBASE-13239 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13282) Fix the minor issues of running Canary on kerberized environment
[
https://issues.apache.org/jira/browse/HBASE-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-13282:
Attachment: HBASE-13282_v2.patch
Addressed both suggestions by [~mbertozzi]. The sample error message while
doing cat log|grep "initial login" looks like this:
{code}
015-03-20 09:06:25,726 ERROR [main] hbase.AuthUtil: Error while trying to
perform the initial login: Login failure for hbase/x...@yyy.com from keytab
hbase.keytab
{code}
> Fix the minor issues of running Canary on kerberized environment
>
>
> Key: HBASE-13282
> URL: https://issues.apache.org/jira/browse/HBASE-13282
> Project: HBase
> Issue Type: Bug
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
>Priority: Minor
> Attachments: HBASE-13282.patch, HBASE-13282.patch,
> HBASE-13282_v2.patch
>
>
> Found two minor issues.
> * Canary tool not logging exception when failing to authenticate.
> * Can't use -D option for setting keytab and principal as auth chore is being
> launched before calling ToolRunner.run method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13304) hbase cleanup script with --cleanAll argument should clean up acls also
Ashish Singhi created HBASE-13304: - Summary: hbase cleanup script with --cleanAll argument should clean up acls also Key: HBASE-13304 URL: https://issues.apache.org/jira/browse/HBASE-13304 Project: HBase Issue Type: Bug Affects Versions: 0.98.12 Reporter: Ashish Singhi Assignee: Ashish Singhi Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13304) hbase cleanup script with --cleanAll argument should clean up acls also
[ https://issues.apache.org/jira/browse/HBASE-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-13304: -- Attachment: HBASE-13304.patch > hbase cleanup script with --cleanAll argument should clean up acls also > --- > > Key: HBASE-13304 > URL: https://issues.apache.org/jira/browse/HBASE-13304 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.12 >Reporter: Ashish Singhi >Assignee: Ashish Singhi >Priority: Minor > Attachments: HBASE-13304.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13303) Fix size calculation of results on the region server
[ https://issues.apache.org/jira/browse/HBASE-13303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13303: --- Attachment: HBASE-13303-0.98.patch Something like this? > Fix size calculation of results on the region server > > > Key: HBASE-13303 > URL: https://issues.apache.org/jira/browse/HBASE-13303 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl > Fix For: 2.0.0, 1.1.0, 0.98.13 > > Attachments: HBASE-13303-0.98.patch > > > One of the problems in the parent is due to different size calculation > between client and server when HFilev3 is used. > Since tags are _never_ shipped to the client in a scan, we can have special > size function (or a flag on the current one) that does not include the tags > and the tags meta information (the length is what causes the issue), so that > client and server will always calculate the same size. > I'll make a patch within the hour, unless somebody beats me to it. > [~apurtell], FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13304) hbase cleanup script with --cleanAll argument should clean up acls also
[ https://issues.apache.org/jira/browse/HBASE-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-13304: -- Fix Version/s: 0.98.13 1.1.0 1.0.1 2.0.0 Status: Patch Available (was: Open) Simple fix. Please review. > hbase cleanup script with --cleanAll argument should clean up acls also > --- > > Key: HBASE-13304 > URL: https://issues.apache.org/jira/browse/HBASE-13304 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.12 >Reporter: Ashish Singhi >Assignee: Ashish Singhi >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13304.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13303) Fix size calculation of results on the region server
[ https://issues.apache.org/jira/browse/HBASE-13303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371736#comment-14371736 ] Andrew Purtell commented on HBASE-13303: Now let me move that to CellUtil > Fix size calculation of results on the region server > > > Key: HBASE-13303 > URL: https://issues.apache.org/jira/browse/HBASE-13303 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl > Fix For: 2.0.0, 1.1.0, 0.98.13 > > Attachments: HBASE-13303-0.98.patch > > > One of the problems in the parent is due to different size calculation > between client and server when HFilev3 is used. > Since tags are _never_ shipped to the client in a scan, we can have special > size function (or a flag on the current one) that does not include the tags > and the tags meta information (the length is what causes the issue), so that > client and server will always calculate the same size. > I'll make a patch within the hour, unless somebody beats me to it. > [~apurtell], FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13282) Fix the minor issues of running Canary on kerberized environment
[ https://issues.apache.org/jira/browse/HBASE-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13282: Attachment: HBASE-13282_v2.patch Fixing the checkstyle error. > Fix the minor issues of running Canary on kerberized environment > > > Key: HBASE-13282 > URL: https://issues.apache.org/jira/browse/HBASE-13282 > Project: HBase > Issue Type: Bug >Reporter: Srikanth Srungarapu >Assignee: Srikanth Srungarapu >Priority: Minor > Attachments: HBASE-13282.patch, HBASE-13282.patch, > HBASE-13282_v2.patch > > > Found two minor issues. > * Canary tool not logging exception when failing to authenticate. > * Can't use -D option for setting keytab and principal as auth chore is being > launched before calling ToolRunner.run method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13303) Fix size calculation of results on the region server
[ https://issues.apache.org/jira/browse/HBASE-13303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13303: --- Attachment: HBASE-13303-0.98.patch > Fix size calculation of results on the region server > > > Key: HBASE-13303 > URL: https://issues.apache.org/jira/browse/HBASE-13303 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl > Fix For: 2.0.0, 1.1.0, 0.98.13 > > Attachments: HBASE-13303-0.98.patch > > > One of the problems in the parent is due to different size calculation > between client and server when HFilev3 is used. > Since tags are _never_ shipped to the client in a scan, we can have special > size function (or a flag on the current one) that does not include the tags > and the tags meta information (the length is what causes the issue), so that > client and server will always calculate the same size. > I'll make a patch within the hour, unless somebody beats me to it. > [~apurtell], FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13282) Fix the minor issues of running Canary on kerberized environment
[ https://issues.apache.org/jira/browse/HBASE-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13282: Attachment: (was: HBASE-13282_v2.patch) > Fix the minor issues of running Canary on kerberized environment > > > Key: HBASE-13282 > URL: https://issues.apache.org/jira/browse/HBASE-13282 > Project: HBase > Issue Type: Bug >Reporter: Srikanth Srungarapu >Assignee: Srikanth Srungarapu >Priority: Minor > Attachments: HBASE-13282.patch, HBASE-13282.patch, > HBASE-13282_v2.patch > > > Found two minor issues. > * Canary tool not logging exception when failing to authenticate. > * Can't use -D option for setting keytab and principal as auth chore is being > launched before calling ToolRunner.run method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13303) Fix size calculation of results on the region server
[ https://issues.apache.org/jira/browse/HBASE-13303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-13303: --- Attachment: (was: HBASE-13303-0.98.patch) > Fix size calculation of results on the region server > > > Key: HBASE-13303 > URL: https://issues.apache.org/jira/browse/HBASE-13303 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Lars Hofhansl > Fix For: 2.0.0, 1.1.0, 0.98.13 > > Attachments: HBASE-13303-0.98.patch > > > One of the problems in the parent is due to different size calculation > between client and server when HFilev3 is used. > Since tags are _never_ shipped to the client in a scan, we can have special > size function (or a flag on the current one) that does not include the tags > and the tags meta information (the length is what causes the issue), so that > client and server will always calculate the same size. > I'll make a patch within the hour, unless somebody beats me to it. > [~apurtell], FYI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13304) hbase cleanup script with --cleanAll argument should clean up acls also
[ https://issues.apache.org/jira/browse/HBASE-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371745#comment-14371745 ] Matteo Bertozzi commented on HBASE-13304: - clean all removes the /hbase znode... so we don't have any znode to cleanup acls from > hbase cleanup script with --cleanAll argument should clean up acls also > --- > > Key: HBASE-13304 > URL: https://issues.apache.org/jira/browse/HBASE-13304 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.12 >Reporter: Ashish Singhi >Assignee: Ashish Singhi >Priority: Minor > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13 > > Attachments: HBASE-13304.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13304) hbase cleanup script with --cleanAll argument should clean up acls also
[ https://issues.apache.org/jira/browse/HBASE-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-13304: -- Resolution: Invalid Fix Version/s: (was: 0.98.13) (was: 1.1.0) (was: 1.0.1) (was: 2.0.0) Assignee: (was: Ashish Singhi) Status: Resolved (was: Patch Available) Thanks. --cleanZk will remove the znode. So there is no point of executing --cleanAcls after it. My bad did not notice this before. > hbase cleanup script with --cleanAll argument should clean up acls also > --- > > Key: HBASE-13304 > URL: https://issues.apache.org/jira/browse/HBASE-13304 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.12 >Reporter: Ashish Singhi >Priority: Minor > Attachments: HBASE-13304.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-13262) ResultScanner doesn't return all rows in Scan
[
https://issues.apache.org/jira/browse/HBASE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-13262:
---
Comment: was deleted
(was: An extra RPC will be quite bad for performance, especially for clients
like Phoenix, which does a lot of short scans using guideposts. We should
backport the NextState (or similar) changes all the way back to 0.98 as I
proposed above. I will do this if nobody else wants to do the work. I don't see
any reason the changes cannot be both backwards and forwards compatible. )
> ResultScanner doesn't return all rows in Scan
> -
>
> Key: HBASE-13262
> URL: https://issues.apache.org/jira/browse/HBASE-13262
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.0.0, 1.1.0
> Environment: Single node, pseduo-distributed 1.1.0-SNAPSHOT
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0, 1.1.0, 0.98.13
>
> Attachments: 13262-0.98-testpatch.txt, regionserver-logging.diff,
> testrun_0.98.txt, testrun_branch1.0.txt
>
>
> Tried to write a simple Java client again 1.1.0-SNAPSHOT.
> * Write 1M rows, each row with 1 family, and 10 qualifiers (values [0-9]),
> for a total of 10M cells written
> * Read back the data from the table, ensure I saw 10M cells
> Running it against {{04ac1891}} (and earlier) yesterday, I would get ~20% of
> the actual rows. Running against 1.0.0, returns all 10M records as expected.
> [Code I was
> running|https://github.com/joshelser/hbase-hwhat/blob/master/src/main/java/hbase/HBaseTest.java]
> for the curious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
