[jira] [Commented] (HBASE-13348) Separate the thread number configs for meta server and server operations
[
https://issues.apache.org/jira/browse/HBASE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386088#comment-14386088
]
Liu Shaohui commented on HBASE-13348:
-
[~stack] [~apurtell] [~lhofhansl]
Any suggestion about this small patch? Thanks~
Separate the thread number configs for meta server and server operations
Key: HBASE-13348
URL: https://issues.apache.org/jira/browse/HBASE-13348
Project: HBase
Issue Type: Improvement
Components: master
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
Fix For: 2.0.0
Attachments: HBASE-13348-v1.diff
Currently, the config keys for thread number of meta server and server
operations in HMaster are same:
See: HMaster.java #993
{code}
this.service.startExecutorService(ExecutorType.MASTER_SERVER_OPERATIONS,
conf.getInt(hbase.master.executor.serverops.threads, 5));
this.service.startExecutorService(ExecutorType.MASTER_META_SERVER_OPERATIONS,
conf.getInt(hbase.master.executor.serverops.threads, 5));
{code}
In large cluster, we usually enlarge the thread number for server operation
separately to make the master handle regionserver shutdown events quickly
in some extremely cases.
So I think we need separate the thread number config for the two operations.
Suggestions are welcomed. Thanks~
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12547) Adopt server side cleanup for bulk load staging directories
[ https://issues.apache.org/jira/browse/HBASE-12547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-12547: --- Labels: bulkloader (was: ) Adopt server side cleanup for bulk load staging directories --- Key: HBASE-12547 URL: https://issues.apache.org/jira/browse/HBASE-12547 Project: HBase Issue Type: Improvement Reporter: Ted Yu Labels: bulkloader Currently we rely on the client to send the clean up request for bulk load staging directories. In discussion of HBASE-12533, Enis and I raised similar comment about cleaning up bulk load staging directories from server side. We can keep lease on staging directory for bulk load operation. The default lease period should be long enough. After the lease expires, the underlying staging directory would be cleaned. This increases the robustness of bulk load process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386123#comment-14386123 ] Srikanth Srungarapu commented on HBASE-13296: - bq. just curious, why did you change the sequence of put() in setup() with a since batch-put? besides making the code compact, I thought all that unnecessary naming overhead(as the puts are being used elsewhere) could be avoided by using anonymous objects. Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch, HBASE-13296_v3.patch, HBASE-13296_v3.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13356) HBase should provide an InputFormat supporting multiple scans in mapreduce jobs over snapshots
[
https://issues.apache.org/jira/browse/HBASE-13356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386231#comment-14386231
]
Andrew Mains commented on HBASE-13356:
--
Spent some time speccing out a potential implementation for this today:
Interface:
Jobs wanting to run multiple scans over snapshots can use
MultiTableSnapshotInputFormat. This can be configured using TableMapreduceUtil,
as usual, with the signature:
{code}
/**
* Sets up the job for reading from one or more multiple table snapshots,
with one or more scan per snapshot.
* It bypasses hbase servers and read directly from snapshot files.
*
* @param snapshotScans map of snapshot name to a list of scans on that
snapshot.
* @param mapper The mapper class to use.
* @param outputKeyClass The class of the output key.
* @param outputValueClass The class of the output value.
* @param job The current job to adjust. Make sure the passed job is
* carrying all necessary HBase configuration.
* @param addDependencyJars upload HBase jars and jars for any of the
configured
* job classes via the distributed cache (tmpjars).
*/
public static void initMultiTableSnapshotMapperJob(MapString,
CollectionScan snapshotScans,
Class? extends
TableMapper mapper,
Class? outputKeyClass,
Class? outputValueClass,
Job job,
boolean addDependencyJars,
Path tmpRestoreDir
) throws IOException {
{code}
Implementation:
Most of the work can be done through delegation to
TableSnapshotInputFormatImpl. The primary change would be to make
TableSnapshotInputFormatImpl.InputSplit take in a scan object and restoreDir
path, instead of retrieving these from the job configuration. This would allow
MultiTableSnapshotInputFormat to avoid setting an individual scan and restore
directory on the configuration (they can be passed along by way of the split,
similar to TableSplit).
Tests:
Any implementation should probably pass at least the tests for
MultiTableInputFormat, and possibly some of the tests for
TableSnapshotInputFormat as well.
Thoughts?
HBase should provide an InputFormat supporting multiple scans in mapreduce
jobs over snapshots
--
Key: HBASE-13356
URL: https://issues.apache.org/jira/browse/HBASE-13356
Project: HBase
Issue Type: New Feature
Components: mapreduce
Reporter: Andrew Mains
Priority: Minor
Currently, HBase supports the pushing of multiple scans to mapreduce jobs
over live tables (via MultiTableInputFormat) but only supports a single scan
for mapreduce jobs over table snapshots. It would be handy to support
multiple scans over snapshots as well, probably through another input format
(MultiTableSnapshotInputFormat?). To mimic the functionality present in
MultiTableInputFormat, the new input format would likely have to take in the
names of all snapshots used in addition to the scans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13359) Updata ACL matrix to include table owner.
Srikanth Srungarapu created HBASE-13359: --- Summary: Updata ACL matrix to include table owner. Key: HBASE-13359 URL: https://issues.apache.org/jira/browse/HBASE-13359 Project: HBase Issue Type: Improvement Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Looks like we allow table owner to truncate and modify table. We should update ACL matrix to reflect this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13358) Upgrade VisibilityClient API to accept Connection object.
[
https://issues.apache.org/jira/browse/HBASE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385652#comment-14385652
]
Srikanth Srungarapu commented on HBASE-13358:
-
Leaving this open just in case if we've volunteers. Else, I'll pick this up
once I get time.
Upgrade VisibilityClient API to accept Connection object.
-
Key: HBASE-13358
URL: https://issues.apache.org/jira/browse/HBASE-13358
Project: HBase
Issue Type: Improvement
Reporter: Srikanth Srungarapu
Priority: Minor
From VisibilityClient class:
{code}
// TODO: Make it so caller passes in a Connection rather than have us do
this expensive
// setup each time. This class only used in test and shell at moment
though.
{code}
Basically, this is the VC's counterpart of HBASE-13171.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13358) Upgrade VisibilityClient API to accept Connection object.
Srikanth Srungarapu created HBASE-13358:
---
Summary: Upgrade VisibilityClient API to accept Connection object.
Key: HBASE-13358
URL: https://issues.apache.org/jira/browse/HBASE-13358
Project: HBase
Issue Type: Improvement
Reporter: Srikanth Srungarapu
Priority: Minor
From VisibilityClient class:
{code}
// TODO: Make it so caller passes in a Connection rather than have us do this
expensive
// setup each time. This class only used in test and shell at moment
though.
{code}
Basically, this is the VC's counterpart of HBASE-13171.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12993) Use HBase 1.0 interfaces in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385649#comment-14385649
]
Hadoop QA commented on HBASE-12993:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12708022/HBASE-12993-1.patch
against master branch at commit ced0e324a190e75d8a93b8b09676781853819361.
ATTACHMENT ID: 12708022
{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 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13481//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13481//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13481//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13481//console
This message is automatically generated.
Use HBase 1.0 interfaces in hbase-thrift
Key: HBASE-12993
URL: https://issues.apache.org/jira/browse/HBASE-12993
Project: HBase
Issue Type: Bug
Reporter: Solomon Duskis
Assignee: Solomon Duskis
Fix For: 2.0.0, 1.0.1
Attachments: HBASE-12993-1.patch, HBASE-12993.patch
hbase-thrift uses HTable and HBaesAdmin. It also uses HTablePool, which is
an outdated concept.
As per [~ndimiduk] on the user group:
{quote}
I believe HTablePool is completely eclipsed by the modern Connection
implementation. We'll need to keep the map of UserName = Connection (or
maybe the ConnectionCache handles this?) Probably a single Connection (per
user) with a large thread pool will do the trick.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13357) If maxTables/maxRegions exceeds quota in a namespace, throw QuotaExceededException
[ https://issues.apache.org/jira/browse/HBASE-13357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385644#comment-14385644 ] Srikanth Srungarapu commented on HBASE-13357: - My bad. Overlooked the clean up portion. But please bear in mind that tearDown() is mainly in place for rolling back on things we've created during setUp(). The general rule of thumb is if you are creating something during test, you should also delete it towards the end of it. I guess we can let this one pass. It's your call though! If maxTables/maxRegions exceeds quota in a namespace, throw QuotaExceededException -- Key: HBASE-13357 URL: https://issues.apache.org/jira/browse/HBASE-13357 Project: HBase Issue Type: Bug Affects Versions: 2.0.0 Reporter: Ashish Singhi Assignee: Ashish Singhi Priority: Minor Labels: quota Fix For: 2.0.0 Attachments: HBASE-13357.patch If maximum number of tables or regions count exceeds in a namespace we are throwing DoNotRetryIOException instead we should throw QuotaExceededException. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13317) Region server reportForDuty stuck looping if there is a master change
[
https://issues.apache.org/jira/browse/HBASE-13317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385646#comment-14385646
]
Jerry He commented on HBASE-13317:
--
The checking seems to be used to guide if someone else has changed rssStub.in
the middle, e.g by refreshing to a new connection.
In that case, we don't want to reset it to null.
Region server reportForDuty stuck looping if there is a master change
-
Key: HBASE-13317
URL: https://issues.apache.org/jira/browse/HBASE-13317
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 1.0.0, 2.0.0, 0.98.12
Reporter: Jerry He
Assignee: Jerry He
Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
Attachments: HBASE-13317-0.98-v2.patch, HBASE-13317-0.98-v3.patch,
HBASE-13317-0.98-v4.patch, HBASE-13317-0.98-v5.patch, HBASE-13317-0.98.patch,
HBASE-13317-master-v5.patch
During cluster startup, region server reportForDuty gets stuck looping if
there is a master change.
{noformat}
2015-03-22 11:15:16,186 INFO [regionserver60020] regionserver.HRegionServer:
reportForDuty to master=bigaperf274,6,1427045883965 with port=60020,
startcode=1427048115174
2015-03-22 11:15:16,272 WARN [regionserver60020] regionserver.HRegionServer:
error telling master we are up
com.google.protobuf.ServiceException: java.net.ConnectException: Connection
refused
at
org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1678)
at
org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1719)
at
org.apache.hadoop.hbase.protobuf.generated.RegionServerStatusProtos$RegionServerStatusService$BlockingStub.regionServerStartup(RegionServerStatusProtos.java:8277)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.reportForDuty(HRegionServer.java:2137)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:896)
at java.lang.Thread.run(Thread.java:745)
2015-03-22 11:15:16,274 WARN [regionserver60020] regionserver.HRegionServer:
reportForDuty failed; sleeping and then retrying.
2015-03-22 11:15:19,274 INFO [regionserver60020] regionserver.HRegionServer:
reportForDuty to master=bigaperf273,6,1427048108439 with port=60020,
startcode=1427048115174
2015-03-22 11:15:19,275 WARN [regionserver60020] regionserver.HRegionServer:
error telling master we are up
com.google.protobuf.ServiceException: java.net.ConnectException: Connection
refused
at
org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1678)
at
org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1719)
at
org.apache.hadoop.hbase.protobuf.generated.RegionServerStatusProtos$RegionServerStatusService$BlockingStub.regionServerStartup(RegionServerStatusProtos.java:8277)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.reportForDuty(HRegionServer.java:2137)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:896)
at java.lang.Thread.run(Thread.java:745)
2015-03-22 11:15:19,276 WARN [regionserver60020] regionserver.HRegionServer:
reportForDuty failed; sleeping and then retrying.
2015-03-22 11:15:22,276 INFO [regionserver60020] regionserver.HRegionServer:
reportForDuty to master=bigaperf273,6,1427048108439 with port=60020,
startcode=1427048115174
2015-03-22 11:15:22,296 DEBUG [regionserver60020] regionserver.HRegionServer:
Master is not running yet
2015-03-22 11:15:22,296 WARN [regionserver60020] regionserver.HRegionServer:
reportForDuty failed; sleeping and then retrying.
2015-03-22 11:15:25,296 INFO [regionserver60020] regionserver.HRegionServer:
reportForDuty to master=bigaperf273,6,1427048108439 with port=60020,
startcode=1427048115174
2015-03-22 11:15:25,299 DEBUG [regionserver60020] regionserver.HRegionServer:
Master is not running yet
2015-03-22 11:15:25,299 WARN [regionserver60020] regionserver.HRegionServer:
reportForDuty failed; sleeping and then retrying.
2015-03-22 11:15:28,299 INFO [regionserver60020] regionserver.HRegionServer:
reportForDuty to master=bigaperf273,6,1427048108439 with port=60020,
startcode=1427048115174
2015-03-22 11:15:28,302 DEBUG [regionserver60020] regionserver.HRegionServer:
Master is not running yet
2015-03-22 11:15:28,302 WARN [regionserver60020] regionserver.HRegionServer:
reportForDuty failed; sleeping and then retrying.
{noformat}
What happended is the region server first got
master=bigaperf274,6,1427045883965. Before it was able to report
successfully, the maser changed to bigaperf273,6,1427048108439.
We were supposed to open a new
[jira] [Updated] (HBASE-13359) Update ACL matrix to include table owner.
[ https://issues.apache.org/jira/browse/HBASE-13359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13359: Summary: Update ACL matrix to include table owner. (was: Updata ACL matrix to include table owner.) Update ACL matrix to include table owner. - Key: HBASE-13359 URL: https://issues.apache.org/jira/browse/HBASE-13359 Project: HBase Issue Type: Improvement Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Looks like we allow table owner to truncate and modify table. We should update ACL matrix to reflect this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13262) ResultScanner doesn't return all rows in Scan
[
https://issues.apache.org/jira/browse/HBASE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385669#comment-14385669
]
Hudson commented on HBASE-13262:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #878 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/878/])
HBASE-13262 Observe ScanResponse.moreResults in ClientScanner. (apurtell: rev
1abf3aa0fd355d69cb3eed325b876a62065807b3)
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScannerCallable.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RegionServerCallable.java
* hbase-protocol/src/main/protobuf/Client.proto
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientSmallScanner.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientSmallReversedScanner.java
*
hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ClientProtos.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSizeFailures.java
ResultScanner doesn't return all rows in Scan
-
Key: HBASE-13262
URL: https://issues.apache.org/jira/browse/HBASE-13262
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 2.0.0, 1.1.0
Environment: Single node, pseduo-distributed 1.1.0-SNAPSHOT
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
Attachments: 13262-0.98-testpatch.txt, HBASE-13262-0.98-v7.patch,
HBASE-13262-branch-1-v2.patch, HBASE-13262-branch-1-v3.patch,
HBASE-13262-branch-1.0-v7.patch, HBASE-13262-branch-1.patch,
HBASE-13262-v1.patch, HBASE-13262-v2.patch, HBASE-13262-v3.patch,
HBASE-13262-v4.patch, HBASE-13262-v5.patch, HBASE-13262-v6.patch,
HBASE-13262-v7.patch, HBASE-13262-v7.patch, HBASE-13262.patch,
regionserver-logging.diff, testrun_0.98.txt, testrun_branch1.0.txt
Tried to write a simple Java client again 1.1.0-SNAPSHOT.
* Write 1M rows, each row with 1 family, and 10 qualifiers (values [0-9]),
for a total of 10M cells written
* Read back the data from the table, ensure I saw 10M cells
Running it against {{04ac1891}} (and earlier) yesterday, I would get ~20% of
the actual rows. Running against 1.0.0, returns all 10M records as expected.
[Code I was
running|https://github.com/joshelser/hbase-hwhat/blob/master/src/main/java/hbase/HBaseTest.java]
for the curious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385792#comment-14385792 ] Matteo Bertozzi commented on HBASE-13296: - Why master.createNamespace() instead of admin.createNamespace()? if we change the master implementation to be async as other operation the test will be flaky Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13360) Standalone example docs (for Raft / HBASE-12259)
[
https://issues.apache.org/jira/browse/HBASE-13360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin SB updated HBASE-13360:
--
Summary: Standalone example docs (for Raft / HBASE-12259) (was: Standalone
example docs)
Standalone example docs (for Raft / HBASE-12259)
Key: HBASE-13360
URL: https://issues.apache.org/jira/browse/HBASE-13360
Project: HBase
Issue Type: Improvement
Components: Consensus
Affects Versions: HBASE-12259
Reporter: Justin SB
Priority: Minor
I'm very interested in the Raft implementation (in particular, whether it can
be reused elsewhere, given that this effort seems likely to produce the
canonical Raft implementation).
I'd like to try it standalone, but I'm not yet having much success.
I start a cluster of 3 servers (N=0,1,2):
java -cp
conf:hbase-consensus/target/hbase-consensus-2.0.0-SNAPSHOT.jar:hbase-consensus/target/dependency/*
org.apache.hadoop.hbase.consensus.server.LocalConsensusServer -region 1
-servers 127.0.0.1:1,127.0.0.1:10001,127.0.0.1:10002 -debug DEBUG
-localIndex ${N}
And then I try running the load-test client:
java -cp
hbase-consensus/target/hbase-consensus-2.0.0-SNAPSHOT.jar:hbase-consensus/target/dependency/*
org.apache.hadoop.hbase.consensus.client.QuorumLoadTestClient -region 1
-servers 127.0.0.1:1,127.0.0.1:10001,127.0.0.1:10002
That gives an immediate NPE at
org.apache.hadoop.hbase.consensus.quorum.QuorumInfo.populateInternalMaps(QuorumInfo.java:315).
Are there any docs on how to get started playing with running this branch?
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13360) Standalone example docs
Justin SB created HBASE-13360:
-
Summary: Standalone example docs
Key: HBASE-13360
URL: https://issues.apache.org/jira/browse/HBASE-13360
Project: HBase
Issue Type: Improvement
Components: Consensus
Affects Versions: HBASE-12259
Reporter: Justin SB
Priority: Minor
I'm very interested in the Raft implementation (in particular, whether it can
be reused elsewhere, given that this effort seems likely to produce the
canonical Raft implementation).
I'd like to try it standalone, but I'm not yet having much success.
I start a cluster of 3 servers (N=0,1,2):
java -cp
conf:hbase-consensus/target/hbase-consensus-2.0.0-SNAPSHOT.jar:hbase-consensus/target/dependency/*
org.apache.hadoop.hbase.consensus.server.LocalConsensusServer -region 1
-servers 127.0.0.1:1,127.0.0.1:10001,127.0.0.1:10002 -debug DEBUG
-localIndex ${N}
And then I try running the load-test client:
java -cp
hbase-consensus/target/hbase-consensus-2.0.0-SNAPSHOT.jar:hbase-consensus/target/dependency/*
org.apache.hadoop.hbase.consensus.client.QuorumLoadTestClient -region 1
-servers 127.0.0.1:1,127.0.0.1:10001,127.0.0.1:10002
That gives an immediate NPE at
org.apache.hadoop.hbase.consensus.quorum.QuorumInfo.populateInternalMaps(QuorumInfo.java:315).
Are there any docs on how to get started playing with running this branch?
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12993) Use HBase 1.0 interfaces in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385834#comment-14385834
]
Hudson commented on HBASE-12993:
FAILURE: Integrated in HBase-TRUNK #6320 (See
[https://builds.apache.org/job/HBase-TRUNK/6320/])
HBASE-12993 Use HBase 1.0 interfaces in hbase-thrift (Solomon Duskis) (tedyu:
rev bfb04d26a757aa146c180710545b11856868f08a)
*
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/util/ConnectionCache.java
Use HBase 1.0 interfaces in hbase-thrift
Key: HBASE-12993
URL: https://issues.apache.org/jira/browse/HBASE-12993
Project: HBase
Issue Type: Bug
Reporter: Solomon Duskis
Assignee: Solomon Duskis
Fix For: 2.0.0, 1.0.1, 1.1.0
Attachments: 12993-1.0.patch, HBASE-12993-1.patch, HBASE-12993.patch
hbase-thrift uses HTable and HBaesAdmin. It also uses HTablePool, which is
an outdated concept.
As per [~ndimiduk] on the user group:
{quote}
I believe HTablePool is completely eclipsed by the modern Connection
implementation. We'll need to keep the map of UserName = Connection (or
maybe the ConnectionCache handles this?) Probably a single Connection (per
user) with a large thread pool will do the trick.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13262) ResultScanner doesn't return all rows in Scan
[
https://issues.apache.org/jira/browse/HBASE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385840#comment-14385840
]
Lars Hofhansl commented on HBASE-13262:
---
Please ignore my comment above. 0.98 already has Scan.{get|set}MaxResultSize.
What I was trying to say is that we should default that (i.e. on the client) to
2mb.
ResultScanner doesn't return all rows in Scan
-
Key: HBASE-13262
URL: https://issues.apache.org/jira/browse/HBASE-13262
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 2.0.0, 1.1.0
Environment: Single node, pseduo-distributed 1.1.0-SNAPSHOT
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
Attachments: 13262-0.98-testpatch.txt, HBASE-13262-0.98-v7.patch,
HBASE-13262-branch-1-v2.patch, HBASE-13262-branch-1-v3.patch,
HBASE-13262-branch-1.0-v7.patch, HBASE-13262-branch-1.patch,
HBASE-13262-v1.patch, HBASE-13262-v2.patch, HBASE-13262-v3.patch,
HBASE-13262-v4.patch, HBASE-13262-v5.patch, HBASE-13262-v6.patch,
HBASE-13262-v7.patch, HBASE-13262-v7.patch, HBASE-13262.patch,
regionserver-logging.diff, testrun_0.98.txt, testrun_branch1.0.txt
Tried to write a simple Java client again 1.1.0-SNAPSHOT.
* Write 1M rows, each row with 1 family, and 10 qualifiers (values [0-9]),
for a total of 10M cells written
* Read back the data from the table, ensure I saw 10M cells
Running it against {{04ac1891}} (and earlier) yesterday, I would get ~20% of
the actual rows. Running against 1.0.0, returns all 10M records as expected.
[Code I was
running|https://github.com/joshelser/hbase-hwhat/blob/master/src/main/java/hbase/HBaseTest.java]
for the curious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12993) Use HBase 1.0 interfaces in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385835#comment-14385835
]
Hudson commented on HBASE-12993:
SUCCESS: Integrated in HBase-1.0 #837 (See
[https://builds.apache.org/job/HBase-1.0/837/])
HBASE-12993 Use HBase 1.0 interfaces in hbase-thrift (Solomon Duskis) (tedyu:
rev 8dab79e6f902f765dab561f218c0590b26463b5b)
* hbase-server/src/main/java/org/apache/hadoop/hbase/util/ConnectionCache.java
*
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java
Use HBase 1.0 interfaces in hbase-thrift
Key: HBASE-12993
URL: https://issues.apache.org/jira/browse/HBASE-12993
Project: HBase
Issue Type: Bug
Reporter: Solomon Duskis
Assignee: Solomon Duskis
Fix For: 2.0.0, 1.0.1, 1.1.0
Attachments: 12993-1.0.patch, HBASE-12993-1.patch, HBASE-12993.patch
hbase-thrift uses HTable and HBaesAdmin. It also uses HTablePool, which is
an outdated concept.
As per [~ndimiduk] on the user group:
{quote}
I believe HTablePool is completely eclipsed by the modern Connection
implementation. We'll need to keep the map of UserName = Connection (or
maybe the ConnectionCache handles this?) Probably a single Connection (per
user) with a large thread pool will do the trick.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12993) Use HBase 1.0 interfaces in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385830#comment-14385830
]
Solomon Duskis commented on HBASE-12993:
Thanks!
Use HBase 1.0 interfaces in hbase-thrift
Key: HBASE-12993
URL: https://issues.apache.org/jira/browse/HBASE-12993
Project: HBase
Issue Type: Bug
Reporter: Solomon Duskis
Assignee: Solomon Duskis
Fix For: 2.0.0, 1.0.1, 1.1.0
Attachments: 12993-1.0.patch, HBASE-12993-1.patch, HBASE-12993.patch
hbase-thrift uses HTable and HBaesAdmin. It also uses HTablePool, which is
an outdated concept.
As per [~ndimiduk] on the user group:
{quote}
I believe HTablePool is completely eclipsed by the modern Connection
implementation. We'll need to keep the map of UserName = Connection (or
maybe the ConnectionCache handles this?) Probably a single Connection (per
user) with a large thread pool will do the trick.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12993) Use HBase 1.0 interfaces in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385831#comment-14385831
]
Hudson commented on HBASE-12993:
SUCCESS: Integrated in HBase-1.1 #337 (See
[https://builds.apache.org/job/HBase-1.1/337/])
HBASE-12993 Use HBase 1.0 interfaces in hbase-thrift (Solomon Duskis) (tedyu:
rev 0f0f3f849334801b1d9da9ba3f54f83d0158dba2)
*
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/util/ConnectionCache.java
Use HBase 1.0 interfaces in hbase-thrift
Key: HBASE-12993
URL: https://issues.apache.org/jira/browse/HBASE-12993
Project: HBase
Issue Type: Bug
Reporter: Solomon Duskis
Assignee: Solomon Duskis
Fix For: 2.0.0, 1.0.1, 1.1.0
Attachments: 12993-1.0.patch, HBASE-12993-1.patch, HBASE-12993.patch
hbase-thrift uses HTable and HBaesAdmin. It also uses HTablePool, which is
an outdated concept.
As per [~ndimiduk] on the user group:
{quote}
I believe HTablePool is completely eclipsed by the modern Connection
implementation. We'll need to keep the map of UserName = Connection (or
maybe the ConnectionCache handles this?) Probably a single Connection (per
user) with a large thread pool will do the trick.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13312) SmallScannerCallable does not increment scan metrics
[
https://issues.apache.org/jira/browse/HBASE-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars George updated HBASE-13312:
Fix Version/s: 1.1.0
1.0.1
2.0.0
SmallScannerCallable does not increment scan metrics
Key: HBASE-13312
URL: https://issues.apache.org/jira/browse/HBASE-13312
Project: HBase
Issue Type: Bug
Components: Client, Scanners
Affects Versions: 1.0.0
Reporter: Lars George
Fix For: 2.0.0, 1.0.1, 1.1.0
The subclass of {{ScannerCallable}}, called {{SmallScannerCallable}} seems to
miss calling any of the increment methods of the {{ScanMetrics}}. The
superclass does so, but the super methods are not invoked. It emits the
metrics dutifully at the end of {{next()}}, but there are no useful numbers
in it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13312) SmallScannerCallable does not increment scan metrics
[
https://issues.apache.org/jira/browse/HBASE-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385765#comment-14385765
]
Lars George commented on HBASE-13312:
-
[~apurtell], do you want to check for 0.98?
SmallScannerCallable does not increment scan metrics
Key: HBASE-13312
URL: https://issues.apache.org/jira/browse/HBASE-13312
Project: HBase
Issue Type: Bug
Components: Client, Scanners
Affects Versions: 1.0.0
Reporter: Lars George
Fix For: 2.0.0, 1.0.1, 1.1.0
The subclass of {{ScannerCallable}}, called {{SmallScannerCallable}} seems to
miss calling any of the increment methods of the {{ScanMetrics}}. The
superclass does so, but the super methods are not invoked. It emits the
metrics dutifully at the end of {{next()}}, but there are no useful numbers
in it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12993) Use HBase 1.0 interfaces in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-12993:
---
Attachment: 12993-1.0.patch
What got committed to branch-1 and branch-1.0
Use HBase 1.0 interfaces in hbase-thrift
Key: HBASE-12993
URL: https://issues.apache.org/jira/browse/HBASE-12993
Project: HBase
Issue Type: Bug
Reporter: Solomon Duskis
Assignee: Solomon Duskis
Fix For: 2.0.0, 1.0.1, 1.1.0
Attachments: 12993-1.0.patch, HBASE-12993-1.patch, HBASE-12993.patch
hbase-thrift uses HTable and HBaesAdmin. It also uses HTablePool, which is
an outdated concept.
As per [~ndimiduk] on the user group:
{quote}
I believe HTablePool is completely eclipsed by the modern Connection
implementation. We'll need to keep the map of UserName = Connection (or
maybe the ConnectionCache handles this?) Probably a single Connection (per
user) with a large thread pool will do the trick.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-12993) Use HBase 1.0 interfaces in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-12993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-12993:
---
Resolution: Fixed
Fix Version/s: 1.1.0
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch, Solomon
Use HBase 1.0 interfaces in hbase-thrift
Key: HBASE-12993
URL: https://issues.apache.org/jira/browse/HBASE-12993
Project: HBase
Issue Type: Bug
Reporter: Solomon Duskis
Assignee: Solomon Duskis
Fix For: 2.0.0, 1.0.1, 1.1.0
Attachments: HBASE-12993-1.patch, HBASE-12993.patch
hbase-thrift uses HTable and HBaesAdmin. It also uses HTablePool, which is
an outdated concept.
As per [~ndimiduk] on the user group:
{quote}
I believe HTablePool is completely eclipsed by the modern Connection
implementation. We'll need to keep the map of UserName = Connection (or
maybe the ConnectionCache handles this?) Probably a single Connection (per
user) with a large thread pool will do the trick.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385841#comment-14385841 ] Srikanth Srungarapu commented on HBASE-13296: - Agreed. Uploaded the patch for addressing this. Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch, HBASE-13296_v3.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[
https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385885#comment-14385885
]
Hadoop QA commented on HBASE-13296:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12708049/HBASE-13296_v3.patch
against master branch at commit bfb04d26a757aa146c180710545b11856868f08a.
ATTACHMENT ID: 12708049
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 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 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13484//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13484//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13484//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13484//console
This message is automatically generated.
Fix the deletion of acl notify nodes for namespace.
---
Key: HBASE-13296
URL: https://issues.apache.org/jira/browse/HBASE-13296
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Priority: Minor
Attachments: HBASE-13296.patch, HBASE-13296_v2.patch,
HBASE-13296_v2.patch, HBASE-13296_v3.patch, HBASE-13296_v3.patch
Though we're clearing the permissions of namespaces in AccessControlLists,
we're not taking care of clearing acl znodes related to namespace. Looking at
the code, we're taking care of this case with tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385842#comment-14385842 ] Srikanth Srungarapu commented on HBASE-13296: - Agreed. Uploaded the patch for addressing this. Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch, HBASE-13296_v3.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13262) ResultScanner doesn't return all rows in Scan
[
https://issues.apache.org/jira/browse/HBASE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385840#comment-14385840
]
Lars Hofhansl edited comment on HBASE-13262 at 3/29/15 5:47 PM:
Please ignore my comment above. 0.98 already has Scan.{get|set\}MaxResultSize.
What I was trying to say is that we should default that (i.e. on the client) to
2mb.
was (Author: lhofhansl):
Please ignore my comment above. 0.98 already has Scan.{get|set}MaxResultSize.
What I was trying to say is that we should default that (i.e. on the client) to
2mb.
ResultScanner doesn't return all rows in Scan
-
Key: HBASE-13262
URL: https://issues.apache.org/jira/browse/HBASE-13262
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 2.0.0, 1.1.0
Environment: Single node, pseduo-distributed 1.1.0-SNAPSHOT
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
Attachments: 13262-0.98-testpatch.txt, HBASE-13262-0.98-v7.patch,
HBASE-13262-branch-1-v2.patch, HBASE-13262-branch-1-v3.patch,
HBASE-13262-branch-1.0-v7.patch, HBASE-13262-branch-1.patch,
HBASE-13262-v1.patch, HBASE-13262-v2.patch, HBASE-13262-v3.patch,
HBASE-13262-v4.patch, HBASE-13262-v5.patch, HBASE-13262-v6.patch,
HBASE-13262-v7.patch, HBASE-13262-v7.patch, HBASE-13262.patch,
regionserver-logging.diff, testrun_0.98.txt, testrun_branch1.0.txt
Tried to write a simple Java client again 1.1.0-SNAPSHOT.
* Write 1M rows, each row with 1 family, and 10 qualifiers (values [0-9]),
for a total of 10M cells written
* Read back the data from the table, ensure I saw 10M cells
Running it against {{04ac1891}} (and earlier) yesterday, I would get ~20% of
the actual rows. Running against 1.0.0, returns all 10M records as expected.
[Code I was
running|https://github.com/joshelser/hbase-hwhat/blob/master/src/main/java/hbase/HBaseTest.java]
for the curious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13359) Update ACL matrix to include table owner.
[ https://issues.apache.org/jira/browse/HBASE-13359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13359: Priority: Minor (was: Major) Update ACL matrix to include table owner. - Key: HBASE-13359 URL: https://issues.apache.org/jira/browse/HBASE-13359 Project: HBase Issue Type: Improvement Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Looks like we allow table owner to truncate and modify table. We should update ACL matrix to reflect this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13296: Attachment: HBASE-13296_v3.patch Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch, HBASE-13296_v3.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13361) Remove or undeprecate {get|set}ScannerCaching in HTable
Lars Francke created HBASE-13361:
Summary: Remove or undeprecate {get|set}ScannerCaching in HTable
Key: HBASE-13361
URL: https://issues.apache.org/jira/browse/HBASE-13361
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 1.0.0
Reporter: Lars Francke
Assignee: Lars Francke
Priority: Minor
{{getScannerCaching}} and {{setScannerCaching}} have been deprecated since 2011
(HBASE-4439). I think it's time to either remove them or undeprecate.
I was not able to find any other issues in JIRA or discussions on mailing lists
regarding deprecation removal policies but I think 3+ years is probably enough
warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13361) Remove or undeprecate {get|set}ScannerCaching in HTable
[
https://issues.apache.org/jira/browse/HBASE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Francke updated HBASE-13361:
-
Issue Type: Task (was: Bug)
Remove or undeprecate {get|set}ScannerCaching in HTable
---
Key: HBASE-13361
URL: https://issues.apache.org/jira/browse/HBASE-13361
Project: HBase
Issue Type: Task
Components: Client
Affects Versions: 1.0.0
Reporter: Lars Francke
Assignee: Lars Francke
Priority: Minor
{{getScannerCaching}} and {{setScannerCaching}} have been deprecated since
2011 (HBASE-4439). I think it's time to either remove them or undeprecate.
I was not able to find any other issues in JIRA or discussions on mailing
lists regarding deprecation removal policies but I think 3+ years is probably
enough warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13359) Update ACL matrix to include table owner.
[ https://issues.apache.org/jira/browse/HBASE-13359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13359: Issue Type: Bug (was: Improvement) Update ACL matrix to include table owner. - Key: HBASE-13359 URL: https://issues.apache.org/jira/browse/HBASE-13359 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Looks like we allow table owner to truncate and modify table. We should update ACL matrix to reflect this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13296: Attachment: HBASE-13296_v3.patch Hello Jenkins... Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch, HBASE-13296_v3.patch, HBASE-13296_v3.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[
https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385686#comment-14385686
]
Hadoop QA commented on HBASE-13296:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12708029/HBASE-13296_v2.patch
against master branch at commit ced0e324a190e75d8a93b8b09676781853819361.
ATTACHMENT ID: 12708029
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 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 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13482//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13482//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13482//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13482//console
This message is automatically generated.
Fix the deletion of acl notify nodes for namespace.
---
Key: HBASE-13296
URL: https://issues.apache.org/jira/browse/HBASE-13296
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Priority: Minor
Attachments: HBASE-13296.patch, HBASE-13296_v2.patch,
HBASE-13296_v2.patch
Though we're clearing the permissions of namespaces in AccessControlLists,
we're not taking care of clearing acl znodes related to namespace. Looking at
the code, we're taking care of this case with tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13262) ResultScanner doesn't return all rows in Scan
[
https://issues.apache.org/jira/browse/HBASE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385654#comment-14385654
]
Hudson commented on HBASE-13262:
SUCCESS: Integrated in HBase-0.98 #924 (See
[https://builds.apache.org/job/HBase-0.98/924/])
HBASE-13262 Observe ScanResponse.moreResults in ClientScanner. (apurtell: rev
1abf3aa0fd355d69cb3eed325b876a62065807b3)
*
hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ClientProtos.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientSmallReversedScanner.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientSmallScanner.java
* hbase-protocol/src/main/protobuf/Client.proto
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/RegionServerCallable.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSizeFailures.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScannerCallable.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java
ResultScanner doesn't return all rows in Scan
-
Key: HBASE-13262
URL: https://issues.apache.org/jira/browse/HBASE-13262
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 2.0.0, 1.1.0
Environment: Single node, pseduo-distributed 1.1.0-SNAPSHOT
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12
Attachments: 13262-0.98-testpatch.txt, HBASE-13262-0.98-v7.patch,
HBASE-13262-branch-1-v2.patch, HBASE-13262-branch-1-v3.patch,
HBASE-13262-branch-1.0-v7.patch, HBASE-13262-branch-1.patch,
HBASE-13262-v1.patch, HBASE-13262-v2.patch, HBASE-13262-v3.patch,
HBASE-13262-v4.patch, HBASE-13262-v5.patch, HBASE-13262-v6.patch,
HBASE-13262-v7.patch, HBASE-13262-v7.patch, HBASE-13262.patch,
regionserver-logging.diff, testrun_0.98.txt, testrun_branch1.0.txt
Tried to write a simple Java client again 1.1.0-SNAPSHOT.
* Write 1M rows, each row with 1 family, and 10 qualifiers (values [0-9]),
for a total of 10M cells written
* Read back the data from the table, ensure I saw 10M cells
Running it against {{04ac1891}} (and earlier) yesterday, I would get ~20% of
the actual rows. Running against 1.0.0, returns all 10M records as expected.
[Code I was
running|https://github.com/joshelser/hbase-hwhat/blob/master/src/main/java/hbase/HBaseTest.java]
for the curious.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13296: Attachment: HBASE-13296_v2.patch Besides unit test, also did some cleanup. Tests passing on local box. Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanth Srungarapu updated HBASE-13296: Attachment: HBASE-13296_v2.patch Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[
https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385675#comment-14385675
]
Ashish Singhi commented on HBASE-13296:
---
Looks ok to me.
minor nits,
Can we create local variables for the return values of this methods and avoid
repetitive calls to this methods.
{code}
TEST_UTIL.getMiniHBaseCluster().getMaster()
table.getNameAsString()
convertToNamespace(ns)
{code}
Why not use assertNotEquals and assertEquals here
{code}
+assertTrue(ZKUtil.checkExists(zkw, baseAclZNode + table.getNameAsString())
!= -1);
+assertTrue(ZKUtil.checkExists(zkw, baseAclZNode + convertToNamespace(ns))
!= -1);
{code}
{code}
+assertTrue(ZKUtil.checkExists(zkw, baseAclZNode + table.getNameAsString())
== -1);
+assertTrue(ZKUtil.checkExists(zkw, baseAclZNode + convertToNamespace(ns))
== -1);
{code}
Fix the deletion of acl notify nodes for namespace.
---
Key: HBASE-13296
URL: https://issues.apache.org/jira/browse/HBASE-13296
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Priority: Minor
Attachments: HBASE-13296.patch, HBASE-13296_v2.patch
Though we're clearing the permissions of namespaces in AccessControlLists,
we're not taking care of clearing acl znodes related to namespace. Looking at
the code, we're taking care of this case with tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[
https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385679#comment-14385679
]
Srikanth Srungarapu commented on HBASE-13296:
-
Extracted a local variable for master, as it saved 3 occurrences. We already
have local variables for table name and namespace. I don't think creating again
local variables for table.getNameAsString() and convertToNamespace(ns) can save
us a lot, especially given the fact there are only 2 occurrences.
If znode exists, the version number is returned.
{code}
* @return version of the node if it exists, -1 if does not exist
{code}
Thought it would be easier to restrict ourselves to check for existence or not,
in which case assertTrue would be better choice. For consistency sake, I used
it for throughout. Let's see what other folks would suggest. If they have other
opinions, I would be happy to change.
Fix the deletion of acl notify nodes for namespace.
---
Key: HBASE-13296
URL: https://issues.apache.org/jira/browse/HBASE-13296
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Priority: Minor
Attachments: HBASE-13296.patch, HBASE-13296_v2.patch,
HBASE-13296_v2.patch
Though we're clearing the permissions of namespaces in AccessControlLists,
we're not taking care of clearing acl znodes related to namespace. Looking at
the code, we're taking care of this case with tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13301) Possible memory leak in BucketCache
[
https://issues.apache.org/jira/browse/HBASE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385682#comment-14385682
]
zhangduo commented on HBASE-13301:
--
{quote}
In btw a context switch t1 completed the caching and done evict and again
cached same block.. This seems rarest of rare case.
{quote}
Agree. But HBase is a long running service, small probability events always
occur if we keep it running long enough...
Let me revisit the whole read write path in regionserver which relates to
BlockCache and give a clear locking schema first. Then it is easier to say if
the situation in this testcase could happen.
Will come back later. Thanks.
Possible memory leak in BucketCache
---
Key: HBASE-13301
URL: https://issues.apache.org/jira/browse/HBASE-13301
Project: HBase
Issue Type: Bug
Components: BlockCache
Reporter: zhangduo
Assignee: zhangduo
Attachments: HBASE-13301-testcase.patch
{code:title=BucketCache.java}
public boolean evictBlock(BlockCacheKey cacheKey) {
...
if (bucketEntry.equals(backingMap.remove(cacheKey))) {
bucketAllocator.freeBlock(bucketEntry.offset());
realCacheSize.addAndGet(-1 * bucketEntry.getLength());
blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
if (removedBlock == null) {
this.blockNumber.decrementAndGet();
}
} else {
return false;
}
...
{code}
I think the problem is here. We remove a BucketEntry that should not be
removed by us, but we do not put it back and also do not do any clean up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[
https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385701#comment-14385701
]
Hadoop QA commented on HBASE-13296:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12708032/HBASE-13296_v2.patch
against master branch at commit ced0e324a190e75d8a93b8b09676781853819361.
ATTACHMENT ID: 12708032
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 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 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13483//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13483//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13483//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13483//console
This message is automatically generated.
Fix the deletion of acl notify nodes for namespace.
---
Key: HBASE-13296
URL: https://issues.apache.org/jira/browse/HBASE-13296
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Priority: Minor
Attachments: HBASE-13296.patch, HBASE-13296_v2.patch,
HBASE-13296_v2.patch
Though we're clearing the permissions of namespaces in AccessControlLists,
we're not taking care of clearing acl znodes related to namespace. Looking at
the code, we're taking care of this case with tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13337) Table regions are not assigning back, after restarting all regionservers at once.
[
https://issues.apache.org/jira/browse/HBASE-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385920#comment-14385920
]
Jimmy Xiang commented on HBASE-13337:
-
Thanks a lot for verifying it.
Table regions are not assigning back, after restarting all regionservers at
once.
-
Key: HBASE-13337
URL: https://issues.apache.org/jira/browse/HBASE-13337
Project: HBase
Issue Type: Bug
Components: Region Assignment
Affects Versions: 2.0.0
Reporter: Y. SREENIVASULU REDDY
Priority: Blocker
Fix For: 2.0.0
Regions of the table are continouly in state=FAILED_CLOSE.
{noformat}
RegionState
RIT time (ms)
8f62e819b356736053e06240f7f7c6fd
t1,,1427362431330.8f62e819b356736053e06240f7f7c6fd.
state=FAILED_CLOSE, ts=Thu Mar 26 15:05:36 IST 2015 (113s ago),
server=VM1,16040,1427362531818 113929
caf59209ae65ea80fca6bdc6996a7d68
t1,,1427362431330.caf59209ae65ea80fca6bdc6996a7d68.
state=FAILED_CLOSE, ts=Thu Mar 26 15:05:36 IST 2015 (113s ago),
server=VM2,16040,1427362533691 113929
db52a74988f71e5cf257bbabf31f26f3
t1,,1427362431330.db52a74988f71e5cf257bbabf31f26f3.
state=FAILED_CLOSE, ts=Thu Mar 26 15:05:36 IST 2015 (113s ago),
server=VM3,16040,1427362533691 113920
43f3a65b9f9ff283f598c5450feab1f8
t1,,1427362431330.43f3a65b9f9ff283f598c5450feab1f8.
state=FAILED_CLOSE, ts=Thu Mar 26 15:05:36 IST 2015 (113s ago),
server=VM1,16040,1427362531818 113920
{noformat}
*Steps to reproduce:*
1. Start HBase cluster with more than one regionserver.
2. Create a table with precreated regions. (lets say 15 regions)
3. Make sure the regions are well balanced.
4. Restart all the Regionservers process at once across the cluster, except
HMaster process
5. After restarting the Regionservers, successfully will connect to the
HMaster.
*Bug:*
But no regions are assigning back to the Regionservers.
*Master log shows as follows:*
{noformat}
2015-03-26 15:05:36,201 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.RegionStates: Transition {8f62e819b356736053e06240f7f7c6fd
state=OFFLINE, ts=1427362536106, server=VM2,16040,1427362242602} to
{8f62e819b356736053e06240f7f7c6fd state=PENDING_OPEN, ts=1427362536201,
server=VM1,16040,1427362531818}
2015-03-26 15:05:36,202 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.RegionStateStore: Updating row
t1,,1427362431330.8f62e819b356736053e06240f7f7c6fd. with
state=PENDING_OPENsn=VM1,16040,1427362531818
2015-03-26 15:05:36,244 DEBUG [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.AssignmentManager: Force region state offline
{8f62e819b356736053e06240f7f7c6fd state=PENDING_OPEN, ts=1427362536201,
server=VM1,16040,1427362531818}
2015-03-26 15:05:36,244 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.RegionStates: Transition {8f62e819b356736053e06240f7f7c6fd
state=PENDING_OPEN, ts=1427362536201, server=VM1,16040,1427362531818} to
{8f62e819b356736053e06240f7f7c6fd state=PENDING_CLOSE, ts=1427362536244,
server=VM1,16040,1427362531818}
2015-03-26 15:05:36,244 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.RegionStateStore: Updating row
t1,,1427362431330.8f62e819b356736053e06240f7f7c6fd. with
state=PENDING_CLOSE
2015-03-26 15:05:36,248 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.AssignmentManager: Server VM1,16040,1427362531818 returned
java.nio.channels.ClosedChannelException for
t1,,1427362431330.8f62e819b356736053e06240f7f7c6fd., try=1 of 10
2015-03-26 15:05:36,248 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.AssignmentManager: Server VM1,16040,1427362531818 returned
java.nio.channels.ClosedChannelException for
t1,,1427362431330.8f62e819b356736053e06240f7f7c6fd., try=2 of 10
2015-03-26 15:05:36,249 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.AssignmentManager: Server VM1,16040,1427362531818 returned
java.nio.channels.ClosedChannelException for
t1,,1427362431330.8f62e819b356736053e06240f7f7c6fd., try=3 of 10
2015-03-26 15:05:36,249 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.AssignmentManager: Server VM1,16040,1427362531818 returned
java.nio.channels.ClosedChannelException for
t1,,1427362431330.8f62e819b356736053e06240f7f7c6fd., try=4 of 10
2015-03-26 15:05:36,249 INFO [VM2,16020,1427362216887-GeneralBulkAssigner-0]
master.AssignmentManager: Server VM1,16040,1427362531818 returned
[jira] [Updated] (HBASE-13361) Remove or undeprecate {get|set}ScannerCaching in HTable
[
https://issues.apache.org/jira/browse/HBASE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Francke updated HBASE-13361:
-
Attachment: HBASE-13361.patch
This removes the getter and setter. They were also used in a test. I just
removed the two lines from the test as they don't seem to contribute much. If
you want me to I can provide a patch that allows the test to use
Scan#setCaching instead.
Remove or undeprecate {get|set}ScannerCaching in HTable
---
Key: HBASE-13361
URL: https://issues.apache.org/jira/browse/HBASE-13361
Project: HBase
Issue Type: Task
Components: Client
Affects Versions: 1.0.0
Reporter: Lars Francke
Assignee: Lars Francke
Priority: Minor
Attachments: HBASE-13361.patch
{{getScannerCaching}} and {{setScannerCaching}} have been deprecated since
2011 (HBASE-4439). I think it's time to either remove them or undeprecate.
I was not able to find any other issues in JIRA or discussions on mailing
lists regarding deprecation removal policies but I think 3+ years is probably
enough warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[ https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385944#comment-14385944 ] Matteo Bertozzi commented on HBASE-13296: - +1 on v3 just curious, why did you change the sequence of put() in setup() with a since batch-put? Fix the deletion of acl notify nodes for namespace. --- Key: HBASE-13296 URL: https://issues.apache.org/jira/browse/HBASE-13296 Project: HBase Issue Type: Bug Reporter: Srikanth Srungarapu Assignee: Srikanth Srungarapu Priority: Minor Attachments: HBASE-13296.patch, HBASE-13296_v2.patch, HBASE-13296_v2.patch, HBASE-13296_v3.patch, HBASE-13296_v3.patch Though we're clearing the permissions of namespaces in AccessControlLists, we're not taking care of clearing acl znodes related to namespace. Looking at the code, we're taking care of this case with tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13296) Fix the deletion of acl notify nodes for namespace.
[
https://issues.apache.org/jira/browse/HBASE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385953#comment-14385953
]
Hadoop QA commented on HBASE-13296:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12708056/HBASE-13296_v3.patch
against master branch at commit bfb04d26a757aa146c180710545b11856868f08a.
ATTACHMENT ID: 12708056
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 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 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13485//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13485//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13485//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13485//console
This message is automatically generated.
Fix the deletion of acl notify nodes for namespace.
---
Key: HBASE-13296
URL: https://issues.apache.org/jira/browse/HBASE-13296
Project: HBase
Issue Type: Bug
Reporter: Srikanth Srungarapu
Assignee: Srikanth Srungarapu
Priority: Minor
Attachments: HBASE-13296.patch, HBASE-13296_v2.patch,
HBASE-13296_v2.patch, HBASE-13296_v3.patch, HBASE-13296_v3.patch
Though we're clearing the permissions of namespaces in AccessControlLists,
we're not taking care of clearing acl znodes related to namespace. Looking at
the code, we're taking care of this case with tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13361) Remove or undeprecate {get|set}ScannerCaching in HTable
[
https://issues.apache.org/jira/browse/HBASE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Francke updated HBASE-13361:
-
Status: Patch Available (was: Open)
Remove or undeprecate {get|set}ScannerCaching in HTable
---
Key: HBASE-13361
URL: https://issues.apache.org/jira/browse/HBASE-13361
Project: HBase
Issue Type: Task
Components: Client
Affects Versions: 1.0.0
Reporter: Lars Francke
Assignee: Lars Francke
Priority: Minor
Attachments: HBASE-13361.patch
{{getScannerCaching}} and {{setScannerCaching}} have been deprecated since
2011 (HBASE-4439). I think it's time to either remove them or undeprecate.
I was not able to find any other issues in JIRA or discussions on mailing
lists regarding deprecation removal policies but I think 3+ years is probably
enough warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13362) set max result size from client only (like caching)?
Lars Hofhansl created HBASE-13362: - Summary: set max result size from client only (like caching)? Key: HBASE-13362 URL: https://issues.apache.org/jira/browse/HBASE-13362 Project: HBase Issue Type: Brainstorming Reporter: Lars Hofhansl With the recent problems we've been seeing client/server result size mismatch, I was thinking: Why was this not a problem with scanner caching? There are two reasons: # number of rows is easy to calculate (and we did it correctly) # caching is only controlled from the client, never set on the server alone We did fix both #1 and #2 in HBASE-13262. Still, I'd like to discuss the following: * default the client sent max result size to 2mb * remove any server only result sizing * continue to use hbase.client.scanner.max.result.size but enforce it via the client only (as the name implies anyway). Comments? Concerns? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13361) Remove or undeprecate {get|set}ScannerCaching in HTable
[
https://issues.apache.org/jira/browse/HBASE-13361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386000#comment-14386000
]
Hadoop QA commented on HBASE-13361:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12708058/HBASE-13361.patch
against master branch at commit bfb04d26a757aa146c180710545b11856868f08a.
ATTACHMENT ID: 12708058
{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 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/13486//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/13486//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/13486//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/13486//console
This message is automatically generated.
Remove or undeprecate {get|set}ScannerCaching in HTable
---
Key: HBASE-13361
URL: https://issues.apache.org/jira/browse/HBASE-13361
Project: HBase
Issue Type: Task
Components: Client
Affects Versions: 1.0.0
Reporter: Lars Francke
Assignee: Lars Francke
Priority: Minor
Attachments: HBASE-13361.patch
{{getScannerCaching}} and {{setScannerCaching}} have been deprecated since
2011 (HBASE-4439). I think it's time to either remove them or undeprecate.
I was not able to find any other issues in JIRA or discussions on mailing
lists regarding deprecation removal policies but I think 3+ years is probably
enough warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
