[jira] [Commented] (HBASE-21032) ScanResponses contain only one cell each
[ https://issues.apache.org/jira/browse/HBASE-21032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587958#comment-16587958 ] Andrey Elenskiy commented on HBASE-21032: - Even though we don't use read replicas, it seems like it's the same issue. The last row loaded from hbase:meta was: 18/08/21 19:46:21 INFO assignment.RegionStateStore: Load hbase:meta entry region=2ad4d95f7b9d9ba0d746b8da50a7f9a7, regionState=OPEN, lastHost=regionserver-0,16020,1534538897512, regionLocation=regionserver-3,16020,1533765879856, openSeqNum=172 Which, based on region encoded name, is hbase:namespace. However, the regionserver is different. I think I'm going to halt deploying the patched version for now. Instead, I've run App.java that I've attached and it looks like it behaves as expected. > ScanResponses contain only one cell each > > > Key: HBASE-21032 > URL: https://issues.apache.org/jira/browse/HBASE-21032 > Project: HBase > Issue Type: Bug > Components: Performance, Scanners >Affects Versions: 2.1.0 > Environment: HBase 2.1.0 > Hadoop 2.8.4 > Java 8 >Reporter: Andrey Elenskiy >Assignee: Andrey Elenskiy >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: App.java, HBASE-21032-v1.patch, HBASE-21032-v1.patch, > HBASE-21032.patch > > > I have a long row with a bunch of columns that I'm scanning with > setAllowPartialResults(true). In the response I'm getting the first partial > ScanResponse being around 2MB with multiple cells while all of the consequent > ones being 1 cell per ScanResponse. After digging more, I found that each of > those single cell ScanResponse partials are preceded by a heartbeat (zero > cells). This results in two requests per cell to a regionserver. > I've attached code to reproduce it on hbase version 2.1.0 (it works as > expected on 2.0.0 and 2.0.1). > [^App.java] > I'm fairly certain it's a serverside issue as > [gohbase|https://github.com/tsuna/gohbase] client is having the same issue. I > have not tried to reproduce this with multi-row scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20941) Create and implement HbckService in master
[ https://issues.apache.org/jira/browse/HBASE-20941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-20941: - Attachment: hbase-20941.master.003.patch > Create and implement HbckService in master > -- > > Key: HBASE-20941 > URL: https://issues.apache.org/jira/browse/HBASE-20941 > Project: HBase > Issue Type: Sub-task >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Major > Attachments: hbase-20941.master.001.patch, > hbase-20941.master.002.patch, hbase-20941.master.003.patch > > > Create HbckService in master and implement following methods: > # setTableState(): If table state are inconsistent with action/ procedures > working on them, sometimes manipulating their states in meta fix things. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20690) Moving table to target rsgroup needs to handle TableStateNotFoundException
[
https://issues.apache.org/jira/browse/HBASE-20690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587927#comment-16587927
]
Andrew Purtell commented on HBASE-20690:
Is someone actively working on this? i.e. a patch? If so please update issue
assignment.
> Moving table to target rsgroup needs to handle TableStateNotFoundException
> --
>
> Key: HBASE-20690
> URL: https://issues.apache.org/jira/browse/HBASE-20690
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Priority: Major
>
> This is related code:
> {code}
> if (targetGroup != null) {
> for (TableName table: tables) {
> if (master.getAssignmentManager().isTableDisabled(table)) {
> LOG.debug("Skipping move regions because the table" + table + "
> is disabled.");
> continue;
> }
> {code}
> In a stack trace [~rmani] showed me:
> {code}
> 2018-06-06 07:10:44,893 ERROR
> [RpcServer.default.FPBQ.Fifo.handler=29,queue=2,port=2]
> master.TableStateManager: Unable to get table demo:tbl1 state
> org.apache.hadoop.hbase.master.TableStateManager$TableStateNotFoundException:
> demo:tbl1
> at
> org.apache.hadoop.hbase.master.TableStateManager.getTableState(TableStateManager.java:193)
> at
> org.apache.hadoop.hbase.master.TableStateManager.isTableState(TableStateManager.java:143)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.isTableDisabled(AssignmentManager.java:346)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:407)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.assignTableToGroup(RSGroupAdminEndpoint.java:447)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.postCreateTable(RSGroupAdminEndpoint.java:470)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost$12.call(MasterCoprocessorHost.java:334)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost$12.call(MasterCoprocessorHost.java:331)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$ObserverOperationWithoutResult.callObserver(CoprocessorHost.java:540)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.execOperation(CoprocessorHost.java:614)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost.postCreateTable(MasterCoprocessorHost.java:331)
> at org.apache.hadoop.hbase.master.HMaster$3.run(HMaster.java:1768)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:131)
> at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1750)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:593)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:131)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> {code}
> The logic should take potential TableStateNotFoundException into account.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21089) clean out stale / invalid PRs
[ https://issues.apache.org/jira/browse/HBASE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587922#comment-16587922 ] Sean Busbey commented on HBASE-21089: - [~mdrob] any objection? > clean out stale / invalid PRs > - > > Key: HBASE-21089 > URL: https://issues.apache.org/jira/browse/HBASE-21089 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > > We haven't cleaned out PRs on github in a while. these can go: > * [#63|https://github.com/apache/hbase/pull/63] - no response since April 11 > * [#66|https://github.com/apache/hbase/pull/66] - no response since April 11 > * [#70|https://github.com/apache/hbase/pull/70] - the referenced JIRA, > HBASE-19547, has already closed. > * [#71|https://github.com/apache/hbase/pull/71] - no response since April 11 > * [#78|https://github.com/apache/hbase/pull/78] - no response since Jun 18th -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21077) MR job launched by hbase incremental backup command failed with FileNotFoundException
[
https://issues.apache.org/jira/browse/HBASE-21077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587920#comment-16587920
]
Vladimir Rodionov commented on HBASE-21077:
---
{quote}
We should have a unit test where BackupLogCleaner would remove certain file(s)
needed by the incremental backup without the fix.
{quote}
That is not doable unless I add test-related code into
IncrementalBackupManager, what I do not want to.
I updated some config parameters in B&R unit tests, related to CleanerChore
timeout (which is 1 sec now) and TimeToLiveLogCleaner and added wait between
consecutive incremental backups in TestIncrementalBackup to guarantee that old
wals get deleted before next incremental backup starts.
> MR job launched by hbase incremental backup command failed with
> FileNotFoundException
> -
>
> Key: HBASE-21077
> URL: https://issues.apache.org/jira/browse/HBASE-21077
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Major
> Attachments: HBASE-21077-v1.patch, HBASE-21077-v2.patch,
> HBASE-21077-v3.patch
>
>
> Discovered during internal testing by Romil Choksi.
> MR job launched by hbase incremental backup command failed with
> FileNotFoundException
> from test console log
> {code}
> 2018-06-12 04:27:31,160|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,160 INFO
> [main] mapreduce.JobSubmitter: Submitting tokens for job:
> job_1528766389356_0044
> 2018-06-12 04:27:31,186|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,184 INFO
> [main] mapreduce.JobSubmitter: Executing with tokens: [Kind:
> HDFS_DELEGATION_TOKEN, Service: ha-hdfs:ns1, Ident: (token for hbase:
> HDFS_DELEGATION_TOKEN owner=hb...@example.com, renewer=yarn, realUser=,
> issueDate=1528777648605, maxDate=1529382448605, sequenceNumber=175,
> masterKeyId=2), Kind: kms-dt, Service: 172.27.68.203:9393, Ident: (kms-dt
> owner=hbase, renewer=yarn, realUser=, issueDate=1528777649149,
> maxDate=1529382449149, sequenceNumber=49, masterKeyId=2), Kind:
> HBASE_AUTH_TOKEN, Service: bc71e347-78ff-4f95-af44-006f9b549a84, Ident:
> (org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier@5),
> Kind: kms-dt, Service: 172.27.52.14:9393, Ident: (kms-dt owner=hbase,
> renewer=yarn, realUser=, issueDate=1528777648918, maxDate=1529382448918,
> sequenceNumber=50, masterKeyId=2)]
> 2018-06-12 04:27:31,477|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,477 INFO
> [main] conf.Configuration: found resource resource-types.xml at
> file:/etc/hadoop/3.0.0.0-1476/0/resource-types.xml
> 2018-06-12 04:27:31,527|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,527 INFO
> [main] impl.TimelineClientImpl: Timeline service address:
> ctr-e138-1518143905142-359429-01-04.hwx.site:8190
> 2018-06-12 04:27:32,563|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,562 INFO
> [main] impl.YarnClientImpl: Submitted application
> application_1528766389356_0044
> 2018-06-12 04:27:32,634|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,634 INFO
> [main] mapreduce.Job: The url to track the job:
> https://ctr-e138-1518143905142-359429-01-03.hwx.site:8090/proxy/application_1528766389356_0044/
> 2018-06-12 04:27:32,635|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,635 INFO
> [main] mapreduce.Job: Running job: job_1528766389356_0044
> 2018-06-12 04:27:44,807|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:44,806 INFO
> [main] mapreduce.Job: Job job_1528766389356_0044 running in uber mode : false
> 2018-06-12 04:27:44,809|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:44,809 INFO
> [main] mapreduce.Job: map 0% reduce 0%
> 2018-06-12 04:27:54,926|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:54,925 INFO
> [main] mapreduce.Job: map 5% reduce 0%
> 2018-06-12 04:27:56,950|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:56,950 INFO
> [main] mapreduce.Job: Task Id : attempt_1528766389356_0044_m_02_0,
> Status : FAILED
> 2018-06-12 04:27:56,979|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|Error:
> java.io.FileNotFoundException: File does not exist:
> hdfs://ns1/
[jira] [Commented] (HBASE-21091) Update Hadoop compatibility table
[ https://issues.apache.org/jira/browse/HBASE-21091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587915#comment-16587915 ] Josh Elser commented on HBASE-21091: Yes to both, Sean. Thanks for your input! > Update Hadoop compatibility table > - > > Key: HBASE-21091 > URL: https://issues.apache.org/jira/browse/HBASE-21091 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > > [https://lists.apache.org/thread.html/7016d322a07e96dccdb071041c37238e43d3df4f93e9515d52ccfafc@%3Cdev.hbase.apache.org%3E] > covers some discussion around our Hadoop Version Compatibility table. > > A "leading" suggestion to make this more clear is to use a green/yellow/red > (traffic-signal) style marking, instead of using specifics words/phrases (as > they're often dependent on the interpretation of the reader). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21077) MR job launched by hbase incremental backup command failed with FileNotFoundException
[
https://issues.apache.org/jira/browse/HBASE-21077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-21077:
--
Status: Patch Available (was: Open)
> MR job launched by hbase incremental backup command failed with
> FileNotFoundException
> -
>
> Key: HBASE-21077
> URL: https://issues.apache.org/jira/browse/HBASE-21077
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Major
> Attachments: HBASE-21077-v1.patch, HBASE-21077-v2.patch,
> HBASE-21077-v3.patch
>
>
> Discovered during internal testing by Romil Choksi.
> MR job launched by hbase incremental backup command failed with
> FileNotFoundException
> from test console log
> {code}
> 2018-06-12 04:27:31,160|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,160 INFO
> [main] mapreduce.JobSubmitter: Submitting tokens for job:
> job_1528766389356_0044
> 2018-06-12 04:27:31,186|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,184 INFO
> [main] mapreduce.JobSubmitter: Executing with tokens: [Kind:
> HDFS_DELEGATION_TOKEN, Service: ha-hdfs:ns1, Ident: (token for hbase:
> HDFS_DELEGATION_TOKEN owner=hb...@example.com, renewer=yarn, realUser=,
> issueDate=1528777648605, maxDate=1529382448605, sequenceNumber=175,
> masterKeyId=2), Kind: kms-dt, Service: 172.27.68.203:9393, Ident: (kms-dt
> owner=hbase, renewer=yarn, realUser=, issueDate=1528777649149,
> maxDate=1529382449149, sequenceNumber=49, masterKeyId=2), Kind:
> HBASE_AUTH_TOKEN, Service: bc71e347-78ff-4f95-af44-006f9b549a84, Ident:
> (org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier@5),
> Kind: kms-dt, Service: 172.27.52.14:9393, Ident: (kms-dt owner=hbase,
> renewer=yarn, realUser=, issueDate=1528777648918, maxDate=1529382448918,
> sequenceNumber=50, masterKeyId=2)]
> 2018-06-12 04:27:31,477|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,477 INFO
> [main] conf.Configuration: found resource resource-types.xml at
> file:/etc/hadoop/3.0.0.0-1476/0/resource-types.xml
> 2018-06-12 04:27:31,527|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,527 INFO
> [main] impl.TimelineClientImpl: Timeline service address:
> ctr-e138-1518143905142-359429-01-04.hwx.site:8190
> 2018-06-12 04:27:32,563|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,562 INFO
> [main] impl.YarnClientImpl: Submitted application
> application_1528766389356_0044
> 2018-06-12 04:27:32,634|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,634 INFO
> [main] mapreduce.Job: The url to track the job:
> https://ctr-e138-1518143905142-359429-01-03.hwx.site:8090/proxy/application_1528766389356_0044/
> 2018-06-12 04:27:32,635|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,635 INFO
> [main] mapreduce.Job: Running job: job_1528766389356_0044
> 2018-06-12 04:27:44,807|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:44,806 INFO
> [main] mapreduce.Job: Job job_1528766389356_0044 running in uber mode : false
> 2018-06-12 04:27:44,809|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:44,809 INFO
> [main] mapreduce.Job: map 0% reduce 0%
> 2018-06-12 04:27:54,926|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:54,925 INFO
> [main] mapreduce.Job: map 5% reduce 0%
> 2018-06-12 04:27:56,950|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:56,950 INFO
> [main] mapreduce.Job: Task Id : attempt_1528766389356_0044_m_02_0,
> Status : FAILED
> 2018-06-12 04:27:56,979|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|Error:
> java.io.FileNotFoundException: File does not exist:
> hdfs://ns1/apps/hbase/data/oldWALs/ctr-e138-1518143905142-359429-01-04.hwx.site%2C16020%2C1528776085205.1528776160915
> 2018-06-12 04:27:56,979|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|at
> org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1583)
> 2018-06-12 04:27:56,980|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|at
> org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1576)
> 2018-06-12 04:27:56,980|INFO|MainThread
[jira] [Updated] (HBASE-21077) MR job launched by hbase incremental backup command failed with FileNotFoundException
[
https://issues.apache.org/jira/browse/HBASE-21077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-21077:
--
Attachment: HBASE-21077-v3.patch
> MR job launched by hbase incremental backup command failed with
> FileNotFoundException
> -
>
> Key: HBASE-21077
> URL: https://issues.apache.org/jira/browse/HBASE-21077
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Major
> Attachments: HBASE-21077-v1.patch, HBASE-21077-v2.patch,
> HBASE-21077-v3.patch
>
>
> Discovered during internal testing by Romil Choksi.
> MR job launched by hbase incremental backup command failed with
> FileNotFoundException
> from test console log
> {code}
> 2018-06-12 04:27:31,160|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,160 INFO
> [main] mapreduce.JobSubmitter: Submitting tokens for job:
> job_1528766389356_0044
> 2018-06-12 04:27:31,186|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,184 INFO
> [main] mapreduce.JobSubmitter: Executing with tokens: [Kind:
> HDFS_DELEGATION_TOKEN, Service: ha-hdfs:ns1, Ident: (token for hbase:
> HDFS_DELEGATION_TOKEN owner=hb...@example.com, renewer=yarn, realUser=,
> issueDate=1528777648605, maxDate=1529382448605, sequenceNumber=175,
> masterKeyId=2), Kind: kms-dt, Service: 172.27.68.203:9393, Ident: (kms-dt
> owner=hbase, renewer=yarn, realUser=, issueDate=1528777649149,
> maxDate=1529382449149, sequenceNumber=49, masterKeyId=2), Kind:
> HBASE_AUTH_TOKEN, Service: bc71e347-78ff-4f95-af44-006f9b549a84, Ident:
> (org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier@5),
> Kind: kms-dt, Service: 172.27.52.14:9393, Ident: (kms-dt owner=hbase,
> renewer=yarn, realUser=, issueDate=1528777648918, maxDate=1529382448918,
> sequenceNumber=50, masterKeyId=2)]
> 2018-06-12 04:27:31,477|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,477 INFO
> [main] conf.Configuration: found resource resource-types.xml at
> file:/etc/hadoop/3.0.0.0-1476/0/resource-types.xml
> 2018-06-12 04:27:31,527|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:31,527 INFO
> [main] impl.TimelineClientImpl: Timeline service address:
> ctr-e138-1518143905142-359429-01-04.hwx.site:8190
> 2018-06-12 04:27:32,563|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,562 INFO
> [main] impl.YarnClientImpl: Submitted application
> application_1528766389356_0044
> 2018-06-12 04:27:32,634|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,634 INFO
> [main] mapreduce.Job: The url to track the job:
> https://ctr-e138-1518143905142-359429-01-03.hwx.site:8090/proxy/application_1528766389356_0044/
> 2018-06-12 04:27:32,635|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:32,635 INFO
> [main] mapreduce.Job: Running job: job_1528766389356_0044
> 2018-06-12 04:27:44,807|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:44,806 INFO
> [main] mapreduce.Job: Job job_1528766389356_0044 running in uber mode : false
> 2018-06-12 04:27:44,809|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:44,809 INFO
> [main] mapreduce.Job: map 0% reduce 0%
> 2018-06-12 04:27:54,926|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:54,925 INFO
> [main] mapreduce.Job: map 5% reduce 0%
> 2018-06-12 04:27:56,950|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|2018-06-12 04:27:56,950 INFO
> [main] mapreduce.Job: Task Id : attempt_1528766389356_0044_m_02_0,
> Status : FAILED
> 2018-06-12 04:27:56,979|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|Error:
> java.io.FileNotFoundException: File does not exist:
> hdfs://ns1/apps/hbase/data/oldWALs/ctr-e138-1518143905142-359429-01-04.hwx.site%2C16020%2C1528776085205.1528776160915
> 2018-06-12 04:27:56,979|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|at
> org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1583)
> 2018-06-12 04:27:56,980|INFO|MainThread|machine.py:167 -
> run()||GUID=cb1d85c9-023c-4bc5-bf87-9c231c917eab|at
> org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1576)
> 2018-06-12 04:27:56,980|INFO|MainThread|mac
[jira] [Commented] (HBASE-21089) clean out stale / invalid PRs
[ https://issues.apache.org/jira/browse/HBASE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587909#comment-16587909 ] Josh Elser commented on HBASE-21089: +1 close 'em. > clean out stale / invalid PRs > - > > Key: HBASE-21089 > URL: https://issues.apache.org/jira/browse/HBASE-21089 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > > We haven't cleaned out PRs on github in a while. these can go: > * [#63|https://github.com/apache/hbase/pull/63] - no response since April 11 > * [#66|https://github.com/apache/hbase/pull/66] - no response since April 11 > * [#70|https://github.com/apache/hbase/pull/70] - the referenced JIRA, > HBASE-19547, has already closed. > * [#71|https://github.com/apache/hbase/pull/71] - no response since April 11 > * [#78|https://github.com/apache/hbase/pull/78] - no response since Jun 18th -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21091) Update Hadoop compatibility table
[
https://issues.apache.org/jira/browse/HBASE-21091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587907#comment-16587907
]
Sean Busbey commented on HBASE-21091:
-
is "unknown bad" the "NT" in the current table? if so, yeah yellow.
"known bad" ("X" in the current table?) should be red.
> Update Hadoop compatibility table
> -
>
> Key: HBASE-21091
> URL: https://issues.apache.org/jira/browse/HBASE-21091
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
>
> [https://lists.apache.org/thread.html/7016d322a07e96dccdb071041c37238e43d3df4f93e9515d52ccfafc@%3Cdev.hbase.apache.org%3E]
> covers some discussion around our Hadoop Version Compatibility table.
>
> A "leading" suggestion to make this more clear is to use a green/yellow/red
> (traffic-signal) style marking, instead of using specifics words/phrases (as
> they're often dependent on the interpretation of the reader).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19008) Add missing equals or hashCode method(s) to stock Filter implementations
[
https://issues.apache.org/jira/browse/HBASE-19008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587905#comment-16587905
]
Hadoop QA commented on HBASE-19008:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s{color} | {color:green} The patch hbase-client passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} hbase-server: The patch generated 0 new + 387
unchanged - 2 fixed = 387 total (was 389) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} The patch hbase-spark passed checkstyle {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
14s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 30s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
21s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}244m 55s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m
32s{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 3m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}304m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncRegionAdminApi |
| | hadoop.hbase.master.assignment.TestMergeTableRegionsProcedure |
| | hadoop.hbase.util.TestFromClientSide3WoUnsafe |
| |
hadoop.hbase.replication.TestSyncReplicationMoreLogsIn
[jira] [Commented] (HBASE-21091) Update Hadoop compatibility table
[ https://issues.apache.org/jira/browse/HBASE-21091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587906#comment-16587906 ] Josh Elser commented on HBASE-21091: Going with the Green/Yellow/Red model, I'm not sure how we'll go about differentiating between "known bad" and "unknown bad". e.g. "we know because of HDFS-, hbase will not work with that version" compared to "we haven't run tests with the release Hadoop-x.y.z" My gut reaction is that "known bad" should be "red" and "unknown bad" (operating under the assumption that Hadoop works as we expect) would be "yellow". > Update Hadoop compatibility table > - > > Key: HBASE-21091 > URL: https://issues.apache.org/jira/browse/HBASE-21091 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > > [https://lists.apache.org/thread.html/7016d322a07e96dccdb071041c37238e43d3df4f93e9515d52ccfafc@%3Cdev.hbase.apache.org%3E] > covers some discussion around our Hadoop Version Compatibility table. > > A "leading" suggestion to make this more clear is to use a green/yellow/red > (traffic-signal) style marking, instead of using specifics words/phrases (as > they're often dependent on the interpretation of the reader). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-20968) list_procedures_test fails due to no matching regex
[
https://issues.apache.org/jira/browse/HBASE-20968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-20968:
--
Assignee: (was: Ted Yu)
> list_procedures_test fails due to no matching regex
> ---
>
> Key: HBASE-20968
> URL: https://issues.apache.org/jira/browse/HBASE-20968
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Priority: Major
> Attachments: 20968.v2.txt, HBASE-20968-branch-2.1.patch,
> HBASE-20968.patch, org.apache.hadoop.hbase.client.TestShell-output.txt
>
>
> From test output against hadoop3:
> {code}
> 2018-07-28 12:04:24,838 DEBUG [Time-limited test]
> procedure2.ProcedureExecutor(948): Stored pid=12, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure
> 2018-07-28 12:04:24,864 INFO [RS-EventLoopGroup-1-3]
> ipc.ServerRpcConnection(556): Connection from 172.18.128.12:46918,
> version=3.0.0-SNAPSHOT, sasl=false, ugi=hbase (auth: SIMPLE),
> service=MasterService
> 2018-07-28 12:04:24,900 DEBUG [Thread-114] master.MasterRpcServices(1157):
> Checking to see if procedure is done pid=11
> ^[[38;5;196mF^[[0m
> ===
> Failure:
> ^[[48;5;124;38;5;231;1mtest_list_procedures(Hbase::ListProceduresTest)^[[0m
> src/test/ruby/shell/list_procedures_test.rb:65:in `block in
> test_list_procedures'
> 62: end
> 63: end
> 64:
> ^[[48;5;124;38;5;231;1m => 65: assert_equal(1, matching_lines)^[[0m
> 66: end
> 67: end
> 68: end
> <^[[48;5;34;38;5;231;1m1^[[0m> expected but was
> <^[[48;5;124;38;5;231;1m0^[[0m>
> ===
> ...
> 2018-07-28 12:04:25,374 INFO [PEWorker-9]
> procedure2.ProcedureExecutor(1316): Finished pid=12, state=SUCCESS,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure in 336msec
> {code}
> The completion of the ShellTestProcedure was after the assertion was raised.
> {code}
> def create_procedure_regexp(table_name)
> regexp_string = '[0-9]+ .*ShellTestProcedure SUCCESS.*' \
> {code}
> The regex used by the test isn't found in test output either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20968) list_procedures_test fails due to no matching regex
[
https://issues.apache.org/jira/browse/HBASE-20968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587900#comment-16587900
]
Ted Yu commented on HBASE-20968:
I am looking at:
https://builds.apache.org/job/HBASE-Find-Flaky-Tests/job/master/8/artifact/dashboard.html
> list_procedures_test fails due to no matching regex
> ---
>
> Key: HBASE-20968
> URL: https://issues.apache.org/jira/browse/HBASE-20968
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20968.v2.txt, HBASE-20968-branch-2.1.patch,
> HBASE-20968.patch, org.apache.hadoop.hbase.client.TestShell-output.txt
>
>
> From test output against hadoop3:
> {code}
> 2018-07-28 12:04:24,838 DEBUG [Time-limited test]
> procedure2.ProcedureExecutor(948): Stored pid=12, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure
> 2018-07-28 12:04:24,864 INFO [RS-EventLoopGroup-1-3]
> ipc.ServerRpcConnection(556): Connection from 172.18.128.12:46918,
> version=3.0.0-SNAPSHOT, sasl=false, ugi=hbase (auth: SIMPLE),
> service=MasterService
> 2018-07-28 12:04:24,900 DEBUG [Thread-114] master.MasterRpcServices(1157):
> Checking to see if procedure is done pid=11
> ^[[38;5;196mF^[[0m
> ===
> Failure:
> ^[[48;5;124;38;5;231;1mtest_list_procedures(Hbase::ListProceduresTest)^[[0m
> src/test/ruby/shell/list_procedures_test.rb:65:in `block in
> test_list_procedures'
> 62: end
> 63: end
> 64:
> ^[[48;5;124;38;5;231;1m => 65: assert_equal(1, matching_lines)^[[0m
> 66: end
> 67: end
> 68: end
> <^[[48;5;34;38;5;231;1m1^[[0m> expected but was
> <^[[48;5;124;38;5;231;1m0^[[0m>
> ===
> ...
> 2018-07-28 12:04:25,374 INFO [PEWorker-9]
> procedure2.ProcedureExecutor(1316): Finished pid=12, state=SUCCESS,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure in 336msec
> {code}
> The completion of the ShellTestProcedure was after the assertion was raised.
> {code}
> def create_procedure_regexp(table_name)
> regexp_string = '[0-9]+ .*ShellTestProcedure SUCCESS.*' \
> {code}
> The regex used by the test isn't found in test output either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21091) Update Hadoop compatibility table
Josh Elser created HBASE-21091: -- Summary: Update Hadoop compatibility table Key: HBASE-21091 URL: https://issues.apache.org/jira/browse/HBASE-21091 Project: HBase Issue Type: Improvement Components: documentation Reporter: Josh Elser Assignee: Josh Elser [https://lists.apache.org/thread.html/7016d322a07e96dccdb071041c37238e43d3df4f93e9515d52ccfafc@%3Cdev.hbase.apache.org%3E] covers some discussion around our Hadoop Version Compatibility table. A "leading" suggestion to make this more clear is to use a green/yellow/red (traffic-signal) style marking, instead of using specifics words/phrases (as they're often dependent on the interpretation of the reader). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20666) Unsuccessful table creation leaves entry in rsgroup meta table
[
https://issues.apache.org/jira/browse/HBASE-20666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587896#comment-16587896
]
Ted Yu commented on HBASE-20666:
For #1, I see that you have an assertion in finally block which is equivalent
to what I suggested.
Basically you can put Assert.fail() call following table creation since you
know that table creation would throw exception.
> Unsuccessful table creation leaves entry in rsgroup meta table
> --
>
> Key: HBASE-20666
> URL: https://issues.apache.org/jira/browse/HBASE-20666
> Project: HBase
> Issue Type: Bug
>Reporter: Biju Nair
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-20666.master.001.patch,
> HBASE-20666.master.002.patch
>
>
> If a table creation fails in a cluster enabled with {{rsgroup}} feature, the
> table is still listed as part of {{default}} rsgroup.
> To recreate the scenario:
> - Create a namespace (NS) with number of region limit
> - Create table in the NS which satisfies the region limit by pre-splitting
> - Create a new table in the NS which will fail
> - {{list_rsgroup}} will show the table being part of {{default}} rsgroup and
> data can be found in {{hbase:rsgroup}} table
> Would be good to revert the entry when the table creation fails or a script
> to clean up the metadata.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21088) HStoreFile should be closed in HStore#hasReferences
[
https://issues.apache.org/jira/browse/HBASE-21088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587894#comment-16587894
]
Hadoop QA commented on HBASE-21088:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
1s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.7.0/precommit-patchnames for
instructions. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
2s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
51s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 12s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}128m 25s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}170m 9s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.regionserver.TestSyncReplicationShipperQuit |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21088 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936476/21088.v1.txt |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 69423d60acb3 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 588ff921c1 |
| maven | version: Apache Maven 3.5.4
(1edded0938998ed
[jira] [Updated] (HBASE-21031) Memory leak if replay edits failed during region opening
[
https://issues.apache.org/jira/browse/HBASE-21031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-21031:
--
Attachment: HBASE-21031.branch-2.0.006.patch
> Memory leak if replay edits failed during region opening
>
>
> Key: HBASE-21031
> URL: https://issues.apache.org/jira/browse/HBASE-21031
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Attachments: HBASE-21031.branch-2.0.001.patch,
> HBASE-21031.branch-2.0.002.patch, HBASE-21031.branch-2.0.003.patch,
> HBASE-21031.branch-2.0.004.patch, HBASE-21031.branch-2.0.005.patch,
> HBASE-21031.branch-2.0.006.patch, HBASE-21031.branch-2.0.006.patch,
> memoryleak.png
>
>
> Due to HBASE-21029, when replaying edits with a lot of same cells, the
> memstore won't flush, a exception will throw when all heap space was used:
> {code}
> 2018-08-06 15:52:27,590 ERROR
> [RS_OPEN_REGION-regionserver/hb-bp10cw4ejoy0a2f3f-009:16020-2]
> handler.OpenRegionHandler(302): Failed open of
> region=hbase_test,dffa78,1531227033378.cbf9a2daf3aaa0c7e931e9c9a7b53f41.,
> starting to roll back the global memstore size.
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at
> org.apache.hadoop.hbase.regionserver.OnheapChunk.allocateDataBuffer(OnheapChunk.java:41)
> at org.apache.hadoop.hbase.regionserver.Chunk.init(Chunk.java:104)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:226)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:180)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:163)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.getOrMakeChunk(MemStoreLABImpl.java:273)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:148)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:111)
> at
> org.apache.hadoop.hbase.regionserver.Segment.maybeCloneWithAllocator(Segment.java:178)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.maybeCloneWithAllocator(AbstractMemStore.java:287)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.add(AbstractMemStore.java:107)
> at org.apache.hadoop.hbase.regionserver.HStore.add(HStore.java:706)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.restoreEdit(HRegion.java:5494)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEdits(HRegion.java:4608)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEditsIfAny(HRegion.java:4404)
> {code}
> After this exception, the memstore did not roll back, and since MSLAB is
> used, all the chunk allocated won't release for ever. Those memory is leak
> forever...
> We need to rollback the memory if open region fails(For now, only global
> memstore size is decreased after failure).
> Another problem is that we use replayEditsPerRegion in RegionServerAccounting
> to record how many memory used during replaying. And decrease the global
> memstore size if replay fails. This is not right, since during replaying, we
> may also flush the memstore, the size in the map of replayEditsPerRegion is
> not accurate at all!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21089) clean out stale / invalid PRs
[ https://issues.apache.org/jira/browse/HBASE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587893#comment-16587893 ] Sean Busbey commented on HBASE-21089: - no I don't think so. That discussion is active and on going and is about changes to how we as a project make it easier for folks in the future to contribute via PR on GitHub. These are issues where we either have already completed the work and forgot to close things or where the contributor has gone silent for 2-4 _months_. They're already gone. > clean out stale / invalid PRs > - > > Key: HBASE-21089 > URL: https://issues.apache.org/jira/browse/HBASE-21089 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > > We haven't cleaned out PRs on github in a while. these can go: > * [#63|https://github.com/apache/hbase/pull/63] - no response since April 11 > * [#66|https://github.com/apache/hbase/pull/66] - no response since April 11 > * [#70|https://github.com/apache/hbase/pull/70] - the referenced JIRA, > HBASE-19547, has already closed. > * [#71|https://github.com/apache/hbase/pull/71] - no response since April 11 > * [#78|https://github.com/apache/hbase/pull/78] - no response since Jun 18th -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21031) Memory leak if replay edits failed during region opening
[
https://issues.apache.org/jira/browse/HBASE-21031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587891#comment-16587891
]
stack commented on HBASE-21031:
---
Retry while [~allan163] is offline.
> Memory leak if replay edits failed during region opening
>
>
> Key: HBASE-21031
> URL: https://issues.apache.org/jira/browse/HBASE-21031
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Attachments: HBASE-21031.branch-2.0.001.patch,
> HBASE-21031.branch-2.0.002.patch, HBASE-21031.branch-2.0.003.patch,
> HBASE-21031.branch-2.0.004.patch, HBASE-21031.branch-2.0.005.patch,
> HBASE-21031.branch-2.0.006.patch, HBASE-21031.branch-2.0.006.patch,
> memoryleak.png
>
>
> Due to HBASE-21029, when replaying edits with a lot of same cells, the
> memstore won't flush, a exception will throw when all heap space was used:
> {code}
> 2018-08-06 15:52:27,590 ERROR
> [RS_OPEN_REGION-regionserver/hb-bp10cw4ejoy0a2f3f-009:16020-2]
> handler.OpenRegionHandler(302): Failed open of
> region=hbase_test,dffa78,1531227033378.cbf9a2daf3aaa0c7e931e9c9a7b53f41.,
> starting to roll back the global memstore size.
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at
> org.apache.hadoop.hbase.regionserver.OnheapChunk.allocateDataBuffer(OnheapChunk.java:41)
> at org.apache.hadoop.hbase.regionserver.Chunk.init(Chunk.java:104)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:226)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:180)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:163)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.getOrMakeChunk(MemStoreLABImpl.java:273)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:148)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:111)
> at
> org.apache.hadoop.hbase.regionserver.Segment.maybeCloneWithAllocator(Segment.java:178)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.maybeCloneWithAllocator(AbstractMemStore.java:287)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.add(AbstractMemStore.java:107)
> at org.apache.hadoop.hbase.regionserver.HStore.add(HStore.java:706)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.restoreEdit(HRegion.java:5494)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEdits(HRegion.java:4608)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEditsIfAny(HRegion.java:4404)
> {code}
> After this exception, the memstore did not roll back, and since MSLAB is
> used, all the chunk allocated won't release for ever. Those memory is leak
> forever...
> We need to rollback the memory if open region fails(For now, only global
> memstore size is decreased after failure).
> Another problem is that we use replayEditsPerRegion in RegionServerAccounting
> to record how many memory used during replaying. And decrease the global
> memstore size if replay fails. This is not right, since during replaying, we
> may also flush the memstore, the size in the map of replayEditsPerRegion is
> not accurate at all!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21039) Procedure worker should not quit when getting unexpected error
[ https://issues.apache.org/jira/browse/HBASE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587890#comment-16587890 ] stack commented on HBASE-21039: --- Yeah, should it be "Procedure terminating UNNATURALLY..." rather than worker? Otherwise patch LGTM. > Procedure worker should not quit when getting unexpected error > -- > > Key: HBASE-21039 > URL: https://issues.apache.org/jira/browse/HBASE-21039 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-21039.branch-2.0.001.patch > > > Since for either the old RTP or the new TRSP introduced in HBASE-20881, we > could end with FAILED_OPEN and set the procedure as failure, it is possible > that we will call rollback for procedures which can not be rollbacked, and > throw UnsupportedOperationException. > Before we find out a way to deal with this, I think at least we should make > the Procedure worker does not quit when getting these errors, as for the core > workers there is no way to get them back... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20968) list_procedures_test fails due to no matching regex
[
https://issues.apache.org/jira/browse/HBASE-20968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587874#comment-16587874
]
stack commented on HBASE-20968:
---
Which dashboard you looking at? I'd removed the test from all but Master FYI in
subissue of HBASE-21043
> list_procedures_test fails due to no matching regex
> ---
>
> Key: HBASE-20968
> URL: https://issues.apache.org/jira/browse/HBASE-20968
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20968.v2.txt, HBASE-20968-branch-2.1.patch,
> HBASE-20968.patch, org.apache.hadoop.hbase.client.TestShell-output.txt
>
>
> From test output against hadoop3:
> {code}
> 2018-07-28 12:04:24,838 DEBUG [Time-limited test]
> procedure2.ProcedureExecutor(948): Stored pid=12, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure
> 2018-07-28 12:04:24,864 INFO [RS-EventLoopGroup-1-3]
> ipc.ServerRpcConnection(556): Connection from 172.18.128.12:46918,
> version=3.0.0-SNAPSHOT, sasl=false, ugi=hbase (auth: SIMPLE),
> service=MasterService
> 2018-07-28 12:04:24,900 DEBUG [Thread-114] master.MasterRpcServices(1157):
> Checking to see if procedure is done pid=11
> ^[[38;5;196mF^[[0m
> ===
> Failure:
> ^[[48;5;124;38;5;231;1mtest_list_procedures(Hbase::ListProceduresTest)^[[0m
> src/test/ruby/shell/list_procedures_test.rb:65:in `block in
> test_list_procedures'
> 62: end
> 63: end
> 64:
> ^[[48;5;124;38;5;231;1m => 65: assert_equal(1, matching_lines)^[[0m
> 66: end
> 67: end
> 68: end
> <^[[48;5;34;38;5;231;1m1^[[0m> expected but was
> <^[[48;5;124;38;5;231;1m0^[[0m>
> ===
> ...
> 2018-07-28 12:04:25,374 INFO [PEWorker-9]
> procedure2.ProcedureExecutor(1316): Finished pid=12, state=SUCCESS,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure in 336msec
> {code}
> The completion of the ShellTestProcedure was after the assertion was raised.
> {code}
> def create_procedure_regexp(table_name)
> regexp_string = '[0-9]+ .*ShellTestProcedure SUCCESS.*' \
> {code}
> The regex used by the test isn't found in test output either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21032) ScanResponses contain only one cell each
[ https://issues.apache.org/jira/browse/HBASE-21032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587872#comment-16587872 ] stack commented on HBASE-21032: --- Is your issue what is on the tail of HBASE-20671 [~timoha]? Thanks. > ScanResponses contain only one cell each > > > Key: HBASE-21032 > URL: https://issues.apache.org/jira/browse/HBASE-21032 > Project: HBase > Issue Type: Bug > Components: Performance, Scanners >Affects Versions: 2.1.0 > Environment: HBase 2.1.0 > Hadoop 2.8.4 > Java 8 >Reporter: Andrey Elenskiy >Assignee: Andrey Elenskiy >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: App.java, HBASE-21032-v1.patch, HBASE-21032-v1.patch, > HBASE-21032.patch > > > I have a long row with a bunch of columns that I'm scanning with > setAllowPartialResults(true). In the response I'm getting the first partial > ScanResponse being around 2MB with multiple cells while all of the consequent > ones being 1 cell per ScanResponse. After digging more, I found that each of > those single cell ScanResponse partials are preceded by a heartbeat (zero > cells). This results in two requests per cell to a regionserver. > I've attached code to reproduce it on hbase version 2.1.0 (it works as > expected on 2.0.0 and 2.0.1). > [^App.java] > I'm fairly certain it's a serverside issue as > [gohbase|https://github.com/tsuna/gohbase] client is having the same issue. I > have not tried to reproduce this with multi-row scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21085) Adding getter methods to some private fields in ProcedureV2 module
[ https://issues.apache.org/jira/browse/HBASE-21085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587867#comment-16587867 ] stack commented on HBASE-21085: --- >From the get-go, Procedure and related classes, have worked hard to keep >internals private exposing the minimum. For example, though we show Procedures >in the UI and in the shell, its a facade only -- a JSON representation -- >rather than allow the actual classes show client-side. Thinking was that we'd >encapsulate as much as possible because the machinery too specialized to allow >views or external manipulation (caveat HBCK2 of course... maybe this is why >you are making these changes...). Thanks [~allan163] > Adding getter methods to some private fields in ProcedureV2 module > --- > > Key: HBASE-21085 > URL: https://issues.apache.org/jira/browse/HBASE-21085 > Project: HBase > Issue Type: Sub-task >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-21085.branch-2.0.001.patch > > > Many fields are private in ProcedureV2 module. adding getter method to them > making them more transparent. > And some classes are private too, making it public. > Some class is private in ProcecudeV2 module, making it public. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21032) ScanResponses contain only one cell each
[
https://issues.apache.org/jira/browse/HBASE-21032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587865#comment-16587865
]
Andrey Elenskiy commented on HBASE-21032:
-
I'm hitting another issue I've had before with 2.1 when upgrading dev cluster.
HBase master is stuck initializing because it can't get to hbase:namespace
region:
{{18/08/21 18:52:28 INFO client.RpcRetryingCallerImpl: Call exception,
tries=32, retries=46, started=471534 ms ago, cancelled=false,
msg=org.apache.hadoop.hbase.NotServingRegionException:
hbase:namespace,,1508805323559.2ad4d95f7b9d9ba0d746b8da50a7f9a7. is not online
on regionserver-0,16020,1534877035908}}
{{ at
org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:3287)}}
{{ at
org.apache.hadoop.hbase.regionserver.HRegionServer.getRegion(HRegionServer.java:3264)}}
{{ at
org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegion(RSRpcServices.java:1428)}}
{{ at
org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2443)}}
{{ at
org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41998)}}
{{ at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)}}
{{ at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)}}
{{ at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)}}
{{ at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)}}
{{, details=row 'default' on table 'hbase:namespace' at
region=hbase:namespace,,1508805323559.2ad4d95f7b9d9ba0d746b8da50a7f9a7.,
hostname=regionserver-0,16020,1534538897512, seqNum=172}}
And there's nothing about hbase:namespace in regionserver-0's logs. Don't
really know how to work around this.
> ScanResponses contain only one cell each
>
>
> Key: HBASE-21032
> URL: https://issues.apache.org/jira/browse/HBASE-21032
> Project: HBase
> Issue Type: Bug
> Components: Performance, Scanners
>Affects Versions: 2.1.0
> Environment: HBase 2.1.0
> Hadoop 2.8.4
> Java 8
>Reporter: Andrey Elenskiy
>Assignee: Andrey Elenskiy
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1
>
> Attachments: App.java, HBASE-21032-v1.patch, HBASE-21032-v1.patch,
> HBASE-21032.patch
>
>
> I have a long row with a bunch of columns that I'm scanning with
> setAllowPartialResults(true). In the response I'm getting the first partial
> ScanResponse being around 2MB with multiple cells while all of the consequent
> ones being 1 cell per ScanResponse. After digging more, I found that each of
> those single cell ScanResponse partials are preceded by a heartbeat (zero
> cells). This results in two requests per cell to a regionserver.
> I've attached code to reproduce it on hbase version 2.1.0 (it works as
> expected on 2.0.0 and 2.0.1).
> [^App.java]
> I'm fairly certain it's a serverside issue as
> [gohbase|https://github.com/tsuna/gohbase] client is having the same issue. I
> have not tried to reproduce this with multi-row scan.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20968) list_procedures_test fails due to no matching regex
[
https://issues.apache.org/jira/browse/HBASE-20968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587864#comment-16587864
]
Ted Yu commented on HBASE-20968:
Earlier, I had a copy of test output showing what the test script looks for,
except there was no hash in the line.
I cannot find the output now. This particular test doesn't show up on flaky
dashboard either.
> list_procedures_test fails due to no matching regex
> ---
>
> Key: HBASE-20968
> URL: https://issues.apache.org/jira/browse/HBASE-20968
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20968.v2.txt, HBASE-20968-branch-2.1.patch,
> HBASE-20968.patch, org.apache.hadoop.hbase.client.TestShell-output.txt
>
>
> From test output against hadoop3:
> {code}
> 2018-07-28 12:04:24,838 DEBUG [Time-limited test]
> procedure2.ProcedureExecutor(948): Stored pid=12, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure
> 2018-07-28 12:04:24,864 INFO [RS-EventLoopGroup-1-3]
> ipc.ServerRpcConnection(556): Connection from 172.18.128.12:46918,
> version=3.0.0-SNAPSHOT, sasl=false, ugi=hbase (auth: SIMPLE),
> service=MasterService
> 2018-07-28 12:04:24,900 DEBUG [Thread-114] master.MasterRpcServices(1157):
> Checking to see if procedure is done pid=11
> ^[[38;5;196mF^[[0m
> ===
> Failure:
> ^[[48;5;124;38;5;231;1mtest_list_procedures(Hbase::ListProceduresTest)^[[0m
> src/test/ruby/shell/list_procedures_test.rb:65:in `block in
> test_list_procedures'
> 62: end
> 63: end
> 64:
> ^[[48;5;124;38;5;231;1m => 65: assert_equal(1, matching_lines)^[[0m
> 66: end
> 67: end
> 68: end
> <^[[48;5;34;38;5;231;1m1^[[0m> expected but was
> <^[[48;5;124;38;5;231;1m0^[[0m>
> ===
> ...
> 2018-07-28 12:04:25,374 INFO [PEWorker-9]
> procedure2.ProcedureExecutor(1316): Finished pid=12, state=SUCCESS,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure in 336msec
> {code}
> The completion of the ShellTestProcedure was after the assertion was raised.
> {code}
> def create_procedure_regexp(table_name)
> regexp_string = '[0-9]+ .*ShellTestProcedure SUCCESS.*' \
> {code}
> The regex used by the test isn't found in test output either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20968) list_procedures_test fails due to no matching regex
[
https://issues.apache.org/jira/browse/HBASE-20968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587854#comment-16587854
]
stack commented on HBASE-20968:
---
[~yuzhih...@gmail.com] Question above for you.
[~Apache9] Just commit. I'll keep an eye on it after it goes in. It doesn't
fail for me locally. I saw it in the nightlies and flakies dashboard. Thanks
sir.
> list_procedures_test fails due to no matching regex
> ---
>
> Key: HBASE-20968
> URL: https://issues.apache.org/jira/browse/HBASE-20968
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20968.v2.txt, HBASE-20968-branch-2.1.patch,
> HBASE-20968.patch, org.apache.hadoop.hbase.client.TestShell-output.txt
>
>
> From test output against hadoop3:
> {code}
> 2018-07-28 12:04:24,838 DEBUG [Time-limited test]
> procedure2.ProcedureExecutor(948): Stored pid=12, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure
> 2018-07-28 12:04:24,864 INFO [RS-EventLoopGroup-1-3]
> ipc.ServerRpcConnection(556): Connection from 172.18.128.12:46918,
> version=3.0.0-SNAPSHOT, sasl=false, ugi=hbase (auth: SIMPLE),
> service=MasterService
> 2018-07-28 12:04:24,900 DEBUG [Thread-114] master.MasterRpcServices(1157):
> Checking to see if procedure is done pid=11
> ^[[38;5;196mF^[[0m
> ===
> Failure:
> ^[[48;5;124;38;5;231;1mtest_list_procedures(Hbase::ListProceduresTest)^[[0m
> src/test/ruby/shell/list_procedures_test.rb:65:in `block in
> test_list_procedures'
> 62: end
> 63: end
> 64:
> ^[[48;5;124;38;5;231;1m => 65: assert_equal(1, matching_lines)^[[0m
> 66: end
> 67: end
> 68: end
> <^[[48;5;34;38;5;231;1m1^[[0m> expected but was
> <^[[48;5;124;38;5;231;1m0^[[0m>
> ===
> ...
> 2018-07-28 12:04:25,374 INFO [PEWorker-9]
> procedure2.ProcedureExecutor(1316): Finished pid=12, state=SUCCESS,
> hasLock=false; org.apache.hadoop.hbase.client.procedure.
> ShellTestProcedure in 336msec
> {code}
> The completion of the ShellTestProcedure was after the assertion was raised.
> {code}
> def create_procedure_regexp(table_name)
> regexp_string = '[0-9]+ .*ShellTestProcedure SUCCESS.*' \
> {code}
> The regex used by the test isn't found in test output either.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21089) clean out stale / invalid PRs
[ https://issues.apache.org/jira/browse/HBASE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587837#comment-16587837 ] Mike Drob commented on HBASE-21089: --- Is this impacted by the discussion on https://lists.apache.org/thread.html/4de8db62ec2091e69c71a63d542bc1eb668e39d62f2983cc2f40c1b5@%3Cdev.hbase.apache.org%3E > clean out stale / invalid PRs > - > > Key: HBASE-21089 > URL: https://issues.apache.org/jira/browse/HBASE-21089 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > > We haven't cleaned out PRs on github in a while. these can go: > * [#63|https://github.com/apache/hbase/pull/63] - no response since April 11 > * [#66|https://github.com/apache/hbase/pull/66] - no response since April 11 > * [#70|https://github.com/apache/hbase/pull/70] - the referenced JIRA, > HBASE-19547, has already closed. > * [#71|https://github.com/apache/hbase/pull/71] - no response since April 11 > * [#78|https://github.com/apache/hbase/pull/78] - no response since Jun 18th -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20666) Unsuccessful table creation leaves entry in rsgroup meta table
[
https://issues.apache.org/jira/browse/HBASE-20666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587830#comment-16587830
]
Xu Cang commented on HBASE-20666:
-
{quote}Please add assertion of failure within the try block after the
createTable() call since exception is expected.
{quote}
I am not sure what I can do within try block after createTable() call. (?)
As you said also, it will throw an exception, so I am catching it in the catch
block. Besides, createTable() does not return anything, what should I assert in
the try block? thanks.
I will address the other 2 comments. thanks for the review.
[~yuzhih...@gmail.com]
> Unsuccessful table creation leaves entry in rsgroup meta table
> --
>
> Key: HBASE-20666
> URL: https://issues.apache.org/jira/browse/HBASE-20666
> Project: HBase
> Issue Type: Bug
>Reporter: Biju Nair
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-20666.master.001.patch,
> HBASE-20666.master.002.patch
>
>
> If a table creation fails in a cluster enabled with {{rsgroup}} feature, the
> table is still listed as part of {{default}} rsgroup.
> To recreate the scenario:
> - Create a namespace (NS) with number of region limit
> - Create table in the NS which satisfies the region limit by pre-splitting
> - Create a new table in the NS which will fail
> - {{list_rsgroup}} will show the table being part of {{default}} rsgroup and
> data can be found in {{hbase:rsgroup}} table
> Would be good to revert the entry when the table creation fails or a script
> to clean up the metadata.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21084) When cloning a snapshot including a split parent region, the split parent region of the cloned table will be online
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587827#comment-16587827
]
Hadoop QA commented on HBASE-21084:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
27s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} hbase-server: The patch generated 0 new + 8
unchanged - 7 fixed = 8 total (was 15) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
15s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 27s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}125m
46s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}161m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21084 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936467/HBASE-21084.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 46875eb7f2c3 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 588ff921c1 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/14117/testReport/ |
| Max. process+thread count | 4524 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/14117/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.o
[jira] [Commented] (HBASE-20306) LoadTestTool does not print summary at end of run
[ https://issues.apache.org/jira/browse/HBASE-20306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587823#comment-16587823 ] Colin Garcia commented on HBASE-20306: -- [~jojochuang] I was wondering what progress you've made? Looking to take a look into this as well :) > LoadTestTool does not print summary at end of run > - > > Key: HBASE-20306 > URL: https://issues.apache.org/jira/browse/HBASE-20306 > Project: HBase > Issue Type: Bug > Components: tooling >Reporter: Mike Drob >Assignee: Wei-Chiu Chuang >Priority: Major > Labels: beginner > > ltt currently prints status as it goes, but doesn't give a nice summary of > what happened so users have to infer it from the last status line printed. > Would be nice to print a real summary with statistics about what was run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21079) Non admin can split or compact from master UI even when the cluster is secured
[ https://issues.apache.org/jira/browse/HBASE-21079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krish Dey resolved HBASE-21079. --- Resolution: Not A Problem Release Note: need to add following in secure cluster to prevent it hbase.master.ui.readonly true > Non admin can split or compact from master UI even when the cluster is secured > -- > > Key: HBASE-21079 > URL: https://issues.apache.org/jira/browse/HBASE-21079 > Project: HBase > Issue Type: Bug >Reporter: Krish Dey >Priority: Major > > Go to any table from table.jsp and try compact/split a table region. > Even when the hbase is secure any user can split/compact the table. > The same behavior is not from the hbase shell and work as expected. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587817#comment-16587817
]
Ted Yu commented on HBASE-21076:
Patch for master looks good me.
Thanks for working on this, Sean.
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch, HBASE-21076.1.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587809#comment-16587809
]
Sean Busbey commented on HBASE-21076:
-
[~Apache9] last 4 runs came back green:
https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/job/master/8/artifact/dashboard.html#job_2
let me know when there are enough green runs for you to be comfortable with me
backporting.
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch, HBASE-21076.1.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20890) PE filterScan seems to be stuck forever
[
https://issues.apache.org/jira/browse/HBASE-20890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587787#comment-16587787
]
Abhishek Goyal commented on HBASE-20890:
Thanks [~busbey] and [~vik.karma]!
> PE filterScan seems to be stuck forever
> ---
>
> Key: HBASE-20890
> URL: https://issues.apache.org/jira/browse/HBASE-20890
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.3
>Reporter: Vikas Vishwakarma
>Priority: Minor
>
> Command Used
> {code:java}
> ~/current/bigdata-hbase/hbase/hbase/bin/hbase pe --nomapred randomWrite 1 >
> write 2>&1
> ~/current/bigdata-hbase/hbase/hbase/bin/hbase pe --nomapred filterScan 1 >
> filterScan 2>&1
> {code}
>
> Output
> This kept running for several hours just printing the below messages in logs
>
> {code:java}
> -bash-4.1$ grep "Advancing internal scanner to startKey" filterScan.1 | head
> 2018-07-13 10:44:45,188 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-13 10:44:45,976 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-13 10:44:46,695 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> .
> -bash-4.1$ grep "Advancing internal scanner to startKey" filterScan.1 | tail
> 2018-07-15 06:20:22,353 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-15 06:20:23,044 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-15 06:20:23,768 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-20890) PE filterScan seems to be stuck forever
[
https://issues.apache.org/jira/browse/HBASE-20890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Goyal reassigned HBASE-20890:
--
Assignee: Abhishek Goyal
> PE filterScan seems to be stuck forever
> ---
>
> Key: HBASE-20890
> URL: https://issues.apache.org/jira/browse/HBASE-20890
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.3
>Reporter: Vikas Vishwakarma
>Assignee: Abhishek Goyal
>Priority: Minor
>
> Command Used
> {code:java}
> ~/current/bigdata-hbase/hbase/hbase/bin/hbase pe --nomapred randomWrite 1 >
> write 2>&1
> ~/current/bigdata-hbase/hbase/hbase/bin/hbase pe --nomapred filterScan 1 >
> filterScan 2>&1
> {code}
>
> Output
> This kept running for several hours just printing the below messages in logs
>
> {code:java}
> -bash-4.1$ grep "Advancing internal scanner to startKey" filterScan.1 | head
> 2018-07-13 10:44:45,188 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-13 10:44:45,976 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-13 10:44:46,695 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> .
> -bash-4.1$ grep "Advancing internal scanner to startKey" filterScan.1 | tail
> 2018-07-15 06:20:22,353 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-15 06:20:23,044 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-15 06:20:23,768 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21090) Default WebUI to read-only when cluster has kerberos authn but no webUI authn
[
https://issues.apache.org/jira/browse/HBASE-21090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-21090:
---
Hadoop Flags: Incompatible change
Tentatively tagging this with the incompatible change as it would change the
existing semantics (so we don't forget to do release notes later, assuming
folks agree with me).
> Default WebUI to read-only when cluster has kerberos authn but no webUI authn
> -
>
> Key: HBASE-21090
> URL: https://issues.apache.org/jira/browse/HBASE-21090
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Reporter: Josh Elser
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: 3.0.0
>
>
> Was chatting with Artem about this. I think we can do a little bit better for
> default "security-related" configurations.
> We have the {{hbase.master.ui.readonly}} configuration property removes some
> options from the web UI that might change the state of the cluster (e.g.
> region distribution, snapshots). We default this to be {{false}} in all cases
> now.
> I suggest that when \{{hbase.security.authentication}}=kerberos but
> {{hbase.security.authentication.ui}}=null (undefined), we default
> {{hbase.master.ui.readonly=true}}. This would force users to opt-in to a
> scenario that may let an unauthenticated user manipulate the system (instead
> of opt-out).
> Artem also mentioned he thinks he could implement this, so assigning to him.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21090) Default WebUI to read-only when cluster has kerberos authn but no webUI authn
Josh Elser created HBASE-21090:
--
Summary: Default WebUI to read-only when cluster has kerberos
authn but no webUI authn
Key: HBASE-21090
URL: https://issues.apache.org/jira/browse/HBASE-21090
Project: HBase
Issue Type: Improvement
Components: UI
Reporter: Josh Elser
Assignee: Artem Ervits
Fix For: 3.0.0
Was chatting with Artem about this. I think we can do a little bit better for
default "security-related" configurations.
We have the {{hbase.master.ui.readonly}} configuration property removes some
options from the web UI that might change the state of the cluster (e.g. region
distribution, snapshots). We default this to be {{false}} in all cases now.
I suggest that when \{{hbase.security.authentication}}=kerberos but
{{hbase.security.authentication.ui}}=null (undefined), we default
{{hbase.master.ui.readonly=true}}. This would force users to opt-in to a
scenario that may let an unauthenticated user manipulate the system (instead of
opt-out).
Artem also mentioned he thinks he could implement this, so assigning to him.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21069) NPE in StoreScanner.updateReaders causes RS to crash
[
https://issues.apache.org/jira/browse/HBASE-21069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-21069:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
> NPE in StoreScanner.updateReaders causes RS to crash
> -
>
> Key: HBASE-21069
> URL: https://issues.apache.org/jira/browse/HBASE-21069
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Thomas D'Silva
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 1.5.0, 1.3.3, 1.4.7
>
> Attachments: HBASE-21069-branch-1.patch, HBASE-21069-branch-1.patch
>
>
> I see the following NPE in the region server log for a table that is taking
> heavy writes.
> I am not sure how the {{memStoreScanners}} variable gets set to null.
> {code}
> 2018-08-17 19:59:23,682 DEBUG [MemStoreFlusher.1]
> regionserver.HRegionFileSystem - Committing store file ...
> 2018-08-17 19:59:23,684 INFO [MemStoreFlusher.1] regionserver.HStore - Added
> hdfs://, entries=919170, sequenceid=275114, filesize=22.6 M
> 2018-08-17 19:59:23,689 FATAL [MemStoreFlusher.1] regionserver.HRegionServer
> - ABORTING region server
> iotperf1dchbase1a-dnds22-2-prd.eng.sfdc.net,60020,1533915690501: Replay of
> WAL required. Forcing server shutdown
> org.apache.hadoop.hbase.DroppedSnapshotException: region: ..
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2581)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2258)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2220)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:2106)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.flush(HRegion.java:2031)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:508)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:478)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$900(MemStoreFlusher.java:76)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:264)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at java.util.ArrayList.(ArrayList.java:177)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.updateReaders(StoreScanner.java:827)
> at
> org.apache.hadoop.hbase.regionserver.HStore.notifyChangedReadersObservers(HStore.java:1160)
> at
> org.apache.hadoop.hbase.regionserver.HStore.updateStorefiles(HStore.java:1133)
> at
> org.apache.hadoop.hbase.regionserver.HStore.access$900(HStore.java:120)
> at
> org.apache.hadoop.hbase.regionserver.HStore$StoreFlusherImpl.commit(HStore.java:2487)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2536)
> ... 9 more
> 2018-08-17 19:59:23,692 FATAL [MemStoreFlusher.1] regionserver.HRegionServer
> - RegionServer abort: loaded coprocessors are:
> [org.apache.hadoop.hbase.security.access.AccessController,
> org.apache.phoenix.coprocessor.ScanRegionObserver,
> org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver,
> org.apache.phoenix.hbase.index.Indexer,
> org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver,
> org.apache.hadoop.hbase.security.token.TokenProvider,
> org.apache.phoenix.coprocessor.ServerCachingEndpointImpl]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21032) ScanResponses contain only one cell each
[ https://issues.apache.org/jira/browse/HBASE-21032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587732#comment-16587732 ] Andrey Elenskiy commented on HBASE-21032: - Sure, giving it a try by applying to 5a40eae63e290c8a12b1e7d4dd01fc98ba09573d of branch-2.1 and deploying onto our dev. > ScanResponses contain only one cell each > > > Key: HBASE-21032 > URL: https://issues.apache.org/jira/browse/HBASE-21032 > Project: HBase > Issue Type: Bug > Components: Performance, Scanners >Affects Versions: 2.1.0 > Environment: HBase 2.1.0 > Hadoop 2.8.4 > Java 8 >Reporter: Andrey Elenskiy >Assignee: Andrey Elenskiy >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: App.java, HBASE-21032-v1.patch, HBASE-21032-v1.patch, > HBASE-21032.patch > > > I have a long row with a bunch of columns that I'm scanning with > setAllowPartialResults(true). In the response I'm getting the first partial > ScanResponse being around 2MB with multiple cells while all of the consequent > ones being 1 cell per ScanResponse. After digging more, I found that each of > those single cell ScanResponse partials are preceded by a heartbeat (zero > cells). This results in two requests per cell to a regionserver. > I've attached code to reproduce it on hbase version 2.1.0 (it works as > expected on 2.0.0 and 2.0.1). > [^App.java] > I'm fairly certain it's a serverside issue as > [gohbase|https://github.com/tsuna/gohbase] client is having the same issue. I > have not tried to reproduce this with multi-row scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20705) Having RPC Quota on a table prevents Space quota to be recreated/removed
[
https://issues.apache.org/jira/browse/HBASE-20705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-20705:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks much, Stack.
Resolving as this has landed everywhere. Thanks for the unit tests, Sakthi.
> Having RPC Quota on a table prevents Space quota to be recreated/removed
>
>
> Key: HBASE-20705
> URL: https://issues.apache.org/jira/browse/HBASE-20705
> Project: HBase
> Issue Type: Bug
>Reporter: Biju Nair
>Assignee: Sakthi
>Priority: Major
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: hbase-20705.master.001.patch
>
>
> * Property {{hbase.quota.remove.on.table.delete}} is set to {{true}} by
> default
> * Create a table and set RPC and Space quota
> {noformat}
> hbase(main):022:0> create 't2','cf1'
> Created table t2
> Took 0.7420 seconds
> => Hbase::Table - t2
> hbase(main):023:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0105 seconds
> hbase(main):024:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0186 seconds
> hbase(main):025:0> list_quotas
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824, VIOLATION_POLICY
> => NO_WRITES{noformat}
> * Drop the table and the Space quota is set to {{REMOVE => true}}
> {noformat}
> hbase(main):026:0> disable 't2'
> Took 0.4363 seconds
> hbase(main):027:0> drop 't2'
> Took 0.2344 seconds
> hbase(main):028:0> list_quotas
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE => true
> USER => u1 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT => 10M/sec,
> SCOPE => MACHINE{noformat}
> * Recreate the table and set Space quota back. The Space quota on the table
> is still set to {{REMOVE => true}}
> {noformat}
> hbase(main):029:0> create 't2','cf1'
> Created table t2
> Took 0.7348 seconds
> => Hbase::Table - t2
> hbase(main):031:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0088 seconds
> hbase(main):032:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE => true{noformat}
> * Remove RPC quota and drop the table, the Space Quota is not removed
> {noformat}
> hbase(main):033:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT => NONE
> Took 0.0193 seconds
> hbase(main):036:0> disable 't2'
> Took 0.4305 seconds
> hbase(main):037:0> drop 't2'
> Took 0.2353 seconds
> hbase(main):038:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE
> => true{noformat}
> * Deleting the quota entry from {{hbase:quota}} seems to be the option to
> reset it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21089) clean out stale / invalid PRs
[ https://issues.apache.org/jira/browse/HBASE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587710#comment-16587710 ] Sean Busbey commented on HBASE-21089: - ping [~elserj] > clean out stale / invalid PRs > - > > Key: HBASE-21089 > URL: https://issues.apache.org/jira/browse/HBASE-21089 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Minor > > We haven't cleaned out PRs on github in a while. these can go: > * [#63|https://github.com/apache/hbase/pull/63] - no response since April 11 > * [#66|https://github.com/apache/hbase/pull/66] - no response since April 11 > * [#70|https://github.com/apache/hbase/pull/70] - the referenced JIRA, > HBASE-19547, has already closed. > * [#71|https://github.com/apache/hbase/pull/71] - no response since April 11 > * [#78|https://github.com/apache/hbase/pull/78] - no response since Jun 18th -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21089) clean out stale / invalid PRs
[
https://issues.apache.org/jira/browse/HBASE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-21089:
Status: Patch Available (was: Open)
git format-patch still doesn't allow making an empty patch, so here's what the
commit looks like for review:
{code}
Busbey-MBA:hbase busbey$ git show 764d84378c
commit 764d84378c991e39da83f705b7803c7ec504504d (HEAD -> master)
Author: Sean Busbey
Date: Tue Aug 21 11:38:21 2018 -0500
HBASE-21089 close out stale or already closed PRs
* closes #63 - no response since April 11
* closes #66 - no response since April 11
* closes #70 - the referenced JIRA, HBASE-19547, has already closed.
* closes #71 - no response since April 11
* closes #78 - no response since Jun 18th
{code}
> clean out stale / invalid PRs
> -
>
> Key: HBASE-21089
> URL: https://issues.apache.org/jira/browse/HBASE-21089
> Project: HBase
> Issue Type: Task
> Components: community
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
>
> We haven't cleaned out PRs on github in a while. these can go:
> * [#63|https://github.com/apache/hbase/pull/63] - no response since April 11
> * [#66|https://github.com/apache/hbase/pull/66] - no response since April 11
> * [#70|https://github.com/apache/hbase/pull/70] - the referenced JIRA,
> HBASE-19547, has already closed.
> * [#71|https://github.com/apache/hbase/pull/71] - no response since April 11
> * [#78|https://github.com/apache/hbase/pull/78] - no response since Jun 18th
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21089) clean out stale / invalid PRs
Sean Busbey created HBASE-21089: --- Summary: clean out stale / invalid PRs Key: HBASE-21089 URL: https://issues.apache.org/jira/browse/HBASE-21089 Project: HBase Issue Type: Task Components: community Reporter: Sean Busbey Assignee: Sean Busbey We haven't cleaned out PRs on github in a while. these can go: * [#63|https://github.com/apache/hbase/pull/63] - no response since April 11 * [#66|https://github.com/apache/hbase/pull/66] - no response since April 11 * [#70|https://github.com/apache/hbase/pull/70] - the referenced JIRA, HBASE-19547, has already closed. * [#71|https://github.com/apache/hbase/pull/71] - no response since April 11 * [#78|https://github.com/apache/hbase/pull/78] - no response since Jun 18th -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21088) HStoreFile should be closed in HStore#hasReferences
[
https://issues.apache.org/jira/browse/HBASE-21088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-21088:
---
Attachment: 21088.v1.txt
> HStoreFile should be closed in HStore#hasReferences
> ---
>
> Key: HBASE-21088
> URL: https://issues.apache.org/jira/browse/HBASE-21088
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 21088.v1.txt
>
>
> {code}
> reloadedStoreFiles = loadStoreFiles();
> return StoreUtils.hasReferences(reloadedStoreFiles);
> {code}
> The intention of obtaining the HStoreFile's is to check for references.
> The loaded HStoreFile's should be closed prior to return to prevent leak.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21088) HStoreFile should be closed in HStore#hasReferences
[
https://issues.apache.org/jira/browse/HBASE-21088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-21088:
---
Status: Patch Available (was: Open)
> HStoreFile should be closed in HStore#hasReferences
> ---
>
> Key: HBASE-21088
> URL: https://issues.apache.org/jira/browse/HBASE-21088
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 21088.v1.txt
>
>
> {code}
> reloadedStoreFiles = loadStoreFiles();
> return StoreUtils.hasReferences(reloadedStoreFiles);
> {code}
> The intention of obtaining the HStoreFile's is to check for references.
> The loaded HStoreFile's should be closed prior to return to prevent leak.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21088) HStoreFile should be closed in HStore#hasReferences
Ted Yu created HBASE-21088:
--
Summary: HStoreFile should be closed in HStore#hasReferences
Key: HBASE-21088
URL: https://issues.apache.org/jira/browse/HBASE-21088
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
{code}
reloadedStoreFiles = loadStoreFiles();
return StoreUtils.hasReferences(reloadedStoreFiles);
{code}
The intention of obtaining the HStoreFile's is to check for references.
The loaded HStoreFile's should be closed prior to return to prevent leak.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21084) When cloning a snapshot including a split parent region, the split parent region of the cloned table will be online
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587620#comment-16587620
]
Ted Yu commented on HBASE-21084:
For the test,
{code}
admin.catalogJanitorSwitch(true);
{code}
Can you put the above in finally block ?
This is so that the janitor would always be turned back on even if there is any
exception in earlier part of the subtest.
Thanks
> When cloning a snapshot including a split parent region, the split parent
> region of the cloned table will be online
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch,
> HBASE-21084.master.002.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region of the cloned table will be online when
> cloning a snapshot including a split parent region.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region of the cloned table
> will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21084) When cloning a snapshot including a split parent region, the split parent region of the cloned table will be online
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587612#comment-16587612
]
Toshihiro Suzuki commented on HBASE-21084:
--
I just attached the v2 patch.
{quote}
Instead of checking whether it is a split parent in TRSP, we should not
schedule a TRSP for a split parent.
{quote}
I modified CloneSnapshotProcedure to do this.
> When cloning a snapshot including a split parent region, the split parent
> region of the cloned table will be online
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch,
> HBASE-21084.master.002.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region of the cloned table will be online when
> cloning a snapshot including a split parent region.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region of the cloned table
> will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21084) When cloning a snapshot including a split parent region, the split parent region of the cloned table will be online
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-21084:
-
Attachment: HBASE-21084.master.002.patch
> When cloning a snapshot including a split parent region, the split parent
> region of the cloned table will be online
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch,
> HBASE-21084.master.002.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region of the cloned table will be online when
> cloning a snapshot including a split parent region.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region of the cloned table
> will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21085) Adding getter methods to some private fields in ProcedureV2 module
[
https://issues.apache.org/jira/browse/HBASE-21085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587590#comment-16587590
]
Hadoop QA commented on HBASE-21085:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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} |
|| || || || {color:brown} branch-2.0 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
1s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
21s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
55s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
21s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
22s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
12s{color} | {color:red} hbase-procedure: The patch generated 1 new + 10
unchanged - 0 fixed = 11 total (was 10) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
23s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 25s{color} | {color:green} Patch does not cause any errors with Hadoop 2.6.5
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
50s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
34s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}146m 2s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f01af0 |
| JIRA Issue | HBASE-21085 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936440/HBASE-21085.branch-2.0.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 74f8705445d2 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/Pre
[jira] [Commented] (HBASE-21084) When cloning a snapshot including a split parent region, the split parent region of the cloned table will be online
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587580#comment-16587580
]
Hadoop QA commented on HBASE-21084:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
40s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} hbase-server: The patch generated 0 new + 0
unchanged - 6 fixed = 0 total (was 6) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
13s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 57s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}118m
48s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}157m 18s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21084 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936436/HBASE-21084.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 56c9f9a602a0 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14
08:52:28 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / bb3494134e |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/14112/testReport/ |
| Max. process+thread count | 4307 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/14112/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.or
[jira] [Commented] (HBASE-21058) Nightly tests for branches 1 fail to build ref guide
[
https://issues.apache.org/jira/browse/HBASE-21058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587571#comment-16587571
]
Hudson commented on HBASE-21058:
SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1151 (See
[https://builds.apache.org/job/HBase-1.2-IT/1151/])
HBASE-21058 When testing branches one, the PDF ref guide is named (busbey: rev
69f5005700a5968c7c5bf99c28c37436a365e971)
* (edit) dev-support/hbase-personality.sh
> Nightly tests for branches 1 fail to build ref guide
>
>
> Key: HBASE-21058
> URL: https://issues.apache.org/jira/browse/HBASE-21058
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21058.0.patch
>
>
> Nightly on all branches 1 reports failure to get a PDF version of the ref
> guide
> {code}
> -1refguide2m 14s patch failed to produce the pdf version of the
> reference guide.
> {code}
> Actual build log looks clean
> {code}
> [INFO] --- asciidoctor-maven-plugin:1.5.2.1:process-asciidoc (output-pdf) @
> hbase ---
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for pass
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> [INFO] Rendered /testptch/hbase/src/main/asciidoc/book.adoc
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21031) Memory leak if replay edits failed during region opening
[
https://issues.apache.org/jira/browse/HBASE-21031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587558#comment-16587558
]
Hadoop QA commented on HBASE-21031:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-2.0 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
1s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
57s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
22s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
14s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
22s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
12s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 6s{color} | {color:green} Patch does not cause any errors with Hadoop 2.6.5
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}113m 2s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}149m 45s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f01af0 |
| JIRA Issue | HBASE-21031 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936434/HBASE-21031.branch-2.0.006.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2cc12df77480 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.0 / efa54012b4 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/14111/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/14111/testReport/ |
| Max. process+thread count | 4149 (vs. ulimit of 10
[jira] [Commented] (HBASE-21058) Nightly tests for branches 1 fail to build ref guide
[
https://issues.apache.org/jira/browse/HBASE-21058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587557#comment-16587557
]
Hudson commented on HBASE-21058:
SUCCESS: Integrated in Jenkins build HBase-1.3-IT #460 (See
[https://builds.apache.org/job/HBase-1.3-IT/460/])
HBASE-21058 When testing branches one, the PDF ref guide is named (busbey: rev
89cfe88a7c239dc908b8f69643ad7535e2b1ba1c)
* (edit) dev-support/hbase-personality.sh
> Nightly tests for branches 1 fail to build ref guide
>
>
> Key: HBASE-21058
> URL: https://issues.apache.org/jira/browse/HBASE-21058
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21058.0.patch
>
>
> Nightly on all branches 1 reports failure to get a PDF version of the ref
> guide
> {code}
> -1refguide2m 14s patch failed to produce the pdf version of the
> reference guide.
> {code}
> Actual build log looks clean
> {code}
> [INFO] --- asciidoctor-maven-plugin:1.5.2.1:process-asciidoc (output-pdf) @
> hbase ---
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for pass
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> [INFO] Rendered /testptch/hbase/src/main/asciidoc/book.adoc
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21058) Nightly tests for branches 1 fail to build ref guide
[
https://issues.apache.org/jira/browse/HBASE-21058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587541#comment-16587541
]
stack commented on HBASE-21058:
---
+1 too.
> Nightly tests for branches 1 fail to build ref guide
>
>
> Key: HBASE-21058
> URL: https://issues.apache.org/jira/browse/HBASE-21058
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21058.0.patch
>
>
> Nightly on all branches 1 reports failure to get a PDF version of the ref
> guide
> {code}
> -1refguide2m 14s patch failed to produce the pdf version of the
> reference guide.
> {code}
> Actual build log looks clean
> {code}
> [INFO] --- asciidoctor-maven-plugin:1.5.2.1:process-asciidoc (output-pdf) @
> hbase ---
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for pass
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> [INFO] Rendered /testptch/hbase/src/main/asciidoc/book.adoc
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21058) Nightly tests for branches 1 fail to build ref guide
[
https://issues.apache.org/jira/browse/HBASE-21058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-21058:
Resolution: Fixed
Fix Version/s: 1.4.7
2.1.1
2.2.0
2.0.2
1.3.3
1.2.7
1.5.0
3.0.0
Status: Resolved (was: Patch Available)
thanks Peter!
> Nightly tests for branches 1 fail to build ref guide
>
>
> Key: HBASE-21058
> URL: https://issues.apache.org/jira/browse/HBASE-21058
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21058.0.patch
>
>
> Nightly on all branches 1 reports failure to get a PDF version of the ref
> guide
> {code}
> -1refguide2m 14s patch failed to produce the pdf version of the
> reference guide.
> {code}
> Actual build log looks clean
> {code}
> [INFO] --- asciidoctor-maven-plugin:1.5.2.1:process-asciidoc (output-pdf) @
> hbase ---
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for pass
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> [INFO] Rendered /testptch/hbase/src/main/asciidoc/book.adoc
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21084) When cloning a snapshot including a split parent region, the split parent region of the cloned table will be online
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-21084:
-
Description:
Investigating HBASE-21015, I found another issue. It seems like after
HBASE-20881, the split parent region of the cloned table will be online when
cloning a snapshot including a split parent region.
Steps to reproduce are as follows, which is the same as the steps in
HBASE-21015:
1. Create a table
{code}
create "test", "cf"
{code}
2. Put some data into the table
{code}
(0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
{code}
3. Split the table
{code}
split "test"
{code}
4. Take a snapshot of the table before CatalogJanitor cleans up the split
parent region
{code}
snapshot "test", "snap"
{code}
5. Clone the snapshot
{code}
clone_snapshot "snap", "cloned_table"
{code}
After following the above steps, the split parent region of the cloned table
will be online.
was:
Investigating HBASE-21015, I found another issue. It seems like after
HBASE-20881, the split parent region becomes online after cloning a snapshot.
Steps to reproduce are as follows, which is the same as the steps in
HBASE-21015:
1. Create a table
{code}
create "test", "cf"
{code}
2. Put some data into the table
{code}
(0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
{code}
3. Split the table
{code}
split "test"
{code}
4. Take a snapshot of the table before CatalogJanitor cleans up the split
parent region
{code}
snapshot "test", "snap"
{code}
5. Clone the snapshot
{code}
clone_snapshot "snap", "cloned_table"
{code}
After following the above steps, the split parent region becomes online.
> When cloning a snapshot including a split parent region, the split parent
> region of the cloned table will be online
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region of the cloned table will be online when
> cloning a snapshot including a split parent region.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region of the cloned table
> will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21084) When cloning a snapshot including a split parent region, the split parent region of the cloned table will be online
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-21084:
-
Summary: When cloning a snapshot including a split parent region, the split
parent region of the cloned table will be online (was: The split parent region
becomes online after cloning a snapshot)
> When cloning a snapshot including a split parent region, the split parent
> region of the cloned table will be online
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region becomes online after cloning a snapshot.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region becomes online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21058) Nightly tests for branches 1 fail to build ref guide
[
https://issues.apache.org/jira/browse/HBASE-21058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587524#comment-16587524
]
Peter Somogyi commented on HBASE-21058:
---
+1
> Nightly tests for branches 1 fail to build ref guide
>
>
> Key: HBASE-21058
> URL: https://issues.apache.org/jira/browse/HBASE-21058
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21058.0.patch
>
>
> Nightly on all branches 1 reports failure to get a PDF version of the ref
> guide
> {code}
> -1refguide2m 14s patch failed to produce the pdf version of the
> reference guide.
> {code}
> Actual build log looks clean
> {code}
> [INFO] --- asciidoctor-maven-plugin:1.5.2.1:process-asciidoc (output-pdf) @
> hbase ---
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for pass
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_indexterm
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> asciidoctor: WARNING: conversion missing in backend pdf for inline_image
> [INFO] Rendered /testptch/hbase/src/main/asciidoc/book.adoc
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21074) JDK7 branches need to pass "-Dhttps.protocols=TLSv1.2" to maven when building
[
https://issues.apache.org/jira/browse/HBASE-21074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587513#comment-16587513
]
Hudson commented on HBASE-21074:
SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1150 (See
[https://builds.apache.org/job/HBase-1.2-IT/1150/])
HBASE-21074 JDK7 builds need to be done with TLSv1.2. (busbey: rev
1a477b115419bfcf21e3ff2b5a693738c4542c8e)
* (edit) src/main/asciidoc/_chapters/developer.adoc
* (edit) dev-support/hbase_nightly_source-artifact.sh
* (edit) dev-support/hbase-personality.sh
> JDK7 branches need to pass "-Dhttps.protocols=TLSv1.2" to maven when building
> -
>
> Key: HBASE-21074
> URL: https://issues.apache.org/jira/browse/HBASE-21074
> Project: HBase
> Issue Type: Bug
> Components: build, community, test
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21074-branch-1.v0.patch
>
>
> Maven central now requires TLSv1.2 and by default JDK7 doesn't use it. So
> anyone building from a clean repo will fail like our nightly check of
> building the convenience binary from the source tarball e.g. 1.4
> {code}
> [INFO] Scanning for projects...
> [INFO] Downloading from apache release:
> https://repository.apache.org/content/repositories/releases/org/apache/apache/18/apache-18.pom
> [INFO] Downloaded from apache release:
> https://repository.apache.org/content/repositories/releases/org/apache/apache/18/apache-18.pom
> (16 kB at 14 kB/s)
> [INFO] Downloading from Nexus:
> http://repository.apache.org/snapshots/org/apache/felix/maven-bundle-plugin/2.5.3/maven-bundle-plugin-2.5.3.pom
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/2.5.3/maven-bundle-plugin-2.5.3.pom
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Unresolveable build extension: Plugin
> org.apache.felix:maven-bundle-plugin:2.5.3 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> org.apache.felix:maven-bundle-plugin:jar:2.5.3 @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.apache.hbase:hbase:1.4.7-SNAPSHOT
> (/home/jenkins/jenkins-slave/workspace/HBase_Nightly_branch-1.4-EDDBHIHAYHZVAGB2FQL37O5LZNSEJJEXGP55DEGOA4FQKBLNWBAQ/unpacked_src_tarball/pom.xml)
> has 1 error
> [ERROR] Unresolveable build extension: Plugin
> org.apache.felix:maven-bundle-plugin:2.5.3 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> org.apache.felix:maven-bundle-plugin:jar:2.5.3: Could not transfer artifact
> org.apache.felix:maven-bundle-plugin:pom:2.5.3 from/to central
> (https://repo.maven.apache.org/maven2): Received fatal alert:
> protocol_version -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginManagerException
> {code}
> if we pass "-Dhttps.protocols=TLSv1.2" to maven then it should work for any
> JDK7 version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21041) Memstore's heap size will be decreased to minus zero after flush
[
https://issues.apache.org/jira/browse/HBASE-21041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587510#comment-16587510
]
Mike Drob commented on HBASE-21041:
---
{code}
- + 7 * ClassSize.REFERENCE // Store, RegionServicesForStores,
CompactionPipeline,
+ + 6 * ClassSize.REFERENCE // Store, RegionServicesForStores,
CompactionPipeline,
{code}
Need to update comment to remove RegionServicesForStores
{code}
+if (regionServices != null) {
+ regionServices.addMemStoreSize(memstoreAccounting.getDataSize(),
{code}
You have this pattern a few times, when is region going to be null? Not saying
that this needs to change, but trying to understand for my own edification.
Patch v2 doesn't apply for me, maybe needs a rebase. I'm +1 overall though, can
fix the comment on commit.
> Memstore's heap size will be decreased to minus zero after flush
>
>
> Key: HBASE-21041
> URL: https://issues.apache.org/jira/browse/HBASE-21041
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Attachments: HBASE-21041.branch-2.0.001.patch,
> HBASE-21041.branch-2.0.002.patch
>
>
> When creating an active mutable segment (MutableSegment) in memstore,
> MutableSegment's deep overheap (208 bytes) was added to its heap size, but
> not to the region's memstore's heap size. And so was the immutable
> segment(CSLMImmutableSegment) which the mutable segment turned into
> (additional 8 bytes ) later. So after one flush, the memstore's heapsize will
> be decreased to -216 bytes, The minus number will accumulate after every
> flush.
> CompactingMemstore has this problem too.
> We need to record the overhead for CSLMImmutableSegment and MutableSegment to
> the corresponding region's memstore size.
> For CellArrayImmutableSegment, CellChunkImmutableSegment and
> CompositeImmutableSegment , it is not necessary to do so, because inside
> CompactingMemstore, the overheads are already be taken care of when transfer
> a CSLMImmutableSegment into them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21074) JDK7 branches need to pass "-Dhttps.protocols=TLSv1.2" to maven when building
[
https://issues.apache.org/jira/browse/HBASE-21074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587501#comment-16587501
]
Hudson commented on HBASE-21074:
SUCCESS: Integrated in Jenkins build HBase-1.3-IT #459 (See
[https://builds.apache.org/job/HBase-1.3-IT/459/])
HBASE-21074 JDK7 builds need to be done with TLSv1.2. (busbey: rev
9dc7ec11eb9b2c0ba876388151e396599faf5a87)
* (edit) dev-support/hbase-personality.sh
* (edit) dev-support/hbase_nightly_source-artifact.sh
* (edit) src/main/asciidoc/_chapters/developer.adoc
> JDK7 branches need to pass "-Dhttps.protocols=TLSv1.2" to maven when building
> -
>
> Key: HBASE-21074
> URL: https://issues.apache.org/jira/browse/HBASE-21074
> Project: HBase
> Issue Type: Bug
> Components: build, community, test
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21074-branch-1.v0.patch
>
>
> Maven central now requires TLSv1.2 and by default JDK7 doesn't use it. So
> anyone building from a clean repo will fail like our nightly check of
> building the convenience binary from the source tarball e.g. 1.4
> {code}
> [INFO] Scanning for projects...
> [INFO] Downloading from apache release:
> https://repository.apache.org/content/repositories/releases/org/apache/apache/18/apache-18.pom
> [INFO] Downloaded from apache release:
> https://repository.apache.org/content/repositories/releases/org/apache/apache/18/apache-18.pom
> (16 kB at 14 kB/s)
> [INFO] Downloading from Nexus:
> http://repository.apache.org/snapshots/org/apache/felix/maven-bundle-plugin/2.5.3/maven-bundle-plugin-2.5.3.pom
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/2.5.3/maven-bundle-plugin-2.5.3.pom
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Unresolveable build extension: Plugin
> org.apache.felix:maven-bundle-plugin:2.5.3 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> org.apache.felix:maven-bundle-plugin:jar:2.5.3 @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.apache.hbase:hbase:1.4.7-SNAPSHOT
> (/home/jenkins/jenkins-slave/workspace/HBase_Nightly_branch-1.4-EDDBHIHAYHZVAGB2FQL37O5LZNSEJJEXGP55DEGOA4FQKBLNWBAQ/unpacked_src_tarball/pom.xml)
> has 1 error
> [ERROR] Unresolveable build extension: Plugin
> org.apache.felix:maven-bundle-plugin:2.5.3 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> org.apache.felix:maven-bundle-plugin:jar:2.5.3: Could not transfer artifact
> org.apache.felix:maven-bundle-plugin:pom:2.5.3 from/to central
> (https://repo.maven.apache.org/maven2): Received fatal alert:
> protocol_version -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginManagerException
> {code}
> if we pass "-Dhttps.protocols=TLSv1.2" to maven then it should work for any
> JDK7 version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587505#comment-16587505
]
Hadoop QA commented on HBASE-21076:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} HBASE-21076 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-21076 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936451/HBASE-21076.1.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/14116/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch, HBASE-21076.1.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587500#comment-16587500
]
Sean Busbey commented on HBASE-21076:
-
- v1 what I pushed to master
- fixes checkstyle problems precommit found
- fixes comment that said "three" instead of "four" regions were requested.
done as v0 + addendum because in my "update, test, push" cycle I forgot to
commit the staged changes before pushing :(
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch, HBASE-21076.1.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21084) The split parent region becomes online after cloning a snapshot
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587502#comment-16587502
]
Toshihiro Suzuki commented on HBASE-21084:
--
We won't online the split parent region for the original table. We will online
the region for the cloned table. The Description may be a little bit confusing.
I'll rewrite that.
In this case, we take a snapshot right after splitting a region and before
CatalogJanitor runs. So the split parent region is included in the snapshot.
When cloning the snapshot, we should restore this split parent region as a
region with a SPLIT state. But currently we will restore the region as a online
region.
> The split parent region becomes online after cloning a snapshot
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region becomes online after cloning a snapshot.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region becomes online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587500#comment-16587500
]
Sean Busbey edited comment on HBASE-21076 at 8/21/18 2:29 PM:
--
v1 what I pushed to master
- fixes checkstyle problems precommit found
- fixes comment that said "three" instead of "four" regions were requested.
done as v0 + addendum because in my "update, test, push" cycle I forgot to
commit the staged changes before pushing :(
was (Author: busbey):
- v1 what I pushed to master
- fixes checkstyle problems precommit found
- fixes comment that said "three" instead of "four" regions were requested.
done as v0 + addendum because in my "update, test, push" cycle I forgot to
commit the staged changes before pushing :(
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch, HBASE-21076.1.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-21076:
Attachment: HBASE-21076.1.patch
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch, HBASE-21076.1.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21074) JDK7 branches need to pass "-Dhttps.protocols=TLSv1.2" to maven when building
[
https://issues.apache.org/jira/browse/HBASE-21074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-21074:
Resolution: Fixed
Fix Version/s: 1.4.7
2.1.1
2.2.0
2.0.2
1.3.3
1.2.7
1.5.0
3.0.0
Status: Resolved (was: Patch Available)
> JDK7 branches need to pass "-Dhttps.protocols=TLSv1.2" to maven when building
> -
>
> Key: HBASE-21074
> URL: https://issues.apache.org/jira/browse/HBASE-21074
> Project: HBase
> Issue Type: Bug
> Components: build, community, test
>Affects Versions: 1.5.0, 1.2.7, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21074-branch-1.v0.patch
>
>
> Maven central now requires TLSv1.2 and by default JDK7 doesn't use it. So
> anyone building from a clean repo will fail like our nightly check of
> building the convenience binary from the source tarball e.g. 1.4
> {code}
> [INFO] Scanning for projects...
> [INFO] Downloading from apache release:
> https://repository.apache.org/content/repositories/releases/org/apache/apache/18/apache-18.pom
> [INFO] Downloaded from apache release:
> https://repository.apache.org/content/repositories/releases/org/apache/apache/18/apache-18.pom
> (16 kB at 14 kB/s)
> [INFO] Downloading from Nexus:
> http://repository.apache.org/snapshots/org/apache/felix/maven-bundle-plugin/2.5.3/maven-bundle-plugin-2.5.3.pom
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/2.5.3/maven-bundle-plugin-2.5.3.pom
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Unresolveable build extension: Plugin
> org.apache.felix:maven-bundle-plugin:2.5.3 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> org.apache.felix:maven-bundle-plugin:jar:2.5.3 @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.apache.hbase:hbase:1.4.7-SNAPSHOT
> (/home/jenkins/jenkins-slave/workspace/HBase_Nightly_branch-1.4-EDDBHIHAYHZVAGB2FQL37O5LZNSEJJEXGP55DEGOA4FQKBLNWBAQ/unpacked_src_tarball/pom.xml)
> has 1 error
> [ERROR] Unresolveable build extension: Plugin
> org.apache.felix:maven-bundle-plugin:2.5.3 or one of its dependencies could
> not be resolved: Failed to read artifact descriptor for
> org.apache.felix:maven-bundle-plugin:jar:2.5.3: Could not transfer artifact
> org.apache.felix:maven-bundle-plugin:pom:2.5.3 from/to central
> (https://repo.maven.apache.org/maven2): Received fatal alert:
> protocol_version -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginManagerException
> {code}
> if we pass "-Dhttps.protocols=TLSv1.2" to maven then it should work for any
> JDK7 version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21031) Memory leak if replay edits failed during region opening
[
https://issues.apache.org/jira/browse/HBASE-21031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587483#comment-16587483
]
Mike Drob commented on HBASE-21031:
---
+1 assuming QA agrees, thanks for working on this!
> Memory leak if replay edits failed during region opening
>
>
> Key: HBASE-21031
> URL: https://issues.apache.org/jira/browse/HBASE-21031
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Attachments: HBASE-21031.branch-2.0.001.patch,
> HBASE-21031.branch-2.0.002.patch, HBASE-21031.branch-2.0.003.patch,
> HBASE-21031.branch-2.0.004.patch, HBASE-21031.branch-2.0.005.patch,
> HBASE-21031.branch-2.0.006.patch, memoryleak.png
>
>
> Due to HBASE-21029, when replaying edits with a lot of same cells, the
> memstore won't flush, a exception will throw when all heap space was used:
> {code}
> 2018-08-06 15:52:27,590 ERROR
> [RS_OPEN_REGION-regionserver/hb-bp10cw4ejoy0a2f3f-009:16020-2]
> handler.OpenRegionHandler(302): Failed open of
> region=hbase_test,dffa78,1531227033378.cbf9a2daf3aaa0c7e931e9c9a7b53f41.,
> starting to roll back the global memstore size.
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at
> org.apache.hadoop.hbase.regionserver.OnheapChunk.allocateDataBuffer(OnheapChunk.java:41)
> at org.apache.hadoop.hbase.regionserver.Chunk.init(Chunk.java:104)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:226)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:180)
> at
> org.apache.hadoop.hbase.regionserver.ChunkCreator.getChunk(ChunkCreator.java:163)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.getOrMakeChunk(MemStoreLABImpl.java:273)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:148)
> at
> org.apache.hadoop.hbase.regionserver.MemStoreLABImpl.copyCellInto(MemStoreLABImpl.java:111)
> at
> org.apache.hadoop.hbase.regionserver.Segment.maybeCloneWithAllocator(Segment.java:178)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.maybeCloneWithAllocator(AbstractMemStore.java:287)
> at
> org.apache.hadoop.hbase.regionserver.AbstractMemStore.add(AbstractMemStore.java:107)
> at org.apache.hadoop.hbase.regionserver.HStore.add(HStore.java:706)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.restoreEdit(HRegion.java:5494)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEdits(HRegion.java:4608)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEditsIfAny(HRegion.java:4404)
> {code}
> After this exception, the memstore did not roll back, and since MSLAB is
> used, all the chunk allocated won't release for ever. Those memory is leak
> forever...
> We need to rollback the memory if open region fails(For now, only global
> memstore size is decreased after failure).
> Another problem is that we use replayEditsPerRegion in RegionServerAccounting
> to record how many memory used during replaying. And decrease the global
> memstore size if replay fails. This is not right, since during replaying, we
> may also flush the memstore, the size in the map of replayEditsPerRegion is
> not accurate at all!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587480#comment-16587480
]
Sean Busbey commented on HBASE-21076:
-
sweet. will push to master shortly and then can backport once the flaky job has
a go at running it a few times.
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20666) Unsuccessful table creation leaves entry in rsgroup meta table
[
https://issues.apache.org/jira/browse/HBASE-20666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587476#comment-16587476
]
Ted Yu commented on HBASE-20666:
{code}
548 public void testRSGroupListDoesNotContainTableCreationFailed() throws
Exception {
{code}
testRSGroupListDoesNotContainTableCreationFailed ->
testRSGroupListDoesNotContainFailedTableCreation
Please add assertion of failure within the try block after the createTable()
call since exception is expected.
Please consolidate the unsetQuota and setQuota methods since majority of code
is the same for them.
thanks
> Unsuccessful table creation leaves entry in rsgroup meta table
> --
>
> Key: HBASE-20666
> URL: https://issues.apache.org/jira/browse/HBASE-20666
> Project: HBase
> Issue Type: Bug
>Reporter: Biju Nair
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-20666.master.001.patch,
> HBASE-20666.master.002.patch
>
>
> If a table creation fails in a cluster enabled with {{rsgroup}} feature, the
> table is still listed as part of {{default}} rsgroup.
> To recreate the scenario:
> - Create a namespace (NS) with number of region limit
> - Create table in the NS which satisfies the region limit by pre-splitting
> - Create a new table in the NS which will fail
> - {{list_rsgroup}} will show the table being part of {{default}} rsgroup and
> data can be found in {{hbase:rsgroup}} table
> Would be good to revert the entry when the table creation fails or a script
> to clean up the metadata.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21087) flaky dashboard needs a way to annotate when there's already a jira associated with a test failure
Sean Busbey created HBASE-21087:
---
Summary: flaky dashboard needs a way to annotate when there's
already a jira associated with a test failure
Key: HBASE-21087
URL: https://issues.apache.org/jira/browse/HBASE-21087
Project: HBase
Issue Type: New Feature
Components: community, test
Reporter: Sean Busbey
To avoid folks opening duplicate JIRAs when a test shows up as very broken on
the flaky dashboard, we should add a way to flag that a jira is open for it.
since the dashboard is read-only, maybe we could add a jira query for a list of
issues with some specific label ("flaky dashboard", "untrusted test", etc) and
the test name in the subject line?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21084) The split parent region becomes online after cloning a snapshot
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587470#comment-16587470
]
Duo Zhang commented on HBASE-21084:
---
And this is really strange, clone snapshot will create a new table, and also
new regions, why we will online the region for the original table?
> The split parent region becomes online after cloning a snapshot
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region becomes online after cloning a snapshot.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region becomes online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-16371) when excluding tests in precommit, provide a link in the report summary to the list of excluded tests
[ https://issues.apache.org/jira/browse/HBASE-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-16371: Component/s: community > when excluding tests in precommit, provide a link in the report summary to > the list of excluded tests > - > > Key: HBASE-16371 > URL: https://issues.apache.org/jira/browse/HBASE-16371 > Project: HBase > Issue Type: Improvement > Components: build, community >Reporter: Sean Busbey >Priority: Major > Labels: beginner > > now that we're excluding some tests from precommit runs, we should be sure to > include a way to find out what tests were excluded from a given test run in > the report that gets posted to JIRA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-20988) TestShell shouldn't be skipped for hbase-shell module test
[
https://issues.apache.org/jira/browse/HBASE-20988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HBASE-20988.
-
Resolution: Duplicate
> TestShell shouldn't be skipped for hbase-shell module test
> --
>
> Key: HBASE-20988
> URL: https://issues.apache.org/jira/browse/HBASE-20988
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Priority: Major
>
> Here is snippet for QA run 13862 for HBASE-20985 :
> {code}
> 13:42:50 cd /testptch/hbase/hbase-shell
> 13:42:50 /usr/share/maven/bin/mvn
> -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.normalizer.
> TestSimpleRegionNormalizerOnCluster.java,**/replication.regionserver.TestSerialReplicationEndpoint.java,**/master.procedure.TestServerCrashProcedure.java,**/master.procedure.TestCreateTableProcedure.
>
> java,**/TestClientOperationTimeout.java,**/client.TestSnapshotFromClientWithRegionReplicas.java,**/master.TestAssignmentManagerMetrics.java,**/client.TestShell.java,**/client.
>
> TestCloneSnapshotFromClientWithRegionReplicas.java,**/master.TestDLSFSHLog.java,**/replication.TestReplicationSmallTestsSync.java,**/master.procedure.TestModifyTableProcedure.java,**/regionserver.
>
> TestCompactionInDeadRegionServer.java,**/client.TestFromClientSide3.java,**/master.procedure.TestRestoreSnapshotProcedure.java,**/client.TestRestoreSnapshotFromClient.java,**/security.access.
>
> TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestDrainReplicationQueuesForStandBy.java,**/master.procedure.TestProcedurePriority.java,**/master.locking.TestLockProcedure.
>
> java,**/master.cleaner.TestSnapshotFromMaster.java,**/master.assignment.TestSplitTableRegionProcedure.java,**/client.TestMobRestoreSnapshotFromClient.java,**/replication.TestReplicationKillSlaveRS.
>
> java,**/regionserver.TestHRegion.java,**/security.access.TestAccessController.java,**/master.procedure.TestTruncateTableProcedure.java,**/client.TestAsyncReplicationAdminApiWithClusters.java,**/
>
> coprocessor.TestMetaTableMetrics.java,**/client.TestMobSnapshotCloneIndependence.java,**/namespace.TestNamespaceAuditor.java,**/master.TestMasterAbortAndRSGotKilled.java,**/client.TestAsyncTable.java,**/master.TestMasterOperationsForRegionReplicas.java,**/util.TestFromClientSide3WoUnsafe.java,**/client.TestSnapshotCloneIndependence.java,**/client.TestAsyncDecommissionAdminApi.java,**/client.
>
> TestRestoreSnapshotFromClientWithRegionReplicas.java,**/master.assignment.TestMasterAbortWhileMergingTable.java,**/client.TestFromClientSide.java,**/client.TestAdmin1.java,**/client.
>
> TestFromClientSideWithCoprocessor.java,**/replication.TestReplicationKillSlaveRSWithSeparateOldWALs.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/regionserver.
> TestSplitTransactionOnCluster.java clean test -fae >
> /testptch/patchprocess/patch-unit-hbase-shell.txt 2>&1
> {code}
> In this case, there was modification to shell script, leading to running
> shell tests.
> However, TestShell was excluded in the QA run, defeating the purpose.
> Meanwhile QA posted the following onto HBASE-20985 :
> bq. +1unit7m 4s hbase-shell in the patch passed.
> That is misleading - no related test was actually run.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-16371) when excluding tests in precommit, provide a link in the report summary to the list of excluded tests
[ https://issues.apache.org/jira/browse/HBASE-16371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-16371: Labels: beginner (was: ) > when excluding tests in precommit, provide a link in the report summary to > the list of excluded tests > - > > Key: HBASE-16371 > URL: https://issues.apache.org/jira/browse/HBASE-16371 > Project: HBase > Issue Type: Improvement > Components: build, community >Reporter: Sean Busbey >Priority: Major > Labels: beginner > > now that we're excluding some tests from precommit runs, we should be sure to > include a way to find out what tests were excluded from a given test run in > the report that gets posted to JIRA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587465#comment-16587465
]
Duo Zhang commented on HBASE-21076:
---
Tried locally, it works for me. +1 after you fixing the checkstyle issues.
Let's push it to master to see if the flaky dashboard also says OK.
Thanks.
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20890) PE filterScan seems to be stuck forever
[
https://issues.apache.org/jira/browse/HBASE-20890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587463#comment-16587463
]
Sean Busbey commented on HBASE-20890:
-
[~abhishek94goyal] I've added you as a contributor to the project, so you
should be able to assign this to yourself now.
> PE filterScan seems to be stuck forever
> ---
>
> Key: HBASE-20890
> URL: https://issues.apache.org/jira/browse/HBASE-20890
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.3
>Reporter: Vikas Vishwakarma
>Priority: Minor
>
> Command Used
> {code:java}
> ~/current/bigdata-hbase/hbase/hbase/bin/hbase pe --nomapred randomWrite 1 >
> write 2>&1
> ~/current/bigdata-hbase/hbase/hbase/bin/hbase pe --nomapred filterScan 1 >
> filterScan 2>&1
> {code}
>
> Output
> This kept running for several hours just printing the below messages in logs
>
> {code:java}
> -bash-4.1$ grep "Advancing internal scanner to startKey" filterScan.1 | head
> 2018-07-13 10:44:45,188 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-13 10:44:45,976 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-13 10:44:46,695 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> .
> -bash-4.1$ grep "Advancing internal scanner to startKey" filterScan.1 | tail
> 2018-07-15 06:20:22,353 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-15 06:20:23,044 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> 2018-07-15 06:20:23,768 DEBUG [TestClient-0] client.ClientScanner - Advancing
> internal scanner to startKey at '52359'
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21086) NPE in TestTableResource
[ https://issues.apache.org/jira/browse/HBASE-21086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587459#comment-16587459 ] Duo Zhang commented on HBASE-21086: --- OK, seems your solution is better. We do not need to call split. > NPE in TestTableResource > > > Key: HBASE-21086 > URL: https://issues.apache.org/jira/browse/HBASE-21086 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-21086.patch > > > Not sure which commit broke it but it is on the top of the flaky list. We use > a method in TestEndToEndSplitTransition, but the method will use its own > HBaseTestingUtility which is not initialized so NPE. Need to rewrite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587457#comment-16587457
]
Sean Busbey commented on HBASE-21076:
-
both of those checkstyle warnings are easy fixes. Can do on commit or will post
a new patch if anyone wants some other change.
> TestTableResource fails with NPE
>
>
> Key: HBASE-21076
> URL: https://issues.apache.org/jira/browse/HBASE-21076
> Project: HBase
> Issue Type: Test
> Components: REST, test
>Affects Versions: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.1.1, 1.4.7
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-21076.0.patch
>
>
> The following can be observed in master branch:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.rest.TestTableResource.setUpBeforeClass(TestTableResource.java:134)
> {code}
> The NPE comes from the following in TestEndToEndSplitTransaction :
> {code}
> compactAndBlockUntilDone(TEST_UTIL.getAdmin(),
> TEST_UTIL.getMiniHBaseCluster().getRegionServer(0),
> daughterA.getRegionName());
> {code}
> Initial check of the code shows that TestEndToEndSplitTransaction uses
> TEST_UTIL instance which is created within TestEndToEndSplitTransaction.
> However, TestTableResource creates its own instance of HBaseTestingUtility.
> Meaning TEST_UTIL.getMiniHBaseCluster() would return null, since the instance
> created by TestEndToEndSplitTransaction has hbaseCluster as null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21086) NPE in TestTableResource
[ https://issues.apache.org/jira/browse/HBASE-21086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21086: -- Attachment: HBASE-21086.patch > NPE in TestTableResource > > > Key: HBASE-21086 > URL: https://issues.apache.org/jira/browse/HBASE-21086 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-21086.patch > > > Not sure which commit broke it but it is on the top of the flaky list. We use > a method in TestEndToEndSplitTransition, but the method will use its own > HBaseTestingUtility which is not initialized so NPE. Need to rewrite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21086) NPE in TestTableResource
[ https://issues.apache.org/jira/browse/HBASE-21086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587455#comment-16587455 ] Duo Zhang commented on HBASE-21086: --- OK, the code which makes us rely on the HBaseTestingUtility is added in HBASE-20940. > NPE in TestTableResource > > > Key: HBASE-21086 > URL: https://issues.apache.org/jira/browse/HBASE-21086 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Priority: Major > > Not sure which commit broke it but it is on the top of the flaky list. We use > a method in TestEndToEndSplitTransition, but the method will use its own > HBaseTestingUtility which is not initialized so NPE. Need to rewrite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21086) NPE in TestTableResource
[ https://issues.apache.org/jira/browse/HBASE-21086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-21086. - Resolution: Duplicate duplicate of HBASE-21076. please review there? > NPE in TestTableResource > > > Key: HBASE-21086 > URL: https://issues.apache.org/jira/browse/HBASE-21086 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Priority: Major > > Not sure which commit broke it but it is on the top of the flaky list. We use > a method in TestEndToEndSplitTransition, but the method will use its own > HBaseTestingUtility which is not initialized so NPE. Need to rewrite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21086) NPE in TestTableResource
Duo Zhang created HBASE-21086: - Summary: NPE in TestTableResource Key: HBASE-21086 URL: https://issues.apache.org/jira/browse/HBASE-21086 Project: HBase Issue Type: Bug Reporter: Duo Zhang Not sure which commit broke it but it is on the top of the flaky list. We use a method in TestEndToEndSplitTransition, but the method will use its own HBaseTestingUtility which is not initialized so NPE. Need to rewrite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19008) Add missing equals or hashCode method(s) to stock Filter implementations
[
https://issues.apache.org/jira/browse/HBASE-19008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
liubangchen updated HBASE-19008:
Attachment: HBASE-19008-17.patch
> Add missing equals or hashCode method(s) to stock Filter implementations
>
>
> Key: HBASE-19008
> URL: https://issues.apache.org/jira/browse/HBASE-19008
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: liubangchen
>Priority: Major
> Labels: filter
> Attachments: Filters.png, HBASE-19008-1.patch, HBASE-19008-10.patch,
> HBASE-19008-11.patch, HBASE-19008-12.patch, HBASE-19008-13.patch,
> HBASE-19008-14.patch, HBASE-19008-15.patch, HBASE-19008-16.patch,
> HBASE-19008-17.patch, HBASE-19008-2.patch, HBASE-19008-3.patch,
> HBASE-19008-4.patch, HBASE-19008-5.patch, HBASE-19008-6.patch,
> HBASE-19008-7.patch, HBASE-19008-8.patch, HBASE-19008-9.patch,
> HBASE-19008.patch
>
>
> In HBASE-15410, [~mdrob] reminded me that Filter implementations may not
> write {{equals}} or {{hashCode}} method(s).
> This issue is to add missing {{equals}} or {{hashCode}} method(s) to stock
> Filter implementations such as KeyOnlyFilter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21039) Procedure worker should not quit when getting unexpected error
[
https://issues.apache.org/jira/browse/HBASE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587446#comment-16587446
]
Duo Zhang commented on HBASE-21039:
---
As for now we do not quit, the log message is not suitable?
{code}
LOG.warn("Worker terminating UNNATURALLY {}", this.activeProcedure, t);
{code}
> Procedure worker should not quit when getting unexpected error
> --
>
> Key: HBASE-21039
> URL: https://issues.apache.org/jira/browse/HBASE-21039
> Project: HBase
> Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Allan Yang
>Priority: Major
> Attachments: HBASE-21039.branch-2.0.001.patch
>
>
> Since for either the old RTP or the new TRSP introduced in HBASE-20881, we
> could end with FAILED_OPEN and set the procedure as failure, it is possible
> that we will call rollback for procedures which can not be rollbacked, and
> throw UnsupportedOperationException.
> Before we find out a way to deal with this, I think at least we should make
> the Procedure worker does not quit when getting these errors, as for the core
> workers there is no way to get them back...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21039) Procedure worker should not quit when getting unexpected error
[
https://issues.apache.org/jira/browse/HBASE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587434#comment-16587434
]
Hadoop QA commented on HBASE-21039:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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} |
|| || || || {color:brown} branch-2.0 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
18s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
24s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
30s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
23s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
21s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 52s{color} | {color:green} Patch does not cause any errors with Hadoop 2.6.5
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
12s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
42s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
11s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 28m 58s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f01af0 |
| JIRA Issue | HBASE-21039 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936444/HBASE-21039.branch-2.0.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 624721bd6866 4.4.0-130-generic #156-Ubuntu SMP Thu Jun 14
08:53:28 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.0 / efa54012b4 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/14114/testReport/ |
| Max. process+thread count | 276 (vs. ulimit of 1) |
| modules | C: hbase-procedure U: hbase-procedure |
| Console output |
https:/
[jira] [Commented] (HBASE-21085) Adding getter methods to some private fields in ProcedureV2 module
[ https://issues.apache.org/jira/browse/HBASE-21085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587431#comment-16587431 ] Duo Zhang commented on HBASE-21085: --- Why? For me, at least for SchemaLocking, it is intentional to make it package private. We should expose as less internal states to others as possible. > Adding getter methods to some private fields in ProcedureV2 module > --- > > Key: HBASE-21085 > URL: https://issues.apache.org/jira/browse/HBASE-21085 > Project: HBase > Issue Type: Sub-task >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-21085.branch-2.0.001.patch > > > Many fields are private in ProcedureV2 module. adding getter method to them > making them more transparent. > And some classes are private too, making it public. > Some class is private in ProcecudeV2 module, making it public. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21084) The split parent region becomes online after cloning a snapshot
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587428#comment-16587428
]
Duo Zhang commented on HBASE-21084:
---
I do not think this is the correct way to fix the problem. Instead of checking
whether it is a split parent in TRSP, we should not schedule a TRSP for a split
parent.
> The split parent region becomes online after cloning a snapshot
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region becomes online after cloning a snapshot.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region becomes online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21039) Procedure worker should not quit when getting unexpected error
[ https://issues.apache.org/jira/browse/HBASE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587385#comment-16587385 ] Allan Yang commented on HBASE-21039: Found this too, uploaded a patch to fix it, [~Apache9] > Procedure worker should not quit when getting unexpected error > -- > > Key: HBASE-21039 > URL: https://issues.apache.org/jira/browse/HBASE-21039 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-21039.branch-2.0.001.patch > > > Since for either the old RTP or the new TRSP introduced in HBASE-20881, we > could end with FAILED_OPEN and set the procedure as failure, it is possible > that we will call rollback for procedures which can not be rollbacked, and > throw UnsupportedOperationException. > Before we find out a way to deal with this, I think at least we should make > the Procedure worker does not quit when getting these errors, as for the core > workers there is no way to get them back... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21039) Procedure worker should not quit when getting unexpected error
[ https://issues.apache.org/jira/browse/HBASE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Yang updated HBASE-21039: --- Attachment: HBASE-21039.branch-2.0.001.patch > Procedure worker should not quit when getting unexpected error > -- > > Key: HBASE-21039 > URL: https://issues.apache.org/jira/browse/HBASE-21039 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-21039.branch-2.0.001.patch > > > Since for either the old RTP or the new TRSP introduced in HBASE-20881, we > could end with FAILED_OPEN and set the procedure as failure, it is possible > that we will call rollback for procedures which can not be rollbacked, and > throw UnsupportedOperationException. > Before we find out a way to deal with this, I think at least we should make > the Procedure worker does not quit when getting these errors, as for the core > workers there is no way to get them back... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21039) Procedure worker should not quit when getting unexpected error
[ https://issues.apache.org/jira/browse/HBASE-21039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Yang updated HBASE-21039: --- Assignee: Allan Yang Status: Patch Available (was: Open) > Procedure worker should not quit when getting unexpected error > -- > > Key: HBASE-21039 > URL: https://issues.apache.org/jira/browse/HBASE-21039 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-21039.branch-2.0.001.patch > > > Since for either the old RTP or the new TRSP introduced in HBASE-20881, we > could end with FAILED_OPEN and set the procedure as failure, it is possible > that we will call rollback for procedures which can not be rollbacked, and > throw UnsupportedOperationException. > Before we find out a way to deal with this, I think at least we should make > the Procedure worker does not quit when getting these errors, as for the core > workers there is no way to get them back... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21076) TestTableResource fails with NPE
[
https://issues.apache.org/jira/browse/HBASE-21076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587379#comment-16587379
]
Hadoop QA commented on HBASE-21076:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
28s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
50s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
46s{color} | {color:red} hbase-rest: The patch generated 2 new + 0 unchanged -
0 fixed = 2 total (was 0) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
57s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
12m 59s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
49s{color} | {color:green} hbase-rest in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 52m 19s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21076 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12936431/HBASE-21076.0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux c145ce8bdffe 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / bb3494134e |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/14110/artifact/patchprocess/diff-checkstyle-hbase-rest.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/14110/testReport/ |
| Max. process+thread count | 2206 (vs. ulimit of 1) |
| modules | C: hbase-rest U: hbase-rest |
| Console output |
https://builds.apache.or
[jira] [Updated] (HBASE-21085) Adding getter methods to some private fields in ProcedureV2 module
[ https://issues.apache.org/jira/browse/HBASE-21085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Yang updated HBASE-21085: --- Attachment: HBASE-21085.branch-2.0.001.patch > Adding getter methods to some private fields in ProcedureV2 module > --- > > Key: HBASE-21085 > URL: https://issues.apache.org/jira/browse/HBASE-21085 > Project: HBase > Issue Type: Sub-task >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-21085.branch-2.0.001.patch > > > Many fields are private in ProcedureV2 module. adding getter method to them > making them more transparent. > And some classes are private too, making it public. > Some class is private in ProcecudeV2 module, making it public. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21085) Adding getter methods to some private fields in ProcedureV2 module
Allan Yang created HBASE-21085: -- Summary: Adding getter methods to some private fields in ProcedureV2 module Key: HBASE-21085 URL: https://issues.apache.org/jira/browse/HBASE-21085 Project: HBase Issue Type: Sub-task Reporter: Allan Yang Assignee: Allan Yang Many fields are private in ProcedureV2 module. adding getter method to them making them more transparent. And some classes are private too, making it public. Some class is private in ProcecudeV2 module, making it public. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21085) Adding getter methods to some private fields in ProcedureV2 module
[ https://issues.apache.org/jira/browse/HBASE-21085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Yang updated HBASE-21085: --- Status: Patch Available (was: Open) > Adding getter methods to some private fields in ProcedureV2 module > --- > > Key: HBASE-21085 > URL: https://issues.apache.org/jira/browse/HBASE-21085 > Project: HBase > Issue Type: Sub-task >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > > Many fields are private in ProcedureV2 module. adding getter method to them > making them more transparent. > And some classes are private too, making it public. > Some class is private in ProcecudeV2 module, making it public. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19008) Add missing equals or hashCode method(s) to stock Filter implementations
[
https://issues.apache.org/jira/browse/HBASE-19008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587376#comment-16587376
]
Reid Chan commented on HBASE-19008:
---
Leave some comments in review board, most of them are the same.
> Add missing equals or hashCode method(s) to stock Filter implementations
>
>
> Key: HBASE-19008
> URL: https://issues.apache.org/jira/browse/HBASE-19008
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: liubangchen
>Priority: Major
> Labels: filter
> Attachments: Filters.png, HBASE-19008-1.patch, HBASE-19008-10.patch,
> HBASE-19008-11.patch, HBASE-19008-12.patch, HBASE-19008-13.patch,
> HBASE-19008-14.patch, HBASE-19008-15.patch, HBASE-19008-16.patch,
> HBASE-19008-2.patch, HBASE-19008-3.patch, HBASE-19008-4.patch,
> HBASE-19008-5.patch, HBASE-19008-6.patch, HBASE-19008-7.patch,
> HBASE-19008-8.patch, HBASE-19008-9.patch, HBASE-19008.patch
>
>
> In HBASE-15410, [~mdrob] reminded me that Filter implementations may not
> write {{equals}} or {{hashCode}} method(s).
> This issue is to add missing {{equals}} or {{hashCode}} method(s) to stock
> Filter implementations such as KeyOnlyFilter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21084) The split parent region becomes online after cloning a snapshot
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587372#comment-16587372
]
Toshihiro Suzuki commented on HBASE-21084:
--
It seems like TransitRegionStateProcedure opens even split parent regions. I
added the check not to open a region if it's a split parent region in the
patch. Could you please take a look at the patch? [~Apache9]
> The split parent region becomes online after cloning a snapshot
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region becomes online after cloning a snapshot.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region becomes online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21084) The split parent region becomes online after cloning a snapshot
[
https://issues.apache.org/jira/browse/HBASE-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-21084:
-
Status: Patch Available (was: Open)
> The split parent region becomes online after cloning a snapshot
> ---
>
> Key: HBASE-21084
> URL: https://issues.apache.org/jira/browse/HBASE-21084
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21084.master.001.patch
>
>
> Investigating HBASE-21015, I found another issue. It seems like after
> HBASE-20881, the split parent region becomes online after cloning a snapshot.
> Steps to reproduce are as follows, which is the same as the steps in
> HBASE-21015:
> 1. Create a table
> {code}
> create "test", "cf"
> {code}
> 2. Put some data into the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Take a snapshot of the table before CatalogJanitor cleans up the split
> parent region
> {code}
> snapshot "test", "snap"
> {code}
> 5. Clone the snapshot
> {code}
> clone_snapshot "snap", "cloned_table"
> {code}
> After following the above steps, the split parent region becomes online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
