[jira] [Commented] (HBASE-13269) Limit result array preallocation to avoid OOME with large scan caching values
[ https://issues.apache.org/jira/browse/HBASE-13269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368617#comment-14368617 ] Hudson commented on HBASE-13269: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #863 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/863/]) HBASE-13269 Limit result array preallocation to avoid OOME with large scan caching values (apurtell: rev 8fa491e709770ca73701adeb474807ec87b421af) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java > Limit result array preallocation to avoid OOME with large scan caching values > - > > Key: HBASE-13269 > URL: https://issues.apache.org/jira/browse/HBASE-13269 > Project: HBase > Issue Type: Bug >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 1.0.1, 0.98.12 > > Attachments: HBASE-13269-0.98.patch, HBASE-13269-0.98.patch, > HBASE-13269-1.0.patch, HBASE-13269-1.0.patch > > > Scan#setCaching(Integer.MAX_VALUE) will likely terminate the regionserver > with an OOME due to preallocation of the result array according to this > parameter. We should limit the preallocation to some sane value. Definitely > affects 0.98 (fix needed to HRegionServer) and 1.0.x (fix needed to > RsRPCServices), not sure about later versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14368618#comment-14368618
]
Hadoop QA commented on HBASE-13282:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705530/HBASE-13282.patch
against master branch at commit 014b8121031d6268f73f901d54c32a9d880bb12f.
ATTACHMENT ID: 12705530
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13310//console
This message is automatically generated.
> 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
>
>
> 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-13283) Document the steps for rolling back the security on hbase.
Srikanth Srungarapu created HBASE-13283:
---
Summary: 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
Would be great to document the steps the user should follow to rollback the
security. The following are
* shutdown hbase
* remove the /hbase znode from zookeeper
* run hbase clean up script with --cleanAcls introduced in HBASE-13162.
* remove from the hbase-site.xml conf
{code}
hbase.security.authentication
hbase.rpc.engine
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] [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.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 > > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=14368627#comment-14368627 ] Srikanth Srungarapu commented on HBASE-13282: - Attaching new rebased 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 > > > 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] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368630#comment-14368630
]
zhangduo commented on HBASE-13280:
--
Let me try...
BTW, do you use mac [~liushaohui]?
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Reporter: Liu Shaohui
>Priority: Minor
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:735)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connec
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14368632#comment-14368632
]
Matteo Bertozzi commented on HBASE-13282:
-
Did you look at the output on failure?
in theory if you do something like:
{code}
LOG.error("xyz-msg: " + e.getMessage(), e);
{code}
you can see the "simple user error" by doing cat log | grep "initial login"
otherwise you have to look at the line below for the exception message + stack
trace.
but do not trust me on this, check the output to see if what I said is true :)
Do we need to create/shutdown the choreService, if the authChore is null?
maybe change like this?
{code}
final ScheduledChore authChore = AuthUtil.getAuthChore(conf);
if (authChore != null) {
choreService = new ChoreService("CANARY_TOOL");
choreService.scheduleChore(authChore);
}
...
if (choreService != null) {
choreService.shutdown();
}
{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
>
>
> 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-13235) Revisit the security auditing semantics.
[
https://issues.apache.org/jira/browse/HBASE-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-13235:
Resolution: Fixed
Fix Version/s: 1.1.0
2.0.0
Status: Resolved (was: Patch Available)
committed to branch-1 and master
> Revisit the security auditing semantics.
>
>
> Key: HBASE-13235
> URL: https://issues.apache.org/jira/browse/HBASE-13235
> Project: HBase
> Issue Type: Improvement
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13235.patch, HBASE-13235_v2.patch,
> HBASE-13235_v2.patch, HBASE-13235_v3.patch, HBASE-13235_v4.patch
>
>
> More specifically, the following things need a closer look. (Will include
> more based on feedback and/or suggestions)
> * Table name (say test) instead of fully qualified table name(default:test)
> being used.
> * Right now, we're using the scope to be similar to arguments for operation.
> Would be better to decouple the arguments for operation and scope involved in
> checking. For e.g. say for createTable, we have the following audit log
> {code}
> Access denied for user esteban; reason: Insufficient permissions; remote
> address: /10.20.30.1; request: createTable; context: (user=srikanth@XXX,
> scope=default, action=CREATE)
> {code}
> The scope was rightly being used as default namespace, but we're missing out
> the information like operation params for CREATE which we used to log prior
> to HBASE-12511.
> Would love to hear inputs on this!
--
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=14368636#comment-14368636
]
Matteo Bertozzi commented on HBASE-13283:
-
why do we need to remove the /hbase znode when we now have the --cleanAcls
script?
also what about replication if you are doing that
> 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
>* remove the /hbase znode from zookeeper
>* run hbase clean up script with --cleanAcls introduced in HBASE-13162.
>* remove from the hbase-site.xml conf
> {code}
> hbase.security.authentication
> hbase.rpc.engine
> 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-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=14368640#comment-14368640
]
Matteo Bertozzi commented on HBASE-13283:
-
...and as far as I know the secure rpc.engine is gone in 96+. so that
"hbase.rpc.engine" shouldn't be in the configuration
> 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
>* remove the /hbase znode from zookeeper
>* run hbase clean up script with --cleanAcls introduced in HBASE-13162.
>* remove from the hbase-site.xml conf
> {code}
> hbase.security.authentication
> hbase.rpc.engine
> 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] [Updated] (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:all-tabpanel
]
Srikanth Srungarapu updated HBASE-13283:
Description:
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.rpc.engine
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]
was:
Would be great to document the steps the user should follow to rollback the
security. The following are
* shutdown hbase
* remove the /hbase znode from zookeeper
* run hbase clean up script with --cleanAcls introduced in HBASE-13162.
* remove from the hbase-site.xml conf
{code}
hbase.security.authentication
hbase.rpc.engine
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]
> 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.rpc.engine
> 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] [Updated] (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:all-tabpanel
]
Srikanth Srungarapu updated HBASE-13283:
Description:
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]
was:
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.rpc.engine
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]
> 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-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=14368641#comment-14368641
]
Srikanth Srungarapu commented on HBASE-13283:
-
My bad. Fixed it. Thanks for pointing out.
> 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.rpc.engine
> 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-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368644#comment-14368644
]
Liu Shaohui commented on HBASE-13280:
-
[~Apache9]
No. Ubuntu 14.04 with jdk 1.7.0_55.
And do the tests depend on krb5.conf in local ?
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Reporter: Liu Shaohui
>Priority: Minor
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:735)
>
[jira] [Commented] (HBASE-13114) [UNITTEST] TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
[
https://issues.apache.org/jira/browse/HBASE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368647#comment-14368647
]
Matteo Bertozzi commented on HBASE-13114:
-
why we catch any exception from create/delete and go on?
shouldn't we fail the test? the outcome after that will be wrong anyway.
other than that patch looks good to me. hopefully this stuff will be removed
and fixed once and for all with HBASE-13204
> [UNITTEST] TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
> -
>
> Key: HBASE-13114
> URL: https://issues.apache.org/jira/browse/HBASE-13114
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Esteban Gutierrez
> Attachments:
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch,
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch,
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch, 13114.txt
>
>
> I've seen this fail a few times. It just happened now on internal rig.
> Looking into it
> {code}
> REGRESSION:
> org.apache.hadoop.hbase.master.handler.TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
> Error Message:
> expected:<0> but was:<1>
> Stack Trace:
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.hadoop.hbase.master.handler.TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta(TestEnableTableHandler.java:151)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13284) Document the format of audit logs.
Srikanth Srungarapu created HBASE-13284: --- Summary: Document the format of audit logs. Key: HBASE-13284 URL: https://issues.apache.org/jira/browse/HBASE-13284 Project: HBase Issue Type: Sub-task Reporter: Srikanth Srungarapu We'll be logging a new field called params which basically is the set of parameters needed for carrying on the operation at the server side. Parent jira has bunch of examples with the new changes. cc: [~misty] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13284) Document the format of audit logs.
[ https://issues.apache.org/jira/browse/HBASE-13284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13284: Description: Couldn't find any documentation on format being followed for audit logs. We'll be logging a new field called params along with the traditional format which basically is the set of parameters needed for carrying on the operation at the server side. Parent jira has bunch of examples with the new changes. cc: [~misty] was: We'll be logging a new field called params which basically is the set of parameters needed for carrying on the operation at the server side. Parent jira has bunch of examples with the new changes. cc: [~misty] > Document the format of audit logs. > -- > > Key: HBASE-13284 > URL: https://issues.apache.org/jira/browse/HBASE-13284 > Project: HBase > Issue Type: Sub-task >Reporter: Srikanth Srungarapu > Fix For: 2.0.0, 1.1.0 > > > Couldn't find any documentation on format being followed for audit logs. > We'll be logging a new field called params along with the traditional format > which basically is the set of parameters needed for carrying on the operation > at the server side. Parent jira has bunch of examples with the new changes. > cc: [~misty] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368672#comment-14368672
]
zhangduo commented on HBASE-13280:
--
{quote}
And do the tests depend on krb5.conf in local ?
{quote}
I suppose not. MiniKdc will refresh krb config. I put a krb5.conf under /etc
then run the test. It had no effect.
Try change 'HOST = InetAddress.getLocalHost().getHostName();' to
'HOST='localhost;'' and try again? LDAP is so complicated so I'm not sure what
is the reason, just guess...
And have you run it on a server instead of local machine? Does it fail either?
Thanks.
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Reporter: Liu Shaohui
>Priority: Minor
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseS
[jira] [Commented] (HBASE-13235) Revisit the security auditing semantics.
[
https://issues.apache.org/jira/browse/HBASE-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368678#comment-14368678
]
Hudson commented on HBASE-13235:
FAILURE: Integrated in HBase-TRUNK #6278 (See
[https://builds.apache.org/job/HBase-TRUNK/6278/])
HBASE-13235 Revisit the security auditing semantics (Srikanth Srungarapu)
(matteo.bertozzi: rev 535ebbfde9e424fab27f79bfa6b40964c4918fc6)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/TableName.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AuthResult.java
> Revisit the security auditing semantics.
>
>
> Key: HBASE-13235
> URL: https://issues.apache.org/jira/browse/HBASE-13235
> Project: HBase
> Issue Type: Improvement
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13235.patch, HBASE-13235_v2.patch,
> HBASE-13235_v2.patch, HBASE-13235_v3.patch, HBASE-13235_v4.patch
>
>
> More specifically, the following things need a closer look. (Will include
> more based on feedback and/or suggestions)
> * Table name (say test) instead of fully qualified table name(default:test)
> being used.
> * Right now, we're using the scope to be similar to arguments for operation.
> Would be better to decouple the arguments for operation and scope involved in
> checking. For e.g. say for createTable, we have the following audit log
> {code}
> Access denied for user esteban; reason: Insufficient permissions; remote
> address: /10.20.30.1; request: createTable; context: (user=srikanth@XXX,
> scope=default, action=CREATE)
> {code}
> The scope was rightly being used as default namespace, but we're missing out
> the information like operation params for CREATE which we used to log prior
> to HBASE-12511.
> Would love to hear inputs on this!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13071) Hbase Streaming Scan Feature
[ https://issues.apache.org/jira/browse/HBASE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368689#comment-14368689 ] Edward Bortnikov commented on HBASE-13071: -- I second [~eshcar]. This is not a huge feature, and everybody seems to benefit. If there is anything else we should do about the code review - let's do it, and race to commit :) Thanks, Edward > Hbase Streaming Scan Feature > > > Key: HBASE-13071 > URL: https://issues.apache.org/jira/browse/HBASE-13071 > Project: HBase > Issue Type: New Feature >Reporter: Eshcar Hillel > Attachments: 99.eshcar.png, HBASE-13071_98_1.patch, > HBASE-13071_trunk_1.patch, HBASE-13071_trunk_10.patch, > HBASE-13071_trunk_2.patch, HBASE-13071_trunk_3.patch, > HBASE-13071_trunk_4.patch, HBASE-13071_trunk_5.patch, > HBASE-13071_trunk_6.patch, HBASE-13071_trunk_7.patch, > HBASE-13071_trunk_8.patch, HBASE-13071_trunk_9.patch, > HBaseStreamingScanDesign.pdf, HbaseStreamingScanEvaluation.pdf, > HbaseStreamingScanEvaluationwithMultipleClients.pdf, gc.eshcar.png, > hits.eshcar.png, network.png > > > A scan operation iterates over all rows of a table or a subrange of the > table. The synchronous nature in which the data is served at the client side > hinders the speed the application traverses the data: it increases the > overall processing time, and may cause a great variance in the times the > application waits for the next piece of data. > The scanner next() method at the client side invokes an RPC to the > regionserver and then stores the results in a cache. The application can > specify how many rows will be transmitted per RPC; by default this is set to > 100 rows. > The cache can be considered as a producer-consumer queue, where the hbase > client pushes the data to the queue and the application consumes it. > Currently this queue is synchronous, i.e., blocking. More specifically, when > the application consumed all the data from the cache --- so the cache is > empty --- the hbase client retrieves additional data from the server and > re-fills the cache with new data. During this time the application is blocked. > Under the assumption that the application processing time can be balanced by > the time it takes to retrieve the data, an asynchronous approach can reduce > the time the application is waiting for data. > We attach a design document. > We also have a patch that is based on a private branch, and some evaluation > results of this code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13114) [UNITTEST] TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
[
https://issues.apache.org/jira/browse/HBASE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368701#comment-14368701
]
Hadoop QA commented on HBASE-13114:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705526/0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch
against master branch at commit 014b8121031d6268f73f901d54c32a9d880bb12f.
ATTACHMENT ID: 12705526
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color: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/13309//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13309//console
This message is automatically generated.
> [UNITTEST] TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
> -
>
> Key: HBASE-13114
> URL: https://issues.apache.org/jira/browse/HBASE-13114
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Esteban Gutierrez
> Attachments:
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch,
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch,
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch, 13114.txt
>
>
> I've seen this fail a few times. It just happened now on internal rig.
> Looking into it
> {code}
> REGRESSION:
> org.apache.hadoop.hbase.master.handler.TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
> Error Message:
> expected:<0> but was:<1>
> Stack Trace:
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.
[jira] [Commented] (HBASE-13187) Add ITBLL that exercises per CF flush
[ https://issues.apache.org/jira/browse/HBASE-13187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368707#comment-14368707 ] zhangduo commented on HBASE-13187: -- I have not fully understood the 'magic' of how to generate the big linked list here, but I suggest to generate tiny and big value based on rowkey(or some other values in the row) so that we can also verify whether the data of tiny and big family are also correct? Thanks. > Add ITBLL that exercises per CF flush > - > > Key: HBASE-13187 > URL: https://issues.apache.org/jira/browse/HBASE-13187 > Project: HBase > Issue Type: Task > Components: integration tests >Reporter: stack >Assignee: stack >Priority: Critical > Fix For: 2.0.0, 1.1.0 > > Attachments: 13187.txt > > > Let me work on this. It would be excellent if we could have confidence to > turn this on earlier rather than later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13235) Revisit the security auditing semantics.
[
https://issues.apache.org/jira/browse/HBASE-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368715#comment-14368715
]
Hudson commented on HBASE-13235:
FAILURE: Integrated in HBase-1.1 #302 (See
[https://builds.apache.org/job/HBase-1.1/302/])
HBASE-13235 Revisit the security auditing semantics (Srikanth Srungarapu)
(matteo.bertozzi: rev 6b411b5d00e114946aeee1c6fa6f0d60fe04087a)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/TableName.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AuthResult.java
> Revisit the security auditing semantics.
>
>
> Key: HBASE-13235
> URL: https://issues.apache.org/jira/browse/HBASE-13235
> Project: HBase
> Issue Type: Improvement
>Reporter: Srikanth Srungarapu
>Assignee: Srikanth Srungarapu
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13235.patch, HBASE-13235_v2.patch,
> HBASE-13235_v2.patch, HBASE-13235_v3.patch, HBASE-13235_v4.patch
>
>
> More specifically, the following things need a closer look. (Will include
> more based on feedback and/or suggestions)
> * Table name (say test) instead of fully qualified table name(default:test)
> being used.
> * Right now, we're using the scope to be similar to arguments for operation.
> Would be better to decouple the arguments for operation and scope involved in
> checking. For e.g. say for createTable, we have the following audit log
> {code}
> Access denied for user esteban; reason: Insufficient permissions; remote
> address: /10.20.30.1; request: createTable; context: (user=srikanth@XXX,
> scope=default, action=CREATE)
> {code}
> The scope was rightly being used as default namespace, but we're missing out
> the information like operation params for CREATE which we used to log prior
> to HBASE-12511.
> Would love to hear inputs on this!
--
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 ] Ashish Singhi updated HBASE-13241: -- Attachment: HBASE-13241-v6.patch > 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 > Attachments: 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.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] [Created] (HBASE-13285) Fix flaky getRegions() in TestAccessController.setUp()
Matteo Bertozzi created HBASE-13285:
---
Summary: Fix flaky getRegions() in TestAccessController.setUp()
Key: HBASE-13285
URL: https://issues.apache.org/jira/browse/HBASE-13285
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.98.12, 1.0.0, 2.0.0, 1.1.0
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Minor
TestAccessController is waiting on table to be enabled and after that tries to
lookup the region. but if the machine is slow, that region may not be assigned
yet.
{code}
TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
HRegion region =
TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13285) Fix flaky getRegions() in TestAccessController.setUp()
[
https://issues.apache.org/jira/browse/HBASE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-13285:
Attachment: HBASE-13285-v0.patch
> Fix flaky getRegions() in TestAccessController.setUp()
> --
>
> Key: HBASE-13285
> URL: https://issues.apache.org/jira/browse/HBASE-13285
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.12
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-13285-v0.patch
>
>
> TestAccessController is waiting on table to be enabled and after that tries
> to lookup the region. but if the machine is slow, that region may not be
> assigned yet.
> {code}
> TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
> HRegion region =
> TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13285) Fix flaky getRegions() in TestAccessController.setUp()
[
https://issues.apache.org/jira/browse/HBASE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-13285:
Description:
TestAccessController is waiting on table to be enabled and after that tries to
lookup the region. but if the machine is slow, that region may not be assigned
yet.
{code}
TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
HRegion region =
TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
{code}
{noformat}
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:635)
at java.util.ArrayList.get(ArrayList.java:411)
at
org.apache.hadoop.hbase.security.access.TestAccessController.setUp(TestAccessController.java:235)
{noformat}
was:
TestAccessController is waiting on table to be enabled and after that tries to
lookup the region. but if the machine is slow, that region may not be assigned
yet.
{code}
TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
HRegion region =
TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
{code}
> Fix flaky getRegions() in TestAccessController.setUp()
> --
>
> Key: HBASE-13285
> URL: https://issues.apache.org/jira/browse/HBASE-13285
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.12
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-13285-v0.patch
>
>
> TestAccessController is waiting on table to be enabled and after that tries
> to lookup the region. but if the machine is slow, that region may not be
> assigned yet.
> {code}
> TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
> HRegion region =
> TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
> {code}
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.setUp(TestAccessController.java:235)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13285) Fix flaky getRegions() in TestAccessController.setUp()
[
https://issues.apache.org/jira/browse/HBASE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-13285:
Status: Patch Available (was: Open)
> Fix flaky getRegions() in TestAccessController.setUp()
> --
>
> Key: HBASE-13285
> URL: https://issues.apache.org/jira/browse/HBASE-13285
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.98.12, 1.0.0, 2.0.0, 1.1.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-13285-v0.patch
>
>
> TestAccessController is waiting on table to be enabled and after that tries
> to lookup the region. but if the machine is slow, that region may not be
> assigned yet.
> {code}
> TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
> HRegion region =
> TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
> {code}
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.setUp(TestAccessController.java:235)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368764#comment-14368764
]
Liu Shaohui commented on HBASE-13280:
-
Tests passed after changing HOST to 'localhost'.
Thanks
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Reporter: Liu Shaohui
>Priority: Minor
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:735)
> at
> org.apache.hadoop.hbase.ipc.RpcCli
[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=14368769#comment-14368769 ] Ashish Singhi commented on HBASE-13241: --- Attached patch addressing the concerns. I have removed test which was just verifying grant and revoke permissions as it was not much value add. In the new test I have two groups each having one user. The test verifies whether user from the group which has access is able to scan the table and retrieve the expected result and the user from other group which does not have access should not be able to scan the table. Please review. > 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 > Attachments: 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.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-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368767#comment-14368767
]
Liu Shaohui commented on HBASE-13280:
-
[~Apache9]
Should we do some fix or not?
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Reporter: Liu Shaohui
>Priority: Minor
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:735)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connecti
[jira] [Commented] (HBASE-13114) [UNITTEST] TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
[
https://issues.apache.org/jira/browse/HBASE-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368772#comment-14368772
]
Andrey Stepachev commented on HBASE-13114:
--
looks good to me.
btw, would it be better to have this observer in HBaseTestingUtility and some
minimal infrastructure to handle that in other tests if needed?
say we have methods createTable(), that would be good to have them use this
observer.
what do you think?
> [UNITTEST] TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
> -
>
> Key: HBASE-13114
> URL: https://issues.apache.org/jira/browse/HBASE-13114
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Esteban Gutierrez
> Attachments:
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch,
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch,
> 0001-UNITTEST-TestEnableTableHandler.testDeleteForSureCle.patch, 13114.txt
>
>
> I've seen this fail a few times. It just happened now on internal rig.
> Looking into it
> {code}
> REGRESSION:
> org.apache.hadoop.hbase.master.handler.TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta
> Error Message:
> expected:<0> but was:<1>
> Stack Trace:
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.hadoop.hbase.master.handler.TestEnableTableHandler.testDeleteForSureClearsAllTableRowsFromMeta(TestEnableTableHandler.java:151)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368777#comment-14368777
]
zhangduo commented on HBASE-13280:
--
Yes, seems InetAddress.getLocalHost().getHostName() is not reliable in unit
test.
And I use it in other unit tests too, let me change all of them.
Thanks [~liushaohui]
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Reporter: Liu Shaohui
>Priority: Minor
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
> at
> org.apache.hadoop.hbase.i
[jira] [Updated] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhangduo updated HBASE-13280:
-
Fix Version/s: 1.1.0
2.0.0
Assignee: zhangduo
Affects Version/s: 1.1.0
2.0.0
Status: Patch Available (was: Open)
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.a
[jira] [Updated] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhangduo updated HBASE-13280:
-
Attachment: HBASE-13280.patch
Use 'localhost' instead of 'InetAddress.getLocalHost().getHostName()' as
hostname in kerberos related testcase.
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Reporter: Liu Shaohui
>Priority: Minor
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(Rp
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368788#comment-14368788
]
zhangduo commented on HBASE-13280:
--
[~liushaohui] Would you please help verifying the other two unit tests? They
also use InetAddress.getLocalHost().getHostName() as host name.
Thanks.
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
[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=14368792#comment-14368792
]
Matteo Bertozzi commented on HBASE-13241:
-
a couple of things:
replace waitTableEnabled() with waitUntilAllRegionsAssigned()
since you have multiple and different actions/checks grouped in a single test.
add a message to the assert. assert(msg, cond), at least it will be easy to
identify what may be the problem without looking at the code. otherwise the
failure will look like this
{noformat}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at
org.apache.hadoop.hbase.security.access.TestAccessController2$7.run(TestAccessController2.java:362)
at
org.apache.hadoop.hbase.security.access.TestAccessController2$7.run(TestAccessController2.java:354)
...
at
org.apache.hadoop.hbase.security.access.SecureTestUtil.verifyAllowed(SecureTestUtil.java:160)
at
org.apache.hadoop.hbase.security.access.TestAccessController2.testPostGrantAndRevokeScanAction(TestAccessController2.java:424)
{noformat}
> 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
> Attachments: 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.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-13285) Fix flaky getRegions() in TestAccessController.setUp()
[
https://issues.apache.org/jira/browse/HBASE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368798#comment-14368798
]
Ashish Singhi commented on HBASE-13285:
---
Shouldn't this we do this at all places in test code.
For example similar was reported in HBASE-13280
> Fix flaky getRegions() in TestAccessController.setUp()
> --
>
> Key: HBASE-13285
> URL: https://issues.apache.org/jira/browse/HBASE-13285
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.12
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-13285-v0.patch
>
>
> TestAccessController is waiting on table to be enabled and after that tries
> to lookup the region. but if the machine is slow, that region may not be
> assigned yet.
> {code}
> TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
> HRegion region =
> TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
> {code}
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.setUp(TestAccessController.java:235)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13285) Fix flaky getRegions() in TestAccessController.setUp()
[
https://issues.apache.org/jira/browse/HBASE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368803#comment-14368803
]
Ashish Singhi commented on HBASE-13285:
---
Sorry, HBASE-13280 has some other cause.
> Fix flaky getRegions() in TestAccessController.setUp()
> --
>
> Key: HBASE-13285
> URL: https://issues.apache.org/jira/browse/HBASE-13285
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.12
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-13285-v0.patch
>
>
> TestAccessController is waiting on table to be enabled and after that tries
> to lookup the region. but if the machine is slow, that region may not be
> assigned yet.
> {code}
> TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
> HRegion region =
> TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
> {code}
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.setUp(TestAccessController.java:235)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368805#comment-14368805
]
Liu Shaohui commented on HBASE-13280:
-
[~Apache9]
TestUsersOperationsWithSecureHadoop passed , but TestGenerateDelegationToken
failed in dev machine without changing host.
TestGenerateDelegationToken passed after the change.
{code}
mvn clean package -PrunSmallTests -Dtest=TestUsersOperationsWithSecureHadoop
mvn clean package -PrunMediumTests -Dtest=TestGenerateDelegationToken
{code}
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache
[jira] [Commented] (HBASE-13285) Fix flaky getRegions() in TestAccessController.setUp()
[
https://issues.apache.org/jira/browse/HBASE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368807#comment-14368807
]
Matteo Bertozzi commented on HBASE-13285:
-
yeah, not all the IndexOutOfBoundsException are the same, HBASE-13280 is a
different problem.
but in general if you want to grab the region or just make sure that your table
is up and running after table creation you should make sure that we have the
region assigned. so that wait is better than just wait enabled
> Fix flaky getRegions() in TestAccessController.setUp()
> --
>
> Key: HBASE-13285
> URL: https://issues.apache.org/jira/browse/HBASE-13285
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.12
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-13285-v0.patch
>
>
> TestAccessController is waiting on table to be enabled and after that tries
> to lookup the region. but if the machine is slow, that region may not be
> assigned yet.
> {code}
> TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
> HRegion region =
> TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
> {code}
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.setUp(TestAccessController.java:235)
> {noformat}
--
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 ] Ashish Singhi updated HBASE-13241: -- Attachment: HBASE-13241-v7.patch > 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 > Attachments: 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-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=14368816#comment-14368816 ] Ashish Singhi commented on HBASE-13241: --- Thanks for reviewing. Addressed the comments. > 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 > Attachments: 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-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368813#comment-14368813
]
zhangduo commented on HBASE-13280:
--
OK, Great. Seems we does something in RPC that causes the
problem(TestUsersOperationsWithSecureHadoop does not use RPC). Not important I
think.
Let's see what PreCommit say.
Thanks.
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(R
[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=14368844#comment-14368844
]
Lars George commented on HBASE-13270:
-
I am +1 on the patch.
> 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=14368848#comment-14368848
]
Matteo Bertozzi commented on HBASE-13270:
-
dumb question: why addStats() and not setStats()? we are not appending
anything... maybe it is just grammar or it sounds better dunno :)
> 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-13271) Table#puts(List) operation is indeterminate; remove!
[
https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368862#comment-14368862
]
Lars George commented on HBASE-13271:
-
Good discussion already, let me chime in: yes, this is about the
autoflush==true case. And yes, this is _only_ using the new API. In that case,
you have either a BufferedMutator or a Table. The latter has put(List) but
what it does in case of an error is hard to handle since we mix local and
remote errors. The remote errors can be dealt with when catching the exception.
But inserting mutations into the local write buffer and triggering a local
error (put is empty, or some such) will cause the above scenario.
I also like to have a put(List) option, it is handy. So what could be done.
Catching the exception and doing the flush() in the final does not help much,
as it leaves the other Puts uncommitted. Example: you have 5 puts an the third
is empty. You call put(list) and the third triggers the local exception. If we
change to code to have a "finally" clause you commit #1 and #2. But _not_ #5.
The client has to catch the exception, then somehow figure out which mutation
was faulty and where to continue. That is mayhem!
I suggest the following rather, for put(List) disable local checks! What that
means is we send it all mutations to the server and get a list back of those
that have failed, while the others all went through. This is assuming that the
majority of API users will have some sense to created proper put instances.
And that is what batch() apparently does, ie. no local checks. But the only
version that is approved is {{batch(final List actions, final
Object[] results)}} which needs to be translated into what put(List) is
supposed to do. How would we return the list of results or errors for that call?
BTW, this also applies to BufferedMutation.mutate(List). You still
need to figure out what went wrong client side, which will lead to cumbersome,
reinvented boilerplate code at many API users trying to handle lists of
mutations sensibly.
As for
bq. Wondering if BufferedMutaror should have a method to retrive the number of
mutations in buffer (writeAsyncBuffer.size() in current impl)?
I like the idea of having ways to figure out the status of the local buffer.
Right now it is very tightly guarded.
> Table#puts(List) operation is indeterminate; remove!
> -
>
> 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
>
> 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] [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=14368865#comment-14368865 ] Lars George commented on HBASE-13272: - +1 on what [~ndimiduk] suggests. We need to either fix it (it used to work), or document/deprecate/remove it. > 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] [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=14368871#comment-14368871 ] Nicolas Liochon commented on HBASE-13272: - I'm +1 for the suppression (I though I deprecated it already, may be I'm wrong or I missed some of the interfaces), but it needs to be done carefully: we need to keep it on the server/protobuf for a while as we want the old clients to be able to speak to the new servers. > 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] [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=14368872#comment-14368872 ] Nicolas Liochon commented on HBASE-13272: - On the other hand if it's broken it's not that useful to keep it :-) > 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] [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=14368881#comment-14368881
]
Lars George commented on HBASE-13273:
-
I do not think this is enough. You can still call {{addResults()}} (or
{{addStats()}} soon), and {{setExists()}}, modifying the EMPTY_RESULT.
What we really need is either the interface idea suggested by [~ndimiduk] or
some more coding to make a Result "read-only". I mean, we could have an package
local constructor that sets a {{boolean readonly}} to {{true}} and then all
setters respecting that. This will not break the signature and is better than
doing the {{copyfrom()}} kludge.
So I am -1 until convinced otherwise.
> 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
>
>
> 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-13274) Fix misplaced deprecation in Delete#addXYZ
[
https://issues.apache.org/jira/browse/HBASE-13274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368885#comment-14368885
]
Lars George commented on HBASE-13274:
-
+1
> 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
> 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-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=14368892#comment-14368892
]
Hadoop QA commented on HBASE-13241:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705545/HBASE-13241-v6.patch
against master branch at commit 535ebbfde9e424fab27f79bfa6b40964c4918fc6.
ATTACHMENT ID: 12705545
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color: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/13312//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13312//console
This message is automatically generated.
> 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
> Attachments: 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-13285) Fix flaky getRegions() in TestAccessController.setUp()
[
https://issues.apache.org/jira/browse/HBASE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368950#comment-14368950
]
Hadoop QA commented on HBASE-13285:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705548/HBASE-13285-v0.patch
against master branch at commit 535ebbfde9e424fab27f79bfa6b40964c4918fc6.
ATTACHMENT ID: 12705548
{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/13313//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13313//console
This message is automatically generated.
> Fix flaky getRegions() in TestAccessController.setUp()
> --
>
> Key: HBASE-13285
> URL: https://issues.apache.org/jira/browse/HBASE-13285
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 0.98.12
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-13285-v0.patch
>
>
> TestAccessController is waiting on table to be enabled and after that tries
> to lookup the region. but if the machine is slow, that region may not be
> assigned yet.
> {code}
> TEST_UTIL.waitTableEnabled(TEST_TABLE.getTableName());
> HRegion region =
> TEST_UTIL.getHBaseCluster().getRegions(TEST_TABLE.getTableName()).get(0);
> {code}
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.setUp(TestAccessController.java:235)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368969#comment-14368969
]
Hadoop QA commented on HBASE-13280:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705554/HBASE-13280.patch
against master branch at commit 535ebbfde9e424fab27f79bfa6b40964c4918fc6.
ATTACHMENT ID: 12705554
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 12 new
or modified tests.
{color:green}+1 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/13314//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13314//console
This message is automatically generated.
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util
[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=14368974#comment-14368974
]
Matteo Bertozzi commented on HBASE-13199:
-
looks like the commit introduced a new findbug error
{noformat}
Nullcheck of table at line 152 of value previously dereferenced in
org.apache.hadoop.hbase.tool.Canary$RegionTask.call()
Bug type RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE (click for details)
In class org.apache.hadoop.hbase.tool.Canary$RegionTask
In method org.apache.hadoop.hbase.tool.Canary$RegionTask.call()
Value loaded from table
Return value of org.apache.hadoop.hbase.client.Connection.getTable(TableName)
At Canary.java:[line 152]
Redundant null check at Canary.java:[line 207]
{noformat}
> 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-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-13188) java.lang.ArithmeticException issue in BoundedByteBufferPool.putBuffer
[
https://issues.apache.org/jira/browse/HBASE-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369261#comment-14369261
]
Nicolas Liochon commented on HBASE-13188:
-
[~saint@gmail.com] if you're interested, there is a ByteBufferPool in
HBASE-9535. If I understand well 9535 is now irrelevant (please close it if
it's the case), but may be there is some code to take there.
> java.lang.ArithmeticException issue in BoundedByteBufferPool.putBuffer
> --
>
> Key: HBASE-13188
> URL: https://issues.apache.org/jira/browse/HBASE-13188
> Project: HBase
> Issue Type: Bug
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13188.patch
>
>
> Running a range scan with PE tool with 25 threads getting this error
> {code}
> java.lang.ArithmeticException: / by zero
> at
> org.apache.hadoop.hbase.io.BoundedByteBufferPool.putBuffer(BoundedByteBufferPool.java:104)
> at org.apache.hadoop.hbase.ipc.RpcServer$Call.done(RpcServer.java:325)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1078)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processAllResponses(RpcServer.java:1103)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doAsyncWrite(RpcServer.java:1036)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRunLoop(RpcServer.java:956)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.run(RpcServer.java:891)
> {code}
> I checked in the trunk code also. I think the comment in the code suggests
> that the size will not be exact so there is a chance that it could be even 0.
--
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=14369266#comment-14369266 ] Liu Shaohui commented on HBASE-13199: - [~mbertozzi] Sorry for this, i will fix the error. > 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-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-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=14369290#comment-14369290
]
William Watson commented on HBASE-13275:
or to not being set at all
> 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-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=14369289#comment-14369289
]
William Watson commented on HBASE-13275:
I thought the docs said it defaults to false...
> 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-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369320#comment-14369320
]
zhangduo commented on HBASE-13280:
--
I think the findbugs warning is not my fault? I only modified test code.
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientI
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369327#comment-14369327
]
zhangduo commented on HBASE-13280:
--
Pushed to master and branch-1. Thanks [~liushaohui].
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
>
[jira] [Updated] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhangduo updated HBASE-13280:
-
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:609)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:154)
> at
> o
[jira] [Commented] (HBASE-13271) Table#puts(List) operation is indeterminate; remove!
[
https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369362#comment-14369362
]
Lars George commented on HBASE-13271:
-
Looking at delete(List) now, that does it proper. It is because
Delete's are immediate, same as Get's. The issue arises due to the client side
write buffer with put(List). I propose for just that function we do
exactly what delete(List) does, as put(List) also is flushing the buffer at the
end of the list as it is implemented now (API in 1.0.0). That keep both the
same, *and* keeps put(List) away from flushing the local write buffer.
In fact, it needs to be checked, maybe the entire local write buffer can be
removed as you either get an explicit one (BufferedMutator) or expect Table to
flush immediately anyways. Are we keeping this just for HTable users? It is
deprecated, so when we drop it, we could then at least remove the entire crud?
> Table#puts(List) operation is indeterminate; remove!
> -
>
> 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
>
> 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-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
Nicolas Liochon created HBASE-13286:
---
Summary: Minimum timeout for a rpc call could be 1 ms instead of 2
seconds
Key: HBASE-13286
URL: https://issues.apache.org/jira/browse/HBASE-13286
Project: HBase
Issue Type: Improvement
Components: Client
Affects Versions: 0.98.12, 1.0.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Priority: Minor
Fix For: 1.1.0
There is a check in the client to be sure that we don't use a timeout of zero
(i.e. infinite). This includes setting the minimal time out for a rpc timeout
to 2 seconds. However, it makes sense for some calls (typically gets going to
the cache) to have much lower timeouts. So it's better to do the check vs. zero
but with a minimal timeout of 0.
I fixed a typo & a wrong comment in this patch as well. I don't understand this
code:
{code}
// t could be a RemoteException so go around again.
translateException(t); // We don't use the result?
{code}
but may be it's good.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
[
https://issues.apache.org/jira/browse/HBASE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Liochon updated HBASE-13286:
Attachment: 13286.patch
> Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
> -
>
> Key: HBASE-13286
> URL: https://issues.apache.org/jira/browse/HBASE-13286
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.0.0, 0.98.12
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 13286.patch
>
>
> There is a check in the client to be sure that we don't use a timeout of zero
> (i.e. infinite). This includes setting the minimal time out for a rpc timeout
> to 2 seconds. However, it makes sense for some calls (typically gets going to
> the cache) to have much lower timeouts. So it's better to do the check vs.
> zero but with a minimal timeout of 0.
> I fixed a typo & a wrong comment in this patch as well. I don't understand
> this code:
> {code}
> // t could be a RemoteException so go around again.
> translateException(t); // We don't use the result?
> {code}
> but may be it's good.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
[
https://issues.apache.org/jira/browse/HBASE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Liochon updated HBASE-13286:
Status: Patch Available (was: Open)
> Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
> -
>
> Key: HBASE-13286
> URL: https://issues.apache.org/jira/browse/HBASE-13286
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.98.12, 1.0.0
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 13286.patch
>
>
> There is a check in the client to be sure that we don't use a timeout of zero
> (i.e. infinite). This includes setting the minimal time out for a rpc timeout
> to 2 seconds. However, it makes sense for some calls (typically gets going to
> the cache) to have much lower timeouts. So it's better to do the check vs.
> zero but with a minimal timeout of 0.
> I fixed a typo & a wrong comment in this patch as well. I don't understand
> this code:
> {code}
> // t could be a RemoteException so go around again.
> translateException(t); // We don't use the result?
> {code}
> but may be it's good.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
[
https://issues.apache.org/jira/browse/HBASE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369381#comment-14369381
]
Ted Yu commented on HBASE-13286:
lgtm
> Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
> -
>
> Key: HBASE-13286
> URL: https://issues.apache.org/jira/browse/HBASE-13286
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.0.0, 0.98.12
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 13286.patch
>
>
> There is a check in the client to be sure that we don't use a timeout of zero
> (i.e. infinite). This includes setting the minimal time out for a rpc timeout
> to 2 seconds. However, it makes sense for some calls (typically gets going to
> the cache) to have much lower timeouts. So it's better to do the check vs.
> zero but with a minimal timeout of 0.
> I fixed a typo & a wrong comment in this patch as well. I don't understand
> this code:
> {code}
> // t could be a RemoteException so go around again.
> translateException(t); // We don't use the result?
> {code}
> but may be it's good.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
[
https://issues.apache.org/jira/browse/HBASE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Liochon updated HBASE-13286:
Description:
There is a check in the client to be sure that we don't use a timeout of zero
(i.e. infinite). This includes setting the minimal time out for a rpc timeout
to 2 seconds. However, it makes sense for some calls (typically gets going to
the cache) to have much lower timeouts. So it's better to do the check vs. zero
but with a minimal timeout of 1.
I fixed a typo & a wrong comment in this patch as well. I don't understand this
code:
{code}
// t could be a RemoteException so go around again.
translateException(t); // We don't use the result?
{code}
but may be it's good.
was:
There is a check in the client to be sure that we don't use a timeout of zero
(i.e. infinite). This includes setting the minimal time out for a rpc timeout
to 2 seconds. However, it makes sense for some calls (typically gets going to
the cache) to have much lower timeouts. So it's better to do the check vs. zero
but with a minimal timeout of 0.
I fixed a typo & a wrong comment in this patch as well. I don't understand this
code:
{code}
// t could be a RemoteException so go around again.
translateException(t); // We don't use the result?
{code}
but may be it's good.
> Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
> -
>
> Key: HBASE-13286
> URL: https://issues.apache.org/jira/browse/HBASE-13286
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.0.0, 0.98.12
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 13286.patch
>
>
> There is a check in the client to be sure that we don't use a timeout of zero
> (i.e. infinite). This includes setting the minimal time out for a rpc timeout
> to 2 seconds. However, it makes sense for some calls (typically gets going to
> the cache) to have much lower timeouts. So it's better to do the check vs.
> zero but with a minimal timeout of 1.
> I fixed a typo & a wrong comment in this patch as well. I don't understand
> this code:
> {code}
> // t could be a RemoteException so go around again.
> translateException(t); // We don't use the result?
> {code}
> but may be it's good.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
[
https://issues.apache.org/jira/browse/HBASE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369451#comment-14369451
]
Nicolas Liochon commented on HBASE-13286:
-
Thanks Ted, let see what hadoop-qa says, I hope I won't discover an ocean of
race conditions here :-).
> Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
> -
>
> Key: HBASE-13286
> URL: https://issues.apache.org/jira/browse/HBASE-13286
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.0.0, 0.98.12
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 13286.patch
>
>
> There is a check in the client to be sure that we don't use a timeout of zero
> (i.e. infinite). This includes setting the minimal time out for a rpc timeout
> to 2 seconds. However, it makes sense for some calls (typically gets going to
> the cache) to have much lower timeouts. So it's better to do the check vs.
> zero but with a minimal timeout of 1.
> I fixed a typo & a wrong comment in this patch as well. I don't understand
> this code:
> {code}
> // t could be a RemoteException so go around again.
> translateException(t); // We don't use the result?
> {code}
> but may be it's good.
--
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:
Summary: Table#puts(List) operation is indeterminate; needs fixing
(was: Table#puts(List) operation is indeterminate; remove!)
> 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
>Assignee: Lars George
>
> 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] [Assigned] (HBASE-13271) Table#puts(List) operation is indeterminate; remove!
[
https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars George reassigned HBASE-13271:
---
Assignee: Lars George
> Table#puts(List) operation is indeterminate; remove!
> -
>
> 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
>Assignee: Lars George
>
> 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-13287) Append is missing methods, such as addColumn()
Lars George created HBASE-13287:
---
Summary: Append is missing methods, such as addColumn()
Key: HBASE-13287
URL: https://issues.apache.org/jira/browse/HBASE-13287
Project: HBase
Issue Type: Bug
Components: API
Affects Versions: 1.0.0
Reporter: Lars George
Analog to Put, Delete, Get, etc. Append should have the same common method
signature, namely {{addColumn()}} as opposed to the older {{add()}}. Also
consider adding the other variant that Put has, including the _immutable_
versions.
Question related: should those methods not better be in the Mutation class? All
derived classes implement them. {{setTTL()}} is in Mutation, and throws an
exception when used with {{Delete}}. So why not moved those down too? (cc
[~saint@gmail.com])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13288) Fix naming of parameter in Delete constructor
Lars George created HBASE-13288:
---
Summary: Fix naming of parameter in Delete constructor
Key: HBASE-13288
URL: https://issues.apache.org/jira/browse/HBASE-13288
Project: HBase
Issue Type: Bug
Components: API
Affects Versions: 1.0.0
Reporter: Lars George
We have these two variants:
{code}
Delete(byte[] row, long timestamp)
Delete(final byte[] rowArray, final int rowOffset, final int rowLength, long ts)
{code}
Both should use {{timestamp}} as the parameter name, not this mix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369565#comment-14369565
]
Hudson commented on HBASE-13280:
SUCCESS: Integrated in HBase-TRUNK #6279 (See
[https://builds.apache.org/job/HBase-TRUNK/6279/])
HBASE-13280 TestSecureRPC failed (zhangduo: rev
27cf749af884edae55454c885c7fb066f0a33c79)
* hbase-server/src/test/java/org/apache/hadoop/hbase/security/TestSecureRPC.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/security/TestUsersOperationsWithSecureHadoop.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/security/token/TestGenerateDelegationToken.java
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
>
[jira] [Commented] (HBASE-13289) typo in splitSuccessCount metric
[
https://issues.apache.org/jira/browse/HBASE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369581#comment-14369581
]
Jonathan Hsieh commented on HBASE-13289:
do folks want a fix or should we go through a deprecation thing for this?
> typo in splitSuccessCount metric
> -
>
> Key: HBASE-13289
> URL: https://issues.apache.org/jira/browse/HBASE-13289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0, 2.0.0, 1.1.0
>Reporter: Jonathan Hsieh
>
> Our split metrics have a misspelled Count and it shows up in our jmx metrics
> {code}
> "splitSuccessCounnt" : 0,
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13289) typo in splitSuccessCount metric
Jonathan Hsieh created HBASE-13289:
--
Summary: typo in splitSuccessCount metric
Key: HBASE-13289
URL: https://issues.apache.org/jira/browse/HBASE-13289
Project: HBase
Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 1.1.0
Reporter: Jonathan Hsieh
Our split metrics have a misspelled Count and it shows up in our jmx metrics
{code}
"splitSuccessCounnt" : 0,
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13289) typo in splitSuccessCount metric
[
https://issues.apache.org/jira/browse/HBASE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-13289:
---
Status: Patch Available (was: Open)
> typo in splitSuccessCount metric
> -
>
> Key: HBASE-13289
> URL: https://issues.apache.org/jira/browse/HBASE-13289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0, 2.0.0, 1.1.0
>Reporter: Jonathan Hsieh
> Attachments: hbase-13289.patch
>
>
> Our split metrics have a misspelled Count and it shows up in our jmx metrics
> {code}
> "splitSuccessCounnt" : 0,
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-13289) typo in splitSuccessCount metric
[
https://issues.apache.org/jira/browse/HBASE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh reassigned HBASE-13289:
--
Assignee: Jonathan Hsieh
> typo in splitSuccessCount metric
> -
>
> Key: HBASE-13289
> URL: https://issues.apache.org/jira/browse/HBASE-13289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0, 2.0.0, 1.1.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-13289.patch
>
>
> Our split metrics have a misspelled Count and it shows up in our jmx metrics
> {code}
> "splitSuccessCounnt" : 0,
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13289) typo in splitSuccessCount metric
[
https://issues.apache.org/jira/browse/HBASE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-13289:
---
Attachment: hbase-13289.patch
fix patch attached
> typo in splitSuccessCount metric
> -
>
> Key: HBASE-13289
> URL: https://issues.apache.org/jira/browse/HBASE-13289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0, 2.0.0, 1.1.0
>Reporter: Jonathan Hsieh
> Attachments: hbase-13289.patch
>
>
> Our split metrics have a misspelled Count and it shows up in our jmx metrics
> {code}
> "splitSuccessCounnt" : 0,
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13289) typo in splitSuccessCount metric
[
https://issues.apache.org/jira/browse/HBASE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-13289:
---
Affects Version/s: 0.98.0
> typo in splitSuccessCount metric
> -
>
> Key: HBASE-13289
> URL: https://issues.apache.org/jira/browse/HBASE-13289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 1.0.0, 2.0.0, 1.1.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-13289.patch
>
>
> Our split metrics have a misspelled Count and it shows up in our jmx metrics
> {code}
> "splitSuccessCounnt" : 0,
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13280) TestSecureRPC failed
[
https://issues.apache.org/jira/browse/HBASE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369600#comment-14369600
]
Hudson commented on HBASE-13280:
SUCCESS: Integrated in HBase-1.1 #303 (See
[https://builds.apache.org/job/HBase-1.1/303/])
HBASE-13280 TestSecureRPC failed (zhangduo: rev
9e92e33629127169dfe869c5beedfc24d5953f72)
*
hbase-server/src/test/java/org/apache/hadoop/hbase/security/token/TestGenerateDelegationToken.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/security/TestSecureRPC.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/security/TestUsersOperationsWithSecureHadoop.java
> TestSecureRPC failed
>
>
> Key: HBASE-13280
> URL: https://issues.apache.org/jira/browse/HBASE-13280
> Project: HBase
> Issue Type: Test
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Liu Shaohui
>Assignee: zhangduo
>Priority: Minor
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13280.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.security.TestSecureRPC
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 33.795 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.security.TestSecureRPC
> testRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed: 14.963
> sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpc(TestSecureRPC.java:102)
> testAsyncRpc(org.apache.hadoop.hbase.security.TestSecureRPC) Time elapsed:
> 5.15 sec <<< ERROR!
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:635)
> at java.util.ArrayList.get(ArrayList.java:411)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testRpcCallWithEnabledKerberosSaslAuth(TestSecureRPC.java:160)
> at
> org.apache.hadoop.hbase.security.TestSecureRPC.testAsyncRpc(TestSecureRPC.java:107)
> {code}
> From log we saw that:
> {code}
> 2015-03-19 11:27:02,271 WARN [Thread-5] ipc.RpcClientImpl$Connection$1(662):
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> Exception in thread "Thread-5" java.lang.RuntimeException:
> com.google.protobuf.ServiceException: java.io.IOException: Couldn't setup
> connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:275)
> Caused by: com.google.protobuf.ServiceException: java.io.IOException:
> Couldn't setup connection for hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:223)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.ipc.protobuf.generated.TestDelayedRpcProtos$TestDelayedService$BlockingStub.test(TestDelayedRpcProtos.java:1115)
> at
> org.apache.hadoop.hbase.ipc.TestDelayedRpc$TestThread.run(TestDelayedRpc.java:272)
> Caused by: java.io.IOException: Couldn't setup connection for
> hbase/liushaohui-optiplex-...@example.com to
> hbase/liushaohui-optiplex-...@example.com
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:663)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1614)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.handleSaslConnectionFailure(RpcClientImpl.java:635)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:885)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:854)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1170)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> ... 3 more
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
[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=14369640#comment-14369640 ] Ashish Singhi commented on HBASE-13241: --- Findbug warning is not related to this patch and will be fixed as part of HBASE-13199 > 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 > Attachments: 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-7055) port HBASE-6371 tier-based compaction from 0.89-fb to trunk (with changes)
[ https://issues.apache.org/jira/browse/HBASE-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369643#comment-14369643 ] Dave Latham commented on HBASE-7055: We have a case where we are very interested in using it - a table where we do regular scans of recent data, and occasional scans of all the data. We're going to evaluate this patch. Could it still be considered for inclusion into HBase? > port HBASE-6371 tier-based compaction from 0.89-fb to trunk (with changes) > -- > > Key: HBASE-7055 > URL: https://issues.apache.org/jira/browse/HBASE-7055 > Project: HBase > Issue Type: Task > Components: Compaction >Affects Versions: 0.95.2 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-6371-squashed.patch, HBASE-6371-v2-squashed.patch, > HBASE-6371-v3-refactor-only-squashed.patch, > HBASE-6371-v4-refactor-only-squashed.patch, > HBASE-6371-v5-refactor-only-squashed.patch, HBASE-7055-v0.patch, > HBASE-7055-v1.patch, HBASE-7055-v2.patch, HBASE-7055-v3.patch, > HBASE-7055-v4.patch, HBASE-7055-v5.patch, HBASE-7055-v6.patch, > HBASE-7055-v7.patch, HBASE-7055-v7.patch, Tier Based Compaction Settings.pdf > > > See HBASE-6371 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-13288) Fix naming of parameter in Delete constructor
[
https://issues.apache.org/jira/browse/HBASE-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi reassigned HBASE-13288:
-
Assignee: Ashish Singhi
> Fix naming of parameter in Delete constructor
> -
>
> Key: HBASE-13288
> URL: https://issues.apache.org/jira/browse/HBASE-13288
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Ashish Singhi
> Labels: noob
>
> We have these two variants:
> {code}
> Delete(byte[] row, long timestamp)
> Delete(final byte[] rowArray, final int rowOffset, final int rowLength, long
> ts)
> {code}
> Both should use {{timestamp}} as the parameter name, not this mix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13288) Fix naming of parameter in Delete constructor
[
https://issues.apache.org/jira/browse/HBASE-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi updated HBASE-13288:
--
Attachment: HBASE-13288.patch
> Fix naming of parameter in Delete constructor
> -
>
> Key: HBASE-13288
> URL: https://issues.apache.org/jira/browse/HBASE-13288
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Ashish Singhi
> Labels: noob
> Attachments: HBASE-13288.patch
>
>
> We have these two variants:
> {code}
> Delete(byte[] row, long timestamp)
> Delete(final byte[] rowArray, final int rowOffset, final int rowLength, long
> ts)
> {code}
> Both should use {{timestamp}} as the parameter name, not this mix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13288) Fix naming of parameter in Delete constructor
[
https://issues.apache.org/jira/browse/HBASE-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi updated HBASE-13288:
--
Status: Patch Available (was: Open)
> Fix naming of parameter in Delete constructor
> -
>
> Key: HBASE-13288
> URL: https://issues.apache.org/jira/browse/HBASE-13288
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Ashish Singhi
> Labels: noob
> Attachments: HBASE-13288.patch
>
>
> We have these two variants:
> {code}
> Delete(byte[] row, long timestamp)
> Delete(final byte[] rowArray, final int rowOffset, final int rowLength, long
> ts)
> {code}
> Both should use {{timestamp}} as the parameter name, not this mix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13288) Fix naming of parameter in Delete constructor
[
https://issues.apache.org/jira/browse/HBASE-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi updated HBASE-13288:
--
Priority: Trivial (was: Major)
> Fix naming of parameter in Delete constructor
> -
>
> Key: HBASE-13288
> URL: https://issues.apache.org/jira/browse/HBASE-13288
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Ashish Singhi
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-13288.patch
>
>
> We have these two variants:
> {code}
> Delete(byte[] row, long timestamp)
> Delete(final byte[] rowArray, final int rowOffset, final int rowLength, long
> ts)
> {code}
> Both should use {{timestamp}} as the parameter name, not this mix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13288) Fix naming of parameter in Delete constructor
[
https://issues.apache.org/jira/browse/HBASE-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369654#comment-14369654
]
Ashish Singhi commented on HBASE-13288:
---
Along with timestamp handled the same for row vs rowArray.
Changed priority to Trivial. If you feel otherwise change it back.
Please review.
> Fix naming of parameter in Delete constructor
> -
>
> Key: HBASE-13288
> URL: https://issues.apache.org/jira/browse/HBASE-13288
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Ashish Singhi
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-13288.patch
>
>
> We have these two variants:
> {code}
> Delete(byte[] row, long timestamp)
> Delete(final byte[] rowArray, final int rowOffset, final int rowLength, long
> ts)
> {code}
> Both should use {{timestamp}} as the parameter name, not this mix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
[
https://issues.apache.org/jira/browse/HBASE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369659#comment-14369659
]
Hadoop QA commented on HBASE-13286:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12705602/13286.patch
against master branch at commit 27cf749af884edae55454c885c7fb066f0a33c79.
ATTACHMENT ID: 12705602
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color: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 .
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at org.apache.oozie.test.MiniHCatServer$1.run(MiniHCatServer.java:137)
at
org.apache.oozie.test.XTestCase$MiniClusterShutdownMonitor.run(XTestCase.java:1071)
at org.apache.oozie.test.XTestCase.waitFor(XTestCase.java:692)
at
org.apache.oozie.action.hadoop.TestDistCpActionExecutor.testDistCpFile(TestDistCpActionExecutor.java:66)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13316//console
This message is automatically generated.
> Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
> -
>
> Key: HBASE-13286
> URL: https://issues.apache.org/jira/browse/HBASE-13286
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.0.0, 0.98.12
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 13286.patch
>
>
> There is a check in the client to be sure that we don't use a timeout of zero
> (i.e. infinite). This includes setting the minimal t
[jira] [Commented] (HBASE-7055) port HBASE-6371 tier-based compaction from 0.89-fb to trunk (with changes)
[ https://issues.apache.org/jira/browse/HBASE-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369658#comment-14369658 ] Nick Dimiduk commented on HBASE-7055: - bq. Could it still be considered for inclusion into HBase? I see no reason why not. It was only closed because it lost a champion. > port HBASE-6371 tier-based compaction from 0.89-fb to trunk (with changes) > -- > > Key: HBASE-7055 > URL: https://issues.apache.org/jira/browse/HBASE-7055 > Project: HBase > Issue Type: Task > Components: Compaction >Affects Versions: 0.95.2 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-6371-squashed.patch, HBASE-6371-v2-squashed.patch, > HBASE-6371-v3-refactor-only-squashed.patch, > HBASE-6371-v4-refactor-only-squashed.patch, > HBASE-6371-v5-refactor-only-squashed.patch, HBASE-7055-v0.patch, > HBASE-7055-v1.patch, HBASE-7055-v2.patch, HBASE-7055-v3.patch, > HBASE-7055-v4.patch, HBASE-7055-v5.patch, HBASE-7055-v6.patch, > HBASE-7055-v7.patch, HBASE-7055-v7.patch, Tier Based Compaction Settings.pdf > > > See HBASE-6371 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13290) Procedure v2 - client enable/disable table sync
Stephen Yuan Jiang created HBASE-13290: -- Summary: Procedure v2 - client enable/disable table sync Key: HBASE-13290 URL: https://issues.apache.org/jira/browse/HBASE-13290 Project: HBase Issue Type: Sub-task Components: Client Affects Versions: 2.0.0, 1.1.0 Reporter: Stephen Yuan Jiang Assignee: Stephen Yuan Jiang client side, part of HBASE-12439/HBASE-13211 it uses the new procedure code to be know when the procedure is completed, and have a proper sync/async behavior on enable/disable table. For 1.1, It has to be binary compatible (1.0 client can talk to 1.1 server && 1.1 client can talk to 1.0 server). Binary compatible is TBD for 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (HBASE-13290) Procedure v2 - client enable/disable table sync
[ https://issues.apache.org/jira/browse/HBASE-13290?focusedWorklogId=19468&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-19468 ] Stephen Yuan Jiang logged work on HBASE-13290: -- Author: Stephen Yuan Jiang Created on: 19/Mar/15 16:57 Start Date: 19/Mar/15 16:54 Worklog Time Spent: 48h Issue Time Tracking --- Worklog Id: (was: 19468) Time Spent: 48h Remaining Estimate: 72h (was: 120h) > Procedure v2 - client enable/disable table sync > --- > > Key: HBASE-13290 > URL: https://issues.apache.org/jira/browse/HBASE-13290 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0, 1.1.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > Attachments: EnableDisableTableClientPV2-draft.v0-master.patch > > Original Estimate: 120h > Time Spent: 48h > Remaining Estimate: 72h > > client side, part of HBASE-12439/HBASE-13211 > it uses the new procedure code to be know when the procedure is completed, > and have a proper sync/async behavior on enable/disable table. > For 1.1, It has to be binary compatible (1.0 client can talk to 1.1 server && > 1.1 client can talk to 1.0 server). Binary compatible is TBD for 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13290) Procedure v2 - client enable/disable table sync
[ https://issues.apache.org/jira/browse/HBASE-13290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-13290: --- Attachment: EnableDisableTableClientPV2-draft.v0-master.patch > Procedure v2 - client enable/disable table sync > --- > > Key: HBASE-13290 > URL: https://issues.apache.org/jira/browse/HBASE-13290 > Project: HBase > Issue Type: Sub-task > Components: Client >Affects Versions: 2.0.0, 1.1.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > Attachments: EnableDisableTableClientPV2-draft.v0-master.patch > > Original Estimate: 120h > Time Spent: 48h > Remaining Estimate: 72h > > client side, part of HBASE-12439/HBASE-13211 > it uses the new procedure code to be know when the procedure is completed, > and have a proper sync/async behavior on enable/disable table. > For 1.1, It has to be binary compatible (1.0 client can talk to 1.1 server && > 1.1 client can talk to 1.0 server). Binary compatible is TBD for 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13211) Procedure V2 - master Enable/Disable table
[ https://issues.apache.org/jira/browse/HBASE-13211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-13211: --- Attachment: EnableDisableTableServerPV2-draft.v0-master.patch > Procedure V2 - master Enable/Disable table > -- > > Key: HBASE-13211 > URL: https://issues.apache.org/jira/browse/HBASE-13211 > Project: HBase > Issue Type: Sub-task > Components: master >Affects Versions: 2.0.0, 1.1.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > Labels: reliability > Attachments: EnableDisableTableServerPV2-draft.v0-master.patch > > > master side, part of HBASE-12439 > starts up the procedure executor on the master > and replaces the enable/disable table handlers with the procedure version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13211) Procedure V2 - master Enable/Disable table
[ https://issues.apache.org/jira/browse/HBASE-13211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-13211: --- Remaining Estimate: 120h Original Estimate: 120h > Procedure V2 - master Enable/Disable table > -- > > Key: HBASE-13211 > URL: https://issues.apache.org/jira/browse/HBASE-13211 > Project: HBase > Issue Type: Sub-task > Components: master >Affects Versions: 2.0.0, 1.1.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > Labels: reliability > Attachments: EnableDisableTableServerPV2-draft.v0-master.patch > > Original Estimate: 120h > Remaining Estimate: 120h > > master side, part of HBASE-12439 > starts up the procedure executor on the master > and replaces the enable/disable table handlers with the procedure version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13211) Procedure V2 - master Enable/Disable table
[ https://issues.apache.org/jira/browse/HBASE-13211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-13211: --- Attachment: (was: EnableDisableTablePV2-draft.v0-master.patch) > Procedure V2 - master Enable/Disable table > -- > > Key: HBASE-13211 > URL: https://issues.apache.org/jira/browse/HBASE-13211 > Project: HBase > Issue Type: Sub-task > Components: master >Affects Versions: 2.0.0, 1.1.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > Labels: reliability > Attachments: EnableDisableTableServerPV2-draft.v0-master.patch > > > master side, part of HBASE-12439 > starts up the procedure executor on the master > and replaces the enable/disable table handlers with the procedure version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (HBASE-13211) Procedure V2 - master Enable/Disable table
[ https://issues.apache.org/jira/browse/HBASE-13211?focusedWorklogId=19469&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-19469 ] Stephen Yuan Jiang logged work on HBASE-13211: -- Author: Stephen Yuan Jiang Created on: 19/Mar/15 17:00 Start Date: 19/Mar/15 17:00 Worklog Time Spent: 48h Issue Time Tracking --- Worklog Id: (was: 19469) Time Spent: 48h Remaining Estimate: 72h (was: 120h) > Procedure V2 - master Enable/Disable table > -- > > Key: HBASE-13211 > URL: https://issues.apache.org/jira/browse/HBASE-13211 > Project: HBase > Issue Type: Sub-task > Components: master >Affects Versions: 2.0.0, 1.1.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > Labels: reliability > Attachments: EnableDisableTableServerPV2-draft.v0-master.patch > > Original Estimate: 120h > Time Spent: 48h > Remaining Estimate: 72h > > master side, part of HBASE-12439 > starts up the procedure executor on the master > and replaces the enable/disable table handlers with the procedure version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13187) Add ITBLL that exercises per CF flush
[ https://issues.apache.org/jira/browse/HBASE-13187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369705#comment-14369705 ] stack commented on HBASE-13187: --- bq. but I suggest to generate tiny and big value based on rowkey(or some other values in the row) so that we can also verify whether the data of tiny and big family are also correct? Would there be any value doing this extra work? The test just ensures referential integrity between rows no matter what the cluster perturbation. The patch adds a new 'agitation' making it very likely column families will flush independently (when flush-columnfamily is enabled). Having the middle 'meta' column family for checking referenced row is still present is sufficient? Having 'big' and 'tiny' columns do it independently adds no extra insurance (that I can see). Maybe we could have 'big' and 'tiny' column families reference other rows altogether making a sort of mesh of references but if it is row-based references that we are checking, I just see us doing extra footwork to no benefit. A cool 'new' test would do up this mesh-of-references but the references would be between cells rather than rows. Your comment does prompt me to add to the verification step a check that the big and tiny are present on every row. Thanks [~Apache9] > Add ITBLL that exercises per CF flush > - > > Key: HBASE-13187 > URL: https://issues.apache.org/jira/browse/HBASE-13187 > Project: HBase > Issue Type: Task > Components: integration tests >Reporter: stack >Assignee: stack >Priority: Critical > Fix For: 2.0.0, 1.1.0 > > Attachments: 13187.txt > > > Let me work on this. It would be excellent if we could have confidence to > turn this on earlier rather than later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13286) Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
[
https://issues.apache.org/jira/browse/HBASE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369715#comment-14369715
]
stack commented on HBASE-13286:
---
+1
Why remove MIN_RPC_TIMEOUT though? Why not just set it to 1 instead of 2000?
Good catch.
> Minimum timeout for a rpc call could be 1 ms instead of 2 seconds
> -
>
> Key: HBASE-13286
> URL: https://issues.apache.org/jira/browse/HBASE-13286
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 1.0.0, 0.98.12
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 13286.patch
>
>
> There is a check in the client to be sure that we don't use a timeout of zero
> (i.e. infinite). This includes setting the minimal time out for a rpc timeout
> to 2 seconds. However, it makes sense for some calls (typically gets going to
> the cache) to have much lower timeouts. So it's better to do the check vs.
> zero but with a minimal timeout of 1.
> I fixed a typo & a wrong comment in this patch as well. I don't understand
> this code:
> {code}
> // t could be a RemoteException so go around again.
> translateException(t); // We don't use the result?
> {code}
> but may be it's good.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
