[jira] [Assigned] (HBASE-19761) Fix Checkstyle errors in hbase-zookeeper
[ https://issues.apache.org/jira/browse/HBASE-19761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang reassigned HBASE-19761: - Assignee: maoling (was: Jan Hentschel) > Fix Checkstyle errors in hbase-zookeeper > > > Key: HBASE-19761 > URL: https://issues.apache.org/jira/browse/HBASE-19761 > Project: HBase > Issue Type: Sub-task >Reporter: Jan Hentschel >Assignee: maoling >Priority: Minor > > Fix the remaining Checkstyle errors in the *hbase-zookeeper* module and > enable Checkstyle to fail on violations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-9465: - Attachment: (was: HBASE-20048-v2.patch) > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Affects Versions: 2.0.0, 1.4.0 >Reporter: Honghua Feng >Assignee: Phil Yang >Priority: Critical > Attachments: HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-branch-1-v4.patch, > HBASE-9465-branch-1-v4.patch, HBASE-9465-branch-1.v4.revert.patch, > HBASE-9465-v1.patch, HBASE-9465-v2.patch, HBASE-9465-v2.patch, > HBASE-9465-v3.patch, HBASE-9465-v4.patch, HBASE-9465-v5.patch, > HBASE-9465-v6.patch, HBASE-9465-v6.patch, HBASE-9465-v7.patch, > HBASE-9465-v7.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20050) Reimplement updateReplicationPositions logic in serial replication based on the newly introduced replication storage layer
[ https://issues.apache.org/jira/browse/HBASE-20050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20050: - Description: Now, in serial replication, need to update the replication position both in zookeeper and meta table, which may led to inconsistent problem. I'll re-implement this part based on the uniform replication storage layer. > Reimplement updateReplicationPositions logic in serial replication based on > the newly introduced replication storage layer > -- > > Key: HBASE-20050 > URL: https://issues.apache.org/jira/browse/HBASE-20050 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > > Now, in serial replication, need to update the replication position both in > zookeeper and meta table, which may led to inconsistent problem. I'll > re-implement this part based on the uniform replication storage layer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374014#comment-16374014 ] Chia-Ping Tsai commented on HBASE-20055: Seems we can remove all InterruptedException from procedure since it was introduced for the permissions checking. After HBASE-16217 moved the check to AccessController, the InterruptedException is useless. > Remove declaration of un-thrown exceptions and unused > setRegionStateBackToOpen() from MergeTableRegionsProcedure > > > Key: HBASE-20055 > URL: https://issues.apache.org/jira/browse/HBASE-20055 > Project: HBase > Issue Type: Improvement > Components: amv2 >Affects Versions: 2.0.0-beta-1 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Fix For: 2.0.0-beta-2 > > Attachments: hbase-20055.master.001.patch > > > A few methods declare exceptions in throws statement that are not thrown and > method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20050) Reimplement updateReplicationPositions logic in serial replication based on the newly introduced replication storage layer
[ https://issues.apache.org/jira/browse/HBASE-20050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20050: - Summary: Reimplement updateReplicationPositions logic in serial replication based on the newly introduced replication storage layer (was: Reimplement serial replication based on the newly introduced replication storage layer) > Reimplement updateReplicationPositions logic in serial replication based on > the newly introduced replication storage layer > -- > > Key: HBASE-20050 > URL: https://issues.apache.org/jira/browse/HBASE-20050 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17918) document serial replication
[
https://issues.apache.org/jira/browse/HBASE-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374010#comment-16374010
]
Duo Zhang commented on HBASE-17918:
---
Will reapply the patch after HBASE-20046 is done.
> document serial replication
> ---
>
> Key: HBASE-17918
> URL: https://issues.apache.org/jira/browse/HBASE-17918
> Project: HBase
> Issue Type: Task
> Components: documentation, Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Sean Busbey
>Assignee: Yi Mei
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-17918.v1.patch, HBASE-17918.v2.patch,
> HBASE-17918.v3.patch
>
>
> It looks like HBASE-9465 addresses one of the major flaws in our existing
> replication (namely that order of delivery is not assured). All I see in the
> reference guide is a note on {{hbase.serial.replication.waitingMs}}. Instead
> we should cover this in the replication section, especially given that we
> call out the order of delivery limitation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (HBASE-17918) document serial replication
[
https://issues.apache.org/jira/browse/HBASE-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang reopened HBASE-17918:
---
> document serial replication
> ---
>
> Key: HBASE-17918
> URL: https://issues.apache.org/jira/browse/HBASE-17918
> Project: HBase
> Issue Type: Task
> Components: documentation, Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Sean Busbey
>Assignee: Yi Mei
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-17918.v1.patch, HBASE-17918.v2.patch,
> HBASE-17918.v3.patch
>
>
> It looks like HBASE-9465 addresses one of the major flaws in our existing
> replication (namely that order of delivery is not assured). All I see in the
> reference guide is a note on {{hbase.serial.replication.waitingMs}}. Instead
> we should cover this in the replication section, especially given that we
> call out the order of delivery limitation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-17010) Serial replication should handle daughter regions being assigned to another RS
[ https://issues.apache.org/jira/browse/HBASE-17010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-17010. --- Resolution: Later Fix Version/s: (was: 1.4.0) (was: 2.0.0) Will reimplement it soon. See HBASE-20046. > Serial replication should handle daughter regions being assigned to another RS > -- > > Key: HBASE-17010 > URL: https://issues.apache.org/jira/browse/HBASE-17010 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Ted Yu >Assignee: Phil Yang >Priority: Major > Attachments: HBASE-17010-branch-1-v1.patch, HBASE-17010-v1.patch, > HBASE-17010-v2.patch, HBASE-17010-v3.patch > > > testRegionSplit and testRegionMerge were temporarily disabled by HBASE-16975. > HBASE-9465 has an assumption that when we split a region, two daughter > regions are in same RS with the parent region. But after HBASE-14551 went in, > daughter regions may be assigned to other RS directly. > This issue is to handle the new behavior and reenable the tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-9465. -- Resolution: Later Fix Version/s: (was: 1.5.0) (was: 2.0.0) Will reimplement it soon. See HBASE-20046. > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Affects Versions: 2.0.0, 1.4.0 >Reporter: Honghua Feng >Assignee: Phil Yang >Priority: Critical > Attachments: HBASE-20048-v2.patch, HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-branch-1-v4.patch, > HBASE-9465-branch-1-v4.patch, HBASE-9465-branch-1.v4.revert.patch, > HBASE-9465-v1.patch, HBASE-9465-v2.patch, HBASE-9465-v2.patch, > HBASE-9465-v3.patch, HBASE-9465-v4.patch, HBASE-9465-v5.patch, > HBASE-9465-v6.patch, HBASE-9465-v6.patch, HBASE-9465-v7.patch, > HBASE-9465-v7.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-17010) Serial replication should handle daughter regions being assigned to another RS
[ https://issues.apache.org/jira/browse/HBASE-17010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang reopened HBASE-17010: --- > Serial replication should handle daughter regions being assigned to another RS > -- > > Key: HBASE-17010 > URL: https://issues.apache.org/jira/browse/HBASE-17010 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Ted Yu >Assignee: Phil Yang >Priority: Major > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-17010-branch-1-v1.patch, HBASE-17010-v1.patch, > HBASE-17010-v2.patch, HBASE-17010-v3.patch > > > testRegionSplit and testRegionMerge were temporarily disabled by HBASE-16975. > HBASE-9465 has an assumption that when we split a region, two daughter > regions are in same RS with the parent region. But after HBASE-14551 went in, > daughter regions may be assigned to other RS directly. > This issue is to handle the new behavior and reenable the tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang reopened HBASE-9465: -- > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Affects Versions: 2.0.0, 1.4.0 >Reporter: Honghua Feng >Assignee: Phil Yang >Priority: Critical > Fix For: 2.0.0, 1.5.0 > > Attachments: HBASE-20048-v2.patch, HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-branch-1-v4.patch, > HBASE-9465-branch-1-v4.patch, HBASE-9465-branch-1.v4.revert.patch, > HBASE-9465-v1.patch, HBASE-9465-v2.patch, HBASE-9465-v2.patch, > HBASE-9465-v3.patch, HBASE-9465-v4.patch, HBASE-9465-v5.patch, > HBASE-9465-v6.patch, HBASE-9465-v6.patch, HBASE-9465-v7.patch, > HBASE-9465-v7.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20048) Revert serial replication feature
[ https://issues.apache.org/jira/browse/HBASE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20048: -- Resolution: Fixed Hadoop Flags: Reviewed Release Note: Revert the serial replication feature from all branches. Plan to reimplement it soon and land onto 2.1 release line. Status: Resolved (was: Patch Available) Cherry picked the two revert commits from branch-1.4 to branch-1. > Revert serial replication feature > - > > Key: HBASE-20048 > URL: https://issues.apache.org/jira/browse/HBASE-20048 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-20048-v1.patch, HBASE-20048-v2.patch, > HBASE-20048.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20043) ITBLL fails against hadoop3
[
https://issues.apache.org/jira/browse/HBASE-20043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373995#comment-16373995
]
stack commented on HBASE-20043:
---
Taking me a while. On h3 we take longer, so long that the Chaos Monkey that
does server killing steps in (test is over on hadoop2 before server killing has
a chance). There is no restart of killed servers for some reason either so
after we get the master -- inevitable -- we are dead in the water until the
failsafe 30min timeout cuts in. Still looking...
> ITBLL fails against hadoop3
> ---
>
> Key: HBASE-20043
> URL: https://issues.apache.org/jira/browse/HBASE-20043
> Project: HBase
> Issue Type: Bug
> Components: integration tests
>Reporter: Mike Drob
>Assignee: stack
>Priority: Major
> Fix For: 2.0.0-beta-2
>
>
> This has been failing for a while, I haven't tried to bisec but it was before
> my changes for HBASE-19991 at least.
> {code}
> mvn clean verify -pl hbase-it -Dhadoop.profile=3.0
> -Dit.test=IntegrationTestBigLinkedList -Dtest=none -am
> {code}
> {code}
> 2018-02-21 16:43:13,265 ERROR
> [RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=60450]
> ipc.RpcServer(464): Unexpected throwable object
> java.lang.AssertionError:
> hri=IntegrationTestBigLinkedList,\x8E8\xE3\x8E8\xE3\x8E5,1519252895022.236bbedde32e4549691c108a1a7005a8.,
> source=, destination=mdrob-mbp.hsd1.tx.comcast.net,60456,1519252856027
> at org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:1691)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.moveRegion(MasterRpcServices.java:1348)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> 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)
> 2018-02-21 16:43:13,276 DEBUG
> [RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=60450]
> ipc.CallRunner(141): callId: 49 service: MasterService methodName: MoveRegion
> size: 106 connection: 192.168.1.134:60743 deadline: 1519253053263
> java.io.IOException:
> hri=IntegrationTestBigLinkedList,\x8E8\xE3\x8E8\xE3\x8E5,1519252895022.236bbedde32e4549691c108a1a7005a8.,
> source=, destination=mdrob-mbp.hsd1.tx.comcast.net,60456,1519252856027
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:465)
> 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)
> Caused by: java.lang.AssertionError:
> hri=IntegrationTestBigLinkedList,\x8E8\xE3\x8E8\xE3\x8E5,1519252895022.236bbedde32e4549691c108a1a7005a8.,
> source=, destination=mdrob-mbp.hsd1.tx.comcast.net,60456,1519252856027
> at org.apache.hadoop.hbase.master.HMaster.move(HMaster.java:1691)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.moveRegion(MasterRpcServices.java:1348)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:406)
> ... 3 more
> {code}
> The assertion that it trips is:
> {code}
> // Now we can do the move
> RegionPlan rp = new RegionPlan(hri, regionState.getServerName(), dest);
> assert rp.getDestination() != null: rp.toString() + " " + dest;
> assert rp.getSource() != null: rp.toString();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19893) restore_snapshot is broken in master branch
[
https://issues.apache.org/jira/browse/HBASE-19893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373983#comment-16373983
]
Toshihiro Suzuki commented on HBASE-19893:
--
I attached v1 patch. To reproduce the issue, we need the snippets of
HBaseTestingUtility.java and TestRestoreSnapshotFromClient.java.
> restore_snapshot is broken in master branch
> ---
>
> Key: HBASE-19893
> URL: https://issues.apache.org/jira/browse/HBASE-19893
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Critical
> Attachments: HBASE-19893.master.001.patch
>
>
> When I was investigating HBASE-19850, I found restore_snapshot didn't work in
> master branch.
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code:java}
> create "test", "cf"
> {code}
> 2. Load data (2000 rows) to the table
> {code:java}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code:java}
> split "test"
> {code}
> 4. Take a snapshot
> {code:java}
> snapshot "test", "snap"
> {code}
> 5. Load more data (2000 rows) to the table and split the table agin
> {code:java}
> (2000...4000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> split "test"
> {code}
> 6. Restore the table from the snapshot
> {code:java}
> disable "test"
> restore_snapshot "snap"
> enable "test"
> {code}
> 7. Scan the table
> {code:java}
> scan "test"
> {code}
> However, this scan returns only 244 rows (it should return 2000 rows) like
> the following:
> {code:java}
> hbase(main):038:0> scan "test"
> ROW COLUMN+CELL
> row78 column=cf:col, timestamp=1517298307049, value=val
>
> row999 column=cf:col, timestamp=1517298307608, value=val
> 244 row(s)
> Took 0.1500 seconds
> {code}
>
> Also, the restored table should have 2 online regions but it has 3 online
> regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19893) restore_snapshot is broken in master branch
[
https://issues.apache.org/jira/browse/HBASE-19893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-19893:
-
Status: Patch Available (was: Open)
> restore_snapshot is broken in master branch
> ---
>
> Key: HBASE-19893
> URL: https://issues.apache.org/jira/browse/HBASE-19893
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Critical
> Attachments: HBASE-19893.master.001.patch
>
>
> When I was investigating HBASE-19850, I found restore_snapshot didn't work in
> master branch.
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code:java}
> create "test", "cf"
> {code}
> 2. Load data (2000 rows) to the table
> {code:java}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code:java}
> split "test"
> {code}
> 4. Take a snapshot
> {code:java}
> snapshot "test", "snap"
> {code}
> 5. Load more data (2000 rows) to the table and split the table agin
> {code:java}
> (2000...4000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> split "test"
> {code}
> 6. Restore the table from the snapshot
> {code:java}
> disable "test"
> restore_snapshot "snap"
> enable "test"
> {code}
> 7. Scan the table
> {code:java}
> scan "test"
> {code}
> However, this scan returns only 244 rows (it should return 2000 rows) like
> the following:
> {code:java}
> hbase(main):038:0> scan "test"
> ROW COLUMN+CELL
> row78 column=cf:col, timestamp=1517298307049, value=val
>
> row999 column=cf:col, timestamp=1517298307608, value=val
> 244 row(s)
> Took 0.1500 seconds
> {code}
>
> Also, the restored table should have 2 online regions but it has 3 online
> regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19893) restore_snapshot is broken in master branch
[
https://issues.apache.org/jira/browse/HBASE-19893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-19893:
-
Attachment: HBASE-19893.master.001.patch
> restore_snapshot is broken in master branch
> ---
>
> Key: HBASE-19893
> URL: https://issues.apache.org/jira/browse/HBASE-19893
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Critical
> Attachments: HBASE-19893.master.001.patch
>
>
> When I was investigating HBASE-19850, I found restore_snapshot didn't work in
> master branch.
>
> Steps to reproduce are as follows:
> 1. Create a table
> {code:java}
> create "test", "cf"
> {code}
> 2. Load data (2000 rows) to the table
> {code:java}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code:java}
> split "test"
> {code}
> 4. Take a snapshot
> {code:java}
> snapshot "test", "snap"
> {code}
> 5. Load more data (2000 rows) to the table and split the table agin
> {code:java}
> (2000...4000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> split "test"
> {code}
> 6. Restore the table from the snapshot
> {code:java}
> disable "test"
> restore_snapshot "snap"
> enable "test"
> {code}
> 7. Scan the table
> {code:java}
> scan "test"
> {code}
> However, this scan returns only 244 rows (it should return 2000 rows) like
> the following:
> {code:java}
> hbase(main):038:0> scan "test"
> ROW COLUMN+CELL
> row78 column=cf:col, timestamp=1517298307049, value=val
>
> row999 column=cf:col, timestamp=1517298307608, value=val
> 244 row(s)
> Took 0.1500 seconds
> {code}
>
> Also, the restored table should have 2 online regions but it has 3 online
> regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20048) Revert serial replication feature
[ https://issues.apache.org/jira/browse/HBASE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373975#comment-16373975 ] Duo Zhang commented on HBASE-20048: --- Reverted from master and branch-2. Let me try the revert path in HBASE-9465 to revert it from branch-1. > Revert serial replication feature > - > > Key: HBASE-20048 > URL: https://issues.apache.org/jira/browse/HBASE-20048 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-20048-v1.patch, HBASE-20048-v2.patch, > HBASE-20048.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19401) Add missing security checks in RSRpcServices
[ https://issues.apache.org/jira/browse/HBASE-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373968#comment-16373968 ] Hudson commented on HBASE-19401: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4633 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4633/]) HBASE-19401 Add missing security checks in RSRpcServices (appy: rev 51f7b75f1ff368b985fc1932c2be0d7fb004538e) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAdminOnlyOperations.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java > Add missing security checks in RSRpcServices > > > Key: HBASE-19401 > URL: https://issues.apache.org/jira/browse/HBASE-19401 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Assignee: Appy >Priority: Major > Attachments: HBASE-19401.master.001.patch, > HBASE-19401.master.002.patch > > > The following RPC methods in RSRpcServices do not have ACL check for ADMIN > rights. > - execRegionServerService -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17825) Backup: further optimizations
[
https://issues.apache.org/jira/browse/HBASE-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373952#comment-16373952
]
Hadoop QA commented on HBASE-17825:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
21s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
14s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
22s{color} | {color:red} hbase-mapreduce: The patch generated 15 new + 21
unchanged - 2 fixed = 36 total (was 23) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
16s{color} | {color:red} hbase-backup: The patch generated 5 new + 0 unchanged
- 0 fixed = 5 total (was 0) {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 5 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
42s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 42s{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} javadoc {color} | {color:green} 0m
56s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}105m
39s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 12m
28s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m
12s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}176m 59s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-17825 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12911657/HBASE-17825-v4.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux d6e0e9522086 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
[jira] [Updated] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-20049:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0-beta-2
Status: Resolved (was: Patch Available)
Thanks for the reminder.
> Region replicas of SPLIT and MERGED regions are kept in in-memory states
> until restarting master
>
>
> Key: HBASE-20049
> URL: https://issues.apache.org/jira/browse/HBASE-20049
> Project: HBase
> Issue Type: Bug
> Components: read replicas
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-20049.master.001.patch,
> HBASE-20049.master.002.patch, HBASE-20049.master.003.patch
>
>
> Currently, when regions are split or merged, region replicas of the regions
> will become CLOSED state but will not be deleted from in-memory states (e.g.
> AssignmentManager). These region replicas are deleted when restarting master,
> but I think they should be deleted during splitting and merging regions.
> One problem with this is the outdated region replicas can be online. Steps to
> reproduce are as follows:
> 1. Create a table with enabling region replication.
> {code}
> create "test", "cf", {REGION_REPLICATION => 2}
> {code}
> 2. Load data to the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Disable and enable the table
> {code}
> disable "test"
> enable "test"
> {code}
> After doing those steps, the outdated region replica will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19974) Decommissioned servers cannot be removed by remove_servers_rsgroup mehods
[
https://issues.apache.org/jira/browse/HBASE-19974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373912#comment-16373912
]
Hadoop QA commented on HBASE-19974:
---
| (x) *{color:red}-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:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
35s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
42s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
21s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
24s{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} 4m
37s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 3s{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} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 14m 7s{color}
| {color:red} hbase-rsgroup in the patch failed. {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} 45m 27s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.rsgroup.TestRSGroups |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:9f2f2db |
| JIRA Issue | HBASE-19974 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12911662/HBASE-19974.branch-2.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 64c1d74877d1 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@2/component/dev-support/hbase-personality.sh
|
| git revision | branch-2 / 991e163cc2 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/11632/artifact/patchprocess/patch-unit-hbase-rsgroup.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/11632/testReport/ |
| Max. process+thread count | 2723 (vs. ulimit of 1) |
| modules | C: hbase-rsgroup U: hbase-rsgroup |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/11632/console |
| Powered by | Apache Yetus 0.7.0
[jira] [Commented] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373910#comment-16373910
]
Pankaj Kumar commented on HBASE-20049:
--
Hi [~yuzhih...@gmail.com], we already have HBASE-19553 which got committed in
branch-1 yesterday.
> Region replicas of SPLIT and MERGED regions are kept in in-memory states
> until restarting master
>
>
> Key: HBASE-20049
> URL: https://issues.apache.org/jira/browse/HBASE-20049
> Project: HBase
> Issue Type: Bug
> Components: read replicas
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-20049.master.001.patch,
> HBASE-20049.master.002.patch, HBASE-20049.master.003.patch
>
>
> Currently, when regions are split or merged, region replicas of the regions
> will become CLOSED state but will not be deleted from in-memory states (e.g.
> AssignmentManager). These region replicas are deleted when restarting master,
> but I think they should be deleted during splitting and merging regions.
> One problem with this is the outdated region replicas can be online. Steps to
> reproduce are as follows:
> 1. Create a table with enabling region replication.
> {code}
> create "test", "cf", {REGION_REPLICATION => 2}
> {code}
> 2. Load data to the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Disable and enable the table
> {code}
> disable "test"
> enable "test"
> {code}
> After doing those steps, the outdated region replica will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20024) TestMergeTableRegionsProcedure is STILL flakey
[ https://issues.apache.org/jira/browse/HBASE-20024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373911#comment-16373911 ] stack commented on HBASE-20024: --- Thank you [~uagashe] > TestMergeTableRegionsProcedure is STILL flakey > -- > > Key: HBASE-20024 > URL: https://issues.apache.org/jira/browse/HBASE-20024 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Attachments: HBASE-20024.branch-2.001.patch > > > This is a follow-on from HBASE-20015. Root issue is that merge does not > support rollback once it has hit the point-of-no-return; it can only > roll-forward at this point. > HBASE-18018 added abort to all procedures. HBASE-18016 added ignoring abort > to the truncate procedure to get around flakeyness. HBASE-20022 is a new > issue to figure what to do w/ unabortable procedures. > Meantime, merge and split have PONR and the procedure executor test harness > does abort regardless making these tests flakies. Adding an ignore of the > abort once into the PONR makes sense (Always? HBASE-20022 is for those as yet > unknown cases where it does not). Let me ignore to merge and split in this > issue to address flakeyness. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-17825) Backup: further optimizations
[
https://issues.apache.org/jira/browse/HBASE-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373909#comment-16373909
]
stack edited comment on HBASE-17825 at 2/23/18 4:24 AM:
bq. What are our compatibility guarantees on WALPlayer?
@InterfaceAudience.Public
public class WALPlayer extends Configured implements Tool {
A recent fix ensured hbase-1 can play hbase-2 WALs and vice-versa.
How does this change output?
was (Author: stack):
bq. What are our compatibility guarantees on WALPlayer?
@InterfaceAudience.Public
public class WALPlayer extends Configured implements Tool {
A recent fix ensured hbase-1 can play hbase-2 WALs and vice-versa.
How does this change
> Backup: further optimizations
> -
>
> Key: HBASE-17825
> URL: https://issues.apache.org/jira/browse/HBASE-17825
> Project: HBase
> Issue Type: Improvement
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Critical
> Labels: backup
> Fix For: 3.0.0
>
> Attachments: HBASE-17825-v1.patch, HBASE-17825-v2.patch,
> HBASE-17825-v3.patch, HBASE-17825-v4.patch
>
>
> Some phases of backup and restore can be optimized:
> # WALPlayer support for multiple tables
> # Run DistCp once per all tables during backup/restore
> The eventual goal:
> # 2 M/R jobs per backup/restore
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-17825) Backup: further optimizations
[
https://issues.apache.org/jira/browse/HBASE-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373909#comment-16373909
]
stack commented on HBASE-17825:
---
bq. What are our compatibility guarantees on WALPlayer?
@InterfaceAudience.Public
public class WALPlayer extends Configured implements Tool {
A recent fix ensured hbase-1 can play hbase-2 WALs and vice-versa.
How does this change
> Backup: further optimizations
> -
>
> Key: HBASE-17825
> URL: https://issues.apache.org/jira/browse/HBASE-17825
> Project: HBase
> Issue Type: Improvement
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Critical
> Labels: backup
> Fix For: 3.0.0
>
> Attachments: HBASE-17825-v1.patch, HBASE-17825-v2.patch,
> HBASE-17825-v3.patch, HBASE-17825-v4.patch
>
>
> Some phases of backup and restore can be optimized:
> # WALPlayer support for multiple tables
> # Run DistCp once per all tables during backup/restore
> The eventual goal:
> # 2 M/R jobs per backup/restore
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373900#comment-16373900 ] stack commented on HBASE-20055: --- I put some questions up on rb... I think you've answered most of them here. Why the test failure? Thanks [~uagashe] > Remove declaration of un-thrown exceptions and unused > setRegionStateBackToOpen() from MergeTableRegionsProcedure > > > Key: HBASE-20055 > URL: https://issues.apache.org/jira/browse/HBASE-20055 > Project: HBase > Issue Type: Improvement > Components: amv2 >Affects Versions: 2.0.0-beta-1 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Fix For: 2.0.0-beta-2 > > Attachments: hbase-20055.master.001.patch > > > A few methods declare exceptions in throws statement that are not thrown and > method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373897#comment-16373897
]
Ted Yu commented on HBASE-20049:
Pushed to branch-2 and master.
If you want this to go to branch-1, please attach patch.
> Region replicas of SPLIT and MERGED regions are kept in in-memory states
> until restarting master
>
>
> Key: HBASE-20049
> URL: https://issues.apache.org/jira/browse/HBASE-20049
> Project: HBase
> Issue Type: Bug
> Components: read replicas
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-20049.master.001.patch,
> HBASE-20049.master.002.patch, HBASE-20049.master.003.patch
>
>
> Currently, when regions are split or merged, region replicas of the regions
> will become CLOSED state but will not be deleted from in-memory states (e.g.
> AssignmentManager). These region replicas are deleted when restarting master,
> but I think they should be deleted during splitting and merging regions.
> One problem with this is the outdated region replicas can be online. Steps to
> reproduce are as follows:
> 1. Create a table with enabling region replication.
> {code}
> create "test", "cf", {REGION_REPLICATION => 2}
> {code}
> 2. Load data to the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Disable and enable the table
> {code}
> disable "test"
> enable "test"
> {code}
> After doing those steps, the outdated region replica will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20048) Revert serial replication feature
[
https://issues.apache.org/jira/browse/HBASE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373891#comment-16373891
]
Hadoop QA commented on HBASE-20048:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
29s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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 5 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
35s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 12m
38s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
21s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
11s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
18s{color} | {color:green} The patch hbase-common passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
7s{color} | {color:green} The patch hbase-protocol passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} hbase-client: The patch generated 0 new + 233
unchanged - 8 fixed = 233 total (was 241) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s{color} | {color:green} hbase-server: The patch generated 0 new + 337
unchanged - 51 fixed = 337 total (was 388) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
57s{color} | {color:green} root: The patch generated 0 new + 570 unchanged - 59
fixed = 570 total (was 629) {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} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
7s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m
3s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.5. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m
58s{color} | {color:red} The patch causes 10 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m
3s{color} | {color:red} The patch causes 10 errors with Hadoop v3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
3m 47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
27s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color}
[jira] [Commented] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373886#comment-16373886
]
Ted Yu commented on HBASE-20049:
+1
> Region replicas of SPLIT and MERGED regions are kept in in-memory states
> until restarting master
>
>
> Key: HBASE-20049
> URL: https://issues.apache.org/jira/browse/HBASE-20049
> Project: HBase
> Issue Type: Bug
> Components: read replicas
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-20049.master.001.patch,
> HBASE-20049.master.002.patch, HBASE-20049.master.003.patch
>
>
> Currently, when regions are split or merged, region replicas of the regions
> will become CLOSED state but will not be deleted from in-memory states (e.g.
> AssignmentManager). These region replicas are deleted when restarting master,
> but I think they should be deleted during splitting and merging regions.
> One problem with this is the outdated region replicas can be online. Steps to
> reproduce are as follows:
> 1. Create a table with enabling region replication.
> {code}
> create "test", "cf", {REGION_REPLICATION => 2}
> {code}
> 2. Load data to the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Disable and enable the table
> {code}
> disable "test"
> enable "test"
> {code}
> After doing those steps, the outdated region replica will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20048) Revert serial replication feature
[ https://issues.apache.org/jira/browse/HBASE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373883#comment-16373883 ] stack commented on HBASE-20048: --- [~Apache9] Thanks. +1 on patch (I think the test is a flakey?) > Revert serial replication feature > - > > Key: HBASE-20048 > URL: https://issues.apache.org/jira/browse/HBASE-20048 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-20048-v1.patch, HBASE-20048-v2.patch, > HBASE-20048.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373877#comment-16373877
]
Hadoop QA commented on HBASE-20049:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
5s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
2s{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
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
58s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m
52s{color} | {color:red} The patch causes 10 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m
57s{color} | {color:red} The patch causes 10 errors with Hadoop v3.0.0. {color}
|
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
0m 51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
26s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}108m
30s{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}138m 27s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20049 |
| JIRA Patch URL |
[jira] [Updated] (HBASE-19974) Decommissioned servers cannot be removed by remove_servers_rsgroup mehods
[ https://issues.apache.org/jira/browse/HBASE-19974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-19974: --- Status: Patch Available (was: Open) > Decommissioned servers cannot be removed by remove_servers_rsgroup mehods > - > > Key: HBASE-19974 > URL: https://issues.apache.org/jira/browse/HBASE-19974 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0-beta-2 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-19974.branch-2.001.patch, > HBASE-19974.branch-2.002.patch > > > When remove servers from a rsgroup, it will check the server is not online or > dead. But when we decommision a server, the server will be both in online > list and drainning list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19974) Decommissioned servers cannot be removed by remove_servers_rsgroup mehods
[ https://issues.apache.org/jira/browse/HBASE-19974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-19974: --- Attachment: HBASE-19974.branch-2.002.patch > Decommissioned servers cannot be removed by remove_servers_rsgroup mehods > - > > Key: HBASE-19974 > URL: https://issues.apache.org/jira/browse/HBASE-19974 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0-beta-2 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-19974.branch-2.001.patch, > HBASE-19974.branch-2.002.patch > > > When remove servers from a rsgroup, it will check the server is not online or > dead. But when we decommision a server, the server will be both in online > list and drainning list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[
https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373858#comment-16373858
]
Hadoop QA commented on HBASE-20055:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
3s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
6s{color} | {color:green} hbase-server: The patch generated 0 new + 72
unchanged - 2 fixed = 72 total (was 74) {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
46s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 59s{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} javadoc {color} | {color:green} 0m
35s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}115m 27s{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}155m 3s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20055 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12911644/hbase-20055.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 4d461b12572f 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@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 51f7b75f1f |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/11628/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/11628/testReport/ |
| Max. process+thread count | 4887 (vs.
[jira] [Commented] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373835#comment-16373835
]
Hadoop QA commented on HBASE-20001:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 16m
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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1.4 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
16s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
33s{color} | {color:green} branch-1.4 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} branch-1.4 passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
25s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
7s{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
13s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} branch-1.4 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} branch-1.4 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} hbase-server: The patch generated 0 new + 349
unchanged - 12 fixed = 349 total (was 361) {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} 2m
40s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 59s{color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.5 2.7.4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}118m 22s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}169m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.security.visibility.TestVisibilityLabelsWithACL |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:74e3133 |
| JIRA Issue | HBASE-20001 |
| JIRA Patch URL |
[jira] [Commented] (HBASE-17825) Backup: further optimizations
[
https://issues.apache.org/jira/browse/HBASE-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373830#comment-16373830
]
Vladimir Rodionov commented on HBASE-17825:
---
{quote}
What are our compatibility guarantees on WALPlayer?
{quote}
None. HBASE 2.0 is not backward compatible with 1.x applications to my best
knowledge.
> Backup: further optimizations
> -
>
> Key: HBASE-17825
> URL: https://issues.apache.org/jira/browse/HBASE-17825
> Project: HBase
> Issue Type: Improvement
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Critical
> Labels: backup
> Fix For: 3.0.0
>
> Attachments: HBASE-17825-v1.patch, HBASE-17825-v2.patch,
> HBASE-17825-v3.patch, HBASE-17825-v4.patch
>
>
> Some phases of backup and restore can be optimized:
> # WALPlayer support for multiple tables
> # Run DistCp once per all tables during backup/restore
> The eventual goal:
> # 2 M/R jobs per backup/restore
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373829#comment-16373829
]
Hadoop QA commented on HBASE-20001:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1.4 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
58s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} branch-1.4 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} branch-1.4 passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
30s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
12s{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
11s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} branch-1.4 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} branch-1.4 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
22s{color} | {color:green} hbase-server: The patch generated 0 new + 349
unchanged - 12 fixed = 349 total (was 361) {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} 2m
38s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 42s{color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.5 2.7.4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}110m
30s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}144m 47s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:74e3133 |
| JIRA Issue | HBASE-20001 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12911642/HBASE-20001.branch-1.4.005.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
[jira] [Updated] (HBASE-17825) Backup: further optimizations
[ https://issues.apache.org/jira/browse/HBASE-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17825: -- Attachment: HBASE-17825-v4.patch > Backup: further optimizations > - > > Key: HBASE-17825 > URL: https://issues.apache.org/jira/browse/HBASE-17825 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Critical > Labels: backup > Fix For: 3.0.0 > > Attachments: HBASE-17825-v1.patch, HBASE-17825-v2.patch, > HBASE-17825-v3.patch, HBASE-17825-v4.patch > > > Some phases of backup and restore can be optimized: > # WALPlayer support for multiple tables > # Run DistCp once per all tables during backup/restore > The eventual goal: > # 2 M/R jobs per backup/restore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-19400) Add missing security checks in MasterRpcServices
[ https://issues.apache.org/jira/browse/HBASE-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy reopened HBASE-19400: -- Uploading patch for branch-1 Patch is both for this jira and few lines in HBASE-19401 > Add missing security checks in MasterRpcServices > > > Key: HBASE-19400 > URL: https://issues.apache.org/jira/browse/HBASE-19400 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Assignee: Appy >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19400.branch-1.001.patch, > HBASE-19400.master.001.patch, HBASE-19400.master.002.patch, > HBASE-19400.master.003.patch, HBASE-19400.master.004.patch, > HBASE-19400.master.004.patch, HBASE-19400.master.005.patch, > HBASE-19400.master.006.patch, HBASE-19400.master.007.patch, > HBASE-19400.master.007.patch > > > The following RPC methods in MasterRpcServices do not have ACL check for > ADMIN rights. > - normalize > - setNormalizerRunning > - runCatalogScan > - enableCatalogJanitor > - runCleanerChore > - setCleanerChoreRunning > - execMasterService > - execProcedure > - execProcedureWithRet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19400) Add missing security checks in MasterRpcServices
[ https://issues.apache.org/jira/browse/HBASE-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19400: - Attachment: HBASE-19400.branch-1.001.patch > Add missing security checks in MasterRpcServices > > > Key: HBASE-19400 > URL: https://issues.apache.org/jira/browse/HBASE-19400 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Assignee: Appy >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19400.branch-1.001.patch, > HBASE-19400.master.001.patch, HBASE-19400.master.002.patch, > HBASE-19400.master.003.patch, HBASE-19400.master.004.patch, > HBASE-19400.master.004.patch, HBASE-19400.master.005.patch, > HBASE-19400.master.006.patch, HBASE-19400.master.007.patch, > HBASE-19400.master.007.patch > > > The following RPC methods in MasterRpcServices do not have ACL check for > ADMIN rights. > - normalize > - setNormalizerRunning > - runCatalogScan > - enableCatalogJanitor > - runCleanerChore > - setCleanerChoreRunning > - execMasterService > - execProcedure > - execProcedureWithRet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19401) Add missing security checks in RSRpcServices
[ https://issues.apache.org/jira/browse/HBASE-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373807#comment-16373807 ] Appy commented on HBASE-19401: -- Thanks for the review stack. Pushed to master and branch-2. Trying to backport HBASE-19400 and this one to branch-1 (since it's security fix), so many merge conflicts ..sigh. > Add missing security checks in RSRpcServices > > > Key: HBASE-19401 > URL: https://issues.apache.org/jira/browse/HBASE-19401 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Assignee: Appy >Priority: Major > Attachments: HBASE-19401.master.001.patch, > HBASE-19401.master.002.patch > > > The following RPC methods in RSRpcServices do not have ACL check for ADMIN > rights. > - execRegionServerService -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373787#comment-16373787
]
Toshihiro Suzuki commented on HBASE-20049:
--
Thank you [~yuzhih...@gmail.com]. I just attached v3 patch for the review.
Because the constructor you mentioned was not used, I removed it.
> Region replicas of SPLIT and MERGED regions are kept in in-memory states
> until restarting master
>
>
> Key: HBASE-20049
> URL: https://issues.apache.org/jira/browse/HBASE-20049
> Project: HBase
> Issue Type: Bug
> Components: read replicas
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-20049.master.001.patch,
> HBASE-20049.master.002.patch, HBASE-20049.master.003.patch
>
>
> Currently, when regions are split or merged, region replicas of the regions
> will become CLOSED state but will not be deleted from in-memory states (e.g.
> AssignmentManager). These region replicas are deleted when restarting master,
> but I think they should be deleted during splitting and merging regions.
> One problem with this is the outdated region replicas can be online. Steps to
> reproduce are as follows:
> 1. Create a table with enabling region replication.
> {code}
> create "test", "cf", {REGION_REPLICATION => 2}
> {code}
> 2. Load data to the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Disable and enable the table
> {code}
> disable "test"
> enable "test"
> {code}
> After doing those steps, the outdated region replica will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-20049:
-
Attachment: HBASE-20049.master.003.patch
> Region replicas of SPLIT and MERGED regions are kept in in-memory states
> until restarting master
>
>
> Key: HBASE-20049
> URL: https://issues.apache.org/jira/browse/HBASE-20049
> Project: HBase
> Issue Type: Bug
> Components: read replicas
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-20049.master.001.patch,
> HBASE-20049.master.002.patch, HBASE-20049.master.003.patch
>
>
> Currently, when regions are split or merged, region replicas of the regions
> will become CLOSED state but will not be deleted from in-memory states (e.g.
> AssignmentManager). These region replicas are deleted when restarting master,
> but I think they should be deleted during splitting and merging regions.
> One problem with this is the outdated region replicas can be online. Steps to
> reproduce are as follows:
> 1. Create a table with enabling region replication.
> {code}
> create "test", "cf", {REGION_REPLICATION => 2}
> {code}
> 2. Load data to the table
> {code}
> (0...2000).each{|i| put "test", "row#{i}", "cf:col", "val"}
> {code}
> 3. Split the table
> {code}
> split "test"
> {code}
> 4. Disable and enable the table
> {code}
> disable "test"
> enable "test"
> {code}
> After doing those steps, the outdated region replica will be online.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-9465) Push entries to peer clusters serially
[ https://issues.apache.org/jira/browse/HBASE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-9465: - Attachment: HBASE-20048-v2.patch > Push entries to peer clusters serially > -- > > Key: HBASE-9465 > URL: https://issues.apache.org/jira/browse/HBASE-9465 > Project: HBase > Issue Type: New Feature > Components: regionserver, Replication >Affects Versions: 2.0.0, 1.4.0 >Reporter: Honghua Feng >Assignee: Phil Yang >Priority: Critical > Fix For: 2.0.0, 1.5.0 > > Attachments: HBASE-20048-v2.patch, HBASE-9465-branch-1-v1.patch, > HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, > HBASE-9465-branch-1-v3.patch, HBASE-9465-branch-1-v4.patch, > HBASE-9465-branch-1-v4.patch, HBASE-9465-branch-1.v4.revert.patch, > HBASE-9465-v1.patch, HBASE-9465-v2.patch, HBASE-9465-v2.patch, > HBASE-9465-v3.patch, HBASE-9465-v4.patch, HBASE-9465-v5.patch, > HBASE-9465-v6.patch, HBASE-9465-v6.patch, HBASE-9465-v7.patch, > HBASE-9465-v7.patch, HBASE-9465.pdf > > > When region-move or RS failure occurs in master cluster, the hlog entries > that are not pushed before region-move or RS-failure will be pushed by > original RS(for region move) or another RS which takes over the remained hlog > of dead RS(for RS failure), and the new entries for the same region(s) will > be pushed by the RS which now serves the region(s), but they push the hlog > entries of a same region concurrently without coordination. > This treatment can possibly lead to data inconsistency between master and > peer clusters: > 1. there are put and then delete written to master cluster > 2. due to region-move / RS-failure, they are pushed by different > replication-source threads to peer cluster > 3. if delete is pushed to peer cluster before put, and flush and > major-compact occurs in peer cluster before put is pushed to peer cluster, > the delete is collected and the put remains in peer cluster > In this scenario, the put remains in peer cluster, but in master cluster the > put is masked by the delete, hence data inconsistency between master and peer > clusters -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20048) Revert serial replication feature
[ https://issues.apache.org/jira/browse/HBASE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20048: -- Attachment: HBASE-20048-v2.patch > Revert serial replication feature > - > > Key: HBASE-20048 > URL: https://issues.apache.org/jira/browse/HBASE-20048 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-20048-v1.patch, HBASE-20048-v2.patch, > HBASE-20048.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373742#comment-16373742 ] Umesh Agashe commented on HBASE-20055: -- Thanks [~yuzhih...@gmail.com]! > Remove declaration of un-thrown exceptions and unused > setRegionStateBackToOpen() from MergeTableRegionsProcedure > > > Key: HBASE-20055 > URL: https://issues.apache.org/jira/browse/HBASE-20055 > Project: HBase > Issue Type: Improvement > Components: amv2 >Affects Versions: 2.0.0-beta-1 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Fix For: 2.0.0-beta-2 > > Attachments: hbase-20055.master.001.patch > > > A few methods declare exceptions in throws statement that are not thrown and > method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373741#comment-16373741 ] Ted Yu commented on HBASE-20055: +1 > Remove declaration of un-thrown exceptions and unused > setRegionStateBackToOpen() from MergeTableRegionsProcedure > > > Key: HBASE-20055 > URL: https://issues.apache.org/jira/browse/HBASE-20055 > Project: HBase > Issue Type: Improvement > Components: amv2 >Affects Versions: 2.0.0-beta-1 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Fix For: 2.0.0-beta-2 > > Attachments: hbase-20055.master.001.patch > > > A few methods declare exceptions in throws statement that are not thrown and > method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20048) Revert serial replication feature
[ https://issues.apache.org/jira/browse/HBASE-20048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373735#comment-16373735 ] Duo Zhang commented on HBASE-20048: --- As I said in the parent issue, the current implementation use a different row key pattern(the encoded region name) instead of the region name, this may introduce problem when region replica feature is enabled. And also, this may hurt our splittable meta approach. So I plan to reimplement the meta related stuff. The other parts are good, will reuse the code so will not spend a lot of time I believe. And since 2.0.0 is feature freezed, I plan to revert it from 2.0.0 and land it in 2.1. Thanks. > Revert serial replication feature > - > > Key: HBASE-20048 > URL: https://issues.apache.org/jira/browse/HBASE-20048 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-20048-v1.patch, HBASE-20048.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-20055: - Status: Patch Available (was: In Progress) > Remove declaration of un-thrown exceptions and unused > setRegionStateBackToOpen() from MergeTableRegionsProcedure > > > Key: HBASE-20055 > URL: https://issues.apache.org/jira/browse/HBASE-20055 > Project: HBase > Issue Type: Improvement > Components: amv2 >Affects Versions: 2.0.0-beta-1 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Fix For: 2.0.0-beta-2 > > Attachments: hbase-20055.master.001.patch > > > A few methods declare exceptions in throws statement that are not thrown and > method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-20055: - Attachment: hbase-20055.master.001.patch > Remove declaration of un-thrown exceptions and unused > setRegionStateBackToOpen() from MergeTableRegionsProcedure > > > Key: HBASE-20055 > URL: https://issues.apache.org/jira/browse/HBASE-20055 > Project: HBase > Issue Type: Improvement > Components: amv2 >Affects Versions: 2.0.0-beta-1 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Fix For: 2.0.0-beta-2 > > Attachments: hbase-20055.master.001.patch > > > A few methods declare exceptions in throws statement that are not thrown and > method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19364) Truncate_preserve fails with table when replica region > 1
[
https://issues.apache.org/jira/browse/HBASE-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373732#comment-16373732
]
Hadoop QA commented on HBASE-19364:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
29s{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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
17s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
56s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
43s{color} | {color:green} branch-1 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
47s{color} | {color:green} branch-1 passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
35s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
52s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m
5s{color} | {color:red} hbase-client in branch-1 has 1 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} branch-1 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} branch-1 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
11s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
42s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
47s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} hbase-client: The patch generated 0 new + 83
unchanged - 1 fixed = 83 total (was 84) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} The patch hbase-server 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} 2m
5s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m
50s{color} | {color:red} The patch causes 44 errors with Hadoop v2.4.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
34s{color} | {color:red} The patch causes 44 errors with Hadoop v2.5.2. {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
20s{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 with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
23s{color} | {color:green} hbase-client in the patch passed. {color} |
|
[jira] [Work started] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
[ https://issues.apache.org/jira/browse/HBASE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-20055 started by Umesh Agashe. > Remove declaration of un-thrown exceptions and unused > setRegionStateBackToOpen() from MergeTableRegionsProcedure > > > Key: HBASE-20055 > URL: https://issues.apache.org/jira/browse/HBASE-20055 > Project: HBase > Issue Type: Improvement > Components: amv2 >Affects Versions: 2.0.0-beta-1 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Minor > Fix For: 2.0.0-beta-2 > > > A few methods declare exceptions in throws statement that are not thrown and > method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure
Umesh Agashe created HBASE-20055: Summary: Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure Key: HBASE-20055 URL: https://issues.apache.org/jira/browse/HBASE-20055 Project: HBase Issue Type: Improvement Components: amv2 Affects Versions: 2.0.0-beta-1 Reporter: Umesh Agashe Assignee: Umesh Agashe Fix For: 2.0.0-beta-2 A few methods declare exceptions in throws statement that are not thrown and method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvel Thirumoolan updated HBASE-20001:
-
Attachment: HBASE-20001.branch-1.4.005.patch
> cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
> -
>
> Key: HBASE-20001
> URL: https://issues.apache.org/jira/browse/HBASE-20001
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.1.7
>Reporter: Francis Liu
>Assignee: Thiruvel Thirumoolan
>Priority: Major
> Fix For: 1.3.2, 1.5.0, 1.2.7, 1.4.3
>
> Attachments: HBASE-20001.branch-1.4.001.patch,
> HBASE-20001.branch-1.4.002.patch, HBASE-20001.branch-1.4.003.patch,
> HBASE-20001.branch-1.4.004.patch, HBASE-20001.branch-1.4.005.patch
>
>
> In RegionStates.cleanIfNoMetaEntry()
> {{if (MetaTableAccessor.getRegion(server.getConnection(),
> hri.getEncodedNameAsBytes()) == null) {}}
> {{regionOffline(hri);}}
> {{FSUtils.deleteRegionDir(server.getConfiguration(), hri);}}
> }
> But api expects regionname
> {{public static Pair getRegion(Connection
> connection, byte [] regionName)}}
> So we might end up cleaning good regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20044) TestClientClusterStatus is flakey
[
https://issues.apache.org/jira/browse/HBASE-20044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373691#comment-16373691
]
Hudson commented on HBASE-20044:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4632 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4632/])
HBASE-20044 TestClientClusterStatus is flakey" Revert "Revert (stack: rev
3434e99e6c728d59ba99141df3730f3e70e0059c)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/TestClientClusterStatus.java
> TestClientClusterStatus is flakey
> -
>
> Key: HBASE-20044
> URL: https://issues.apache.org/jira/browse/HBASE-20044
> Project: HBase
> Issue Type: Sub-task
> Components: flakey
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20044.branch-2.001.patch
>
>
> It killed a nightly. Failed in flakey suite. The compare is too sensitive to
> slightest variance. Here are two failiures... one because the previous test
> had not finished putting back a Region that had been offlined, and the other
> because the count of requests was off slightly. Let me make the compare
> coarser
> {code}
> Test set: org.apache.hadoop.hbase.TestClientClusterStatus
> ---
> Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 27.858 s <<<
> FAILURE! - in org.apache.hadoop.hbase.TestClientClusterStatus
> testNone(org.apache.hadoop.hbase.TestClientClusterStatus) Time elapsed:
> 0.236 s <<< FAILURE!
> java.lang.AssertionError:
> expected: Number of backup masters: 2
> asf903.gq1.ygridcore.net,34661,1519246530655
> asf903.gq1.ygridcore.net,34734,1519246533133
> Number of live region servers: 4
> asf903.gq1.ygridcore.net,37432,1519246533632
> asf903.gq1.ygridcore.net,42964,1519246533554
> asf903.gq1.ygridcore.net,43699,1519246533376
> asf903.gq1.ygridcore.net,56911,1519246533711
> Number of dead region servers: 1
> asf903.gq1.ygridcore.net,57278,1519246533770
> Average load: 0.25
> Number of requests: 17
> Number of regions: 1
> Number of regions in transition: 0> but was: asf903.gq1.ygridcore.net,45687,1519246533030
> Number of backup masters: 2
> asf903.gq1.ygridcore.net,34661,1519246530655
> asf903.gq1.ygridcore.net,34734,1519246533133
> Number of live region servers: 4
> asf903.gq1.ygridcore.net,37432,1519246533632
> asf903.gq1.ygridcore.net,42964,1519246533554
> asf903.gq1.ygridcore.net,43699,1519246533376
> asf903.gq1.ygridcore.net,56911,1519246533711
> Number of dead region servers: 1
> asf903.gq1.ygridcore.net,57278,1519246533770
> Average load: 0.5
> Number of requests: 17
> Number of regions: 2
> Number of regions in transition: 0>
> at
> org.apache.hadoop.hbase.TestClientClusterStatus.testNone(TestClientClusterStatus.java:107)
> {code}
> and
> {code}
> [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.416
> s <<< FAILURE! - in org.apache.hadoop.hbase.TestClientClusterStatus
> [ERROR] testNone(org.apache.hadoop.hbase.TestClientClusterStatus) Time
> elapsed: 0.065 s <<< FAILURE!
> java.lang.AssertionError:
> expected: Number of backup masters: 2
> 9845c79afe69,35076,1519227086213
> 9845c79afe69,45963,1519227086363
> Number of live region servers: 4
> 9845c79afe69,34709,1519227086571
> 9845c79afe69,34961,1519227086645
> 9845c79afe69,35891,1519227086720
> 9845c79afe69,36139,1519227086486
> Number of dead region servers: 1
> 9845c79afe69,41992,1519227086820
> Average load: 0.5
> Number of requests: 17
> Number of regions: 2
> Number of regions in transition: 0> but was: 9845c79afe69,46509,1519227084385
> Number of backup masters: 2
> 9845c79afe69,35076,1519227086213
> 9845c79afe69,45963,1519227086363
> Number of live region servers: 4
> 9845c79afe69,34709,1519227086571
> 9845c79afe69,34961,1519227086645
> 9845c79afe69,35891,1519227086720
> 9845c79afe69,36139,1519227086486
> Number of dead region servers: 1
> 9845c79afe69,41992,1519227086820
> Average load: 0.5
> Number of requests: 19
> Number of regions: 2
> Number of regions in transition: 0>
> at
> org.apache.hadoop.hbase.TestClientClusterStatus.testNone(TestClientClusterStatus.java:107)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-2004) Client javadoc suggestion: add code examples about obtaining historical values
[
https://issues.apache.org/jira/browse/HBASE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373689#comment-16373689
]
Hudson commented on HBASE-2004:
---
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4632 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4632/])
Revert "HBASE-2004 TestClientClusterStatus is flakey" Revert to fix JIRA
(stack: rev 3d2e9e2125ec29c6959c98157ad378d5c53f911d)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/TestClientClusterStatus.java
HBASE-20044 TestClientClusterStatus is flakey" Revert "Revert (stack: rev
3434e99e6c728d59ba99141df3730f3e70e0059c)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/TestClientClusterStatus.java
> Client javadoc suggestion: add code examples about obtaining historical
> values
> ---
>
> Key: HBASE-2004
> URL: https://issues.apache.org/jira/browse/HBASE-2004
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.1
>Reporter: Doug Meil
>Priority: Minor
>
> The implicit support HBase provides for versioning of values is very
> powerful, but it's not all that obvious for application programmers to use it
> to obtain the historical values.
> I would like to suggest adding some comments and sample code to the Result
> class (org.apache.hadoop.hbase.client.Result) Javadoc. I know this seems
> sort of obvious to people that regularly use HBase, but I think that for new
> folks having code examples available in Javadoc is helpful because it's "one
> stop shopping" for documentation (i.e., as opposed to looking to an external
> writeup). Arguably, this type of example could also go in the HTable class
> javadoc.
> e.g.,
> HTable table = new HTable(config, "mytable");
> Scan scan = new Scan(); // no arguments indicates will scan all rows
> scan.setMaxVersions( 5 ); // setting this to 1 only returns
> current version
> ResultScanner rs = table.getScanner(scan);
> for (Iterator i = rs.iterator(); i.hasNext(); ) {
> Result r = i.next();
> // obtains current value from 'family:column'
> byte b[] = r.getValue( Bytes.toBytes("family"), Bytes.toBytes("column")
> );
> KeyValue kv[] = r.raw();
> for (int j = 0; j < kv.length; j++) {
>
>byte bv[] = kv[j].getValue();
> // this loop returns both current and historical values
>byte bc[] = kv[j].getColumn();
>// returns 'family:column'
> }
>}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20052) TestRegionOpen#testNonExistentRegionReplica fails due to NPE
[
https://issues.apache.org/jira/browse/HBASE-20052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373693#comment-16373693
]
Hudson commented on HBASE-20052:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4632 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4632/])
HBASE-20052 TestRegionOpen#testNonExistentRegionReplica fails due to NPE
(tedyu: rev d68f697f39fc0e660eb85dc9ef67a757102169f2)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionOpen.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionFileSystem.java
> TestRegionOpen#testNonExistentRegionReplica fails due to NPE
>
>
> Key: HBASE-20052
> URL: https://issues.apache.org/jira/browse/HBASE-20052
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Fix For: 1.5.0, 2.0.0-beta-2
>
> Attachments: 20052.v1.txt, 20052.v2.txt
>
>
> After HBASE-19391 was integrated, the following test failure can be observed:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.TestRegionOpen.testNonExistentRegionReplica(TestRegionOpen.java:122)
> {code}
> This was due null being returned from
> HRegionFileSystem#createRegionOnFileSystem().
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19767) Master web UI shows negative values for Remaining KVs
[ https://issues.apache.org/jira/browse/HBASE-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373692#comment-16373692 ] Hudson commented on HBASE-19767: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4632 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4632/]) HBASE-19767 Fix for Master web UI shows negative values for Remaining (stack: rev 8afa49f5d0e28e96c6e1b6c88c6ac976ac0da2b2) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMajorCompaction.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/CompactionProgress.java > Master web UI shows negative values for Remaining KVs > - > > Key: HBASE-19767 > URL: https://issues.apache.org/jira/browse/HBASE-19767 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-4 >Reporter: Jean-Marc Spaggiari >Assignee: Umesh Agashe >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: Screen Shot 2018-01-12 at 12.18.41 PM.png, > hbase-19767.master.001.patch, hbase-19767.master.001.patch, > hbase-19767.master.001.patch, hbase-19767.master.001.patch > > > In the Master Web UI, under the compaction tab, the Remaining KVs sometimes > shows negative values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvel Thirumoolan updated HBASE-20001:
-
Attachment: HBASE-20001.branch-1.4.004.patch
> cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
> -
>
> Key: HBASE-20001
> URL: https://issues.apache.org/jira/browse/HBASE-20001
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.1.7
>Reporter: Francis Liu
>Assignee: Thiruvel Thirumoolan
>Priority: Major
> Fix For: 1.3.2, 1.5.0, 1.2.7, 1.4.3
>
> Attachments: HBASE-20001.branch-1.4.001.patch,
> HBASE-20001.branch-1.4.002.patch, HBASE-20001.branch-1.4.003.patch,
> HBASE-20001.branch-1.4.004.patch
>
>
> In RegionStates.cleanIfNoMetaEntry()
> {{if (MetaTableAccessor.getRegion(server.getConnection(),
> hri.getEncodedNameAsBytes()) == null) {}}
> {{regionOffline(hri);}}
> {{FSUtils.deleteRegionDir(server.getConfiguration(), hri);}}
> }
> But api expects regionname
> {{public static Pair getRegion(Connection
> connection, byte [] regionName)}}
> So we might end up cleaning good regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19483) Add proper privilege check for rsgroup commands
[ https://issues.apache.org/jira/browse/HBASE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19483: - Hadoop Flags: Incompatible change,Reviewed (was: Reviewed) > Add proper privilege check for rsgroup commands > --- > > Key: HBASE-19483 > URL: https://issues.apache.org/jira/browse/HBASE-19483 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Guangxu Cheng >Priority: Major > Fix For: 1.4.1, 1.5.0, 2.0.0-beta-1 > > Attachments: 19483.master.011.patch, 19483.v11.patch, > 19483.v11.patch, HBASE-19483.addendum-1.patch, HBASE-19483.addendum.patch, > HBASE-19483.branch-1.001.patch, HBASE-19483.branch-1.addendum.patch, > HBASE-19483.branch-2.001.patch, HBASE-19483.branch-2.002.patch, > HBASE-19483.branch-2.003.patch, HBASE-19483.master.001.patch, > HBASE-19483.master.002.patch, HBASE-19483.master.003.patch, > HBASE-19483.master.004.patch, HBASE-19483.master.005.patch, > HBASE-19483.master.006.patch, HBASE-19483.master.007.patch, > HBASE-19483.master.008.patch, HBASE-19483.master.009.patch, > HBASE-19483.master.010.patch, HBASE-19483.master.011.patch, > HBASE-19483.master.011.patch, HBASE-19483.master.012.patch, > HBASE-19483.master.013.patch, HBASE-19483.master.014.patch > > > Currently list_rsgroups command can be executed by any user. > This is inconsistent with other list commands such as list_peers and > list_peer_configs. > We should add proper privilege check for list_rsgroups command. > privilege check should be added for get_table_rsgroup / get_server_rsgroup / > get_rsgroup commands. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20007) rest server doesn't start against hadoop-3
[
https://issues.apache.org/jira/browse/HBASE-20007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373666#comment-16373666
]
Mike Drob commented on HBASE-20007:
---
It looks like the problem is only in dev environment, on a real cluster running
hadoop 3 the rest server started without issue. I'm not sure how much of that
is $dayjob deployment magic and how much is just lifted from the assembly and
would work for other folks doing their own thing.
Tried a couple of other approaches after a bit of discussion with [~busbey],
posting my findings here so that I don't forget everything...
It might make sense to use the maven-dependency-plugin to create a separate
classpath listing for each service. Rest Server doesn't need some thrift
specific things on its classpath, Thrift Server doesn't need rest things, etc.
First problem with this approach is that dependency plugin doesn't output the
current module, which makes sense but also leads to awkward gymnastics for us
if we try to use it like that. We can put in a bunch of special case scripting
for dev environment in {{bin/hbase}} then, but this all starts going down a
path that is fairly muddy.
Further, I'm not sure what happens when we try to run this out of a binary
tarball. Leaving this a reminder to myself to check that out.
> rest server doesn't start against hadoop-3
> --
>
> Key: HBASE-20007
> URL: https://issues.apache.org/jira/browse/HBASE-20007
> Project: HBase
> Issue Type: Sub-task
> Components: REST
>Affects Versions: 2.0.0-alpha-3
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-20007.patch, HBASE-20007.patch
>
>
> While fixing HBASE-19991 I discovered that this command fails:
> {noformat}
> mvn clean package -Dhadoop.profile=3.0 -DskipTests && bin/hbase-daemon.sh
> start rest
> {noformat}
> The command itself actually succeeds, but the rest server fails to start with
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com/sun/jersey/core/spi/factory/AbstractRuntimeDelegate
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at javax.ws.rs.ext.FactoryFinder.newInstance(FactoryFinder.java:107)
> at javax.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:166)
> at
> javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:135)
> at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:120)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> at
> org.glassfish.jersey.server.model.IntrospectionModeller.extractMediaTypes(IntrospectionModeller.java:297)
> at
> org.glassfish.jersey.server.model.IntrospectionModeller.extractMediaTypes(IntrospectionModeller.java:282)
> at
> org.glassfish.jersey.server.model.IntrospectionModeller.doCreateResourceBuilder(IntrospectionModeller.java:129)
> at
> org.glassfish.jersey.server.model.IntrospectionModeller.access$000(IntrospectionModeller.java:80)
> at
> org.glassfish.jersey.server.model.IntrospectionModeller$1.call(IntrospectionModeller.java:112)
> at
> org.glassfish.jersey.server.model.IntrospectionModeller$1.call(IntrospectionModeller.java:109)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at
> org.glassfish.jersey.internal.Errors.processWithException(Errors.java:255)
> at
> org.glassfish.jersey.server.model.IntrospectionModeller.createResourceBuilder(IntrospectionModeller.java:109)
> at org.glassfish.jersey.server.model.Resource.from(Resource.java:797)
> at
> org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:465)
> at
> org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:184)
> at
>
[jira] [Commented] (HBASE-20054) Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet replicated in case of KeeperException
[
https://issues.apache.org/jira/browse/HBASE-20054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373660#comment-16373660
]
Hadoop QA commented on HBASE-20054:
---
| (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: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:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
0s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
53s{color} | {color:red} hbase-server: The patch generated 3 new + 6 unchanged
- 0 fixed = 9 total (was 6) {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
6s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m
0s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.5. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m
58s{color} | {color:red} The patch causes 10 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m
1s{color} | {color:red} The patch causes 10 errors with Hadoop v3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}105m
43s{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}132m 27s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20054 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12911611/20054.v1.txt |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 056938704dfb 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/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / d68f697f39 |
| maven |
[jira] [Commented] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373657#comment-16373657
]
Hadoop QA commented on HBASE-20001:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1.4 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
30s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
29s{color} | {color:green} branch-1.4 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} branch-1.4 passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} branch-1.4 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} 1m
56s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
22s{color} | {color:green} branch-1.4 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} branch-1.4 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
30s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
10s{color} | {color:red} hbase-server: The patch generated 1 new + 350
unchanged - 11 fixed = 351 total (was 361) {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} 2m
10s{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 26s{color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.5 2.7.4. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
15s{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
23s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
38s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}131m 26s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | org.apache.hadoop.hbase.master.AssignmentManager.TEST_SKIP_MERGE_HANDLING
isn't final but should be At AssignmentManager.java:be At
AssignmentManager.java:[line 262] |
\\
\\
|| Subsystem || Report/Notes ||
| Docker |
[jira] [Commented] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373631#comment-16373631
]
Ted Yu commented on HBASE-20001:
I looked at the patch which looks good.
> cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
> -
>
> Key: HBASE-20001
> URL: https://issues.apache.org/jira/browse/HBASE-20001
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.1.7
>Reporter: Francis Liu
>Assignee: Thiruvel Thirumoolan
>Priority: Major
> Fix For: 1.3.2, 1.5.0, 1.2.7, 1.4.3
>
> Attachments: HBASE-20001.branch-1.4.001.patch,
> HBASE-20001.branch-1.4.002.patch, HBASE-20001.branch-1.4.003.patch
>
>
> In RegionStates.cleanIfNoMetaEntry()
> {{if (MetaTableAccessor.getRegion(server.getConnection(),
> hri.getEncodedNameAsBytes()) == null) {}}
> {{regionOffline(hri);}}
> {{FSUtils.deleteRegionDir(server.getConfiguration(), hri);}}
> }
> But api expects regionname
> {{public static Pair getRegion(Connection
> connection, byte [] regionName)}}
> So we might end up cleaning good regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373621#comment-16373621
]
Thiruvel Thirumoolan commented on HBASE-20001:
--
Uploaded HBASE-20001.branch-1.4.003.patch to address the issues we ([~toffer]
and I) found. This addresses two issues:
# regionName fix which caused the data loss issue for us.
# ZK split/merge rollback on failure and unit tests.
testRSSplitEphemeralsDisappearButDaughtersAreOnlinedAfterShutdownHandling -
This test failed and caused subsequent tests to fail. It was failing in
deletion of the test table (finally clause) because the daughters were in
transition (SPLITTING_NEW) due to regionName fix. Without the regionName fix,
the daughters were offlined and HDFS dir removed and the test passed, which is
wrong.
[~toffer] pointed out that the test was waiting for daughters to be online, but
in zk based assignment, we rollback and not forward. So, we should be waiting
for parent. The test was still passing all these checks because there were not
enough barriers. So we fixed the test to comply with the zk based behavior. We
also introduced a similar test for merge in zk mode. I will raise separate Jira
for re-introducing zkless based tests back and will add the appropriate zkless
tests in follow up.
Once we fixed the test, we realized the failed daughters were in transition and
not offlined. We fixed that also in RegionStates.java as part of this Jira
itself.
Please let us know what do you guys think. Thanks!
> cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
> -
>
> Key: HBASE-20001
> URL: https://issues.apache.org/jira/browse/HBASE-20001
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.1.7
>Reporter: Francis Liu
>Assignee: Thiruvel Thirumoolan
>Priority: Major
> Fix For: 1.3.2, 1.5.0, 1.2.7, 1.4.3
>
> Attachments: HBASE-20001.branch-1.4.001.patch,
> HBASE-20001.branch-1.4.002.patch, HBASE-20001.branch-1.4.003.patch
>
>
> In RegionStates.cleanIfNoMetaEntry()
> {{if (MetaTableAccessor.getRegion(server.getConnection(),
> hri.getEncodedNameAsBytes()) == null) {}}
> {{regionOffline(hri);}}
> {{FSUtils.deleteRegionDir(server.getConfiguration(), hri);}}
> }
> But api expects regionname
> {{public static Pair getRegion(Connection
> connection, byte [] regionName)}}
> So we might end up cleaning good regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19402) Add missing security check for RegionServerStatusService RPCs
[ https://issues.apache.org/jira/browse/HBASE-19402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373606#comment-16373606 ] Appy commented on HBASE-19402: -- We can't limit it to any particular username. It's not right to assume that all users will be able to run hbase with 'hbase' user. Also, we need to define perms as a function of [access level and scope|http://hbase.apache.org/book.html#_understanding_access_levels]. So should be at minimum, global + admin? > Add missing security check for RegionServerStatusService RPCs > - > > Key: HBASE-19402 > URL: https://issues.apache.org/jira/browse/HBASE-19402 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Priority: Major > > The following RPC methods do not call the observers, therefore they are not > guarded by AccessController: > - regionServerStartup > - regionServerReport > - reportRSFatalError > - reportRegionStateTransition > - reportRegionSpaceUse -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19989) READY_TO_MERGE and READY_TO_SPLIT do not update region state correctly
[ https://issues.apache.org/jira/browse/HBASE-19989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373599#comment-16373599 ] Ben Lau commented on HBASE-19989: - I don't think those 4 tests are related to this patch. Also ran them locally just now against the current version of branch-1 (cadc2efd1207d7d505c9fadaeca9338d21018f08) and all 4 tests pass fine with the patch. Probably flaky tests. > READY_TO_MERGE and READY_TO_SPLIT do not update region state correctly > -- > > Key: HBASE-19989 > URL: https://issues.apache.org/jira/browse/HBASE-19989 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.4.1 >Reporter: Ben Lau >Assignee: Ben Lau >Priority: Major > Attachments: HBASE-19989-branch-1.patch > > > Region state transitions do not work correctly for READY_TO_MERGE/SPLIT. > [~thiruvel] and I noticed this is due to break statements being in the wrong > place in AssignmentManager. This allows a race condition for example in > which one of the regions being merged could be moved concurrently, resulting > in the merge transaction failing and then double assignment and/or dataloss. > This bug appears to only affect branch-1 (for example 1.3 and 1.4) and not > branch-2 as the relevant code in AM has since been rewritten. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19403) Add missing security checks for AdminService RPCs
[ https://issues.apache.org/jira/browse/HBASE-19403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373590#comment-16373590 ] stack commented on HBASE-19403: --- If it just ADMIN then one cluster will blocked replicating to another? Other methods requiring ADMIN seem fine. > Add missing security checks for AdminService RPCs > - > > Key: HBASE-19403 > URL: https://issues.apache.org/jira/browse/HBASE-19403 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Assignee: Appy >Priority: Major > > The following RPC methods do not call the observers, therefore they are not > guarded by AccessController: > - updateConfiguration > - replay > - warmupRegion > - updateFavoredNodes > - clearRegionBlockCache -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19402) Add missing security check for RegionServerStatusService RPCs
[ https://issues.apache.org/jira/browse/HBASE-19402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373586#comment-16373586 ] stack commented on HBASE-19402: --- Is he saying that [~appy]? I think he's saying that it should be hbase user, not ADMIN? > Add missing security check for RegionServerStatusService RPCs > - > > Key: HBASE-19402 > URL: https://issues.apache.org/jira/browse/HBASE-19402 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Priority: Major > > The following RPC methods do not call the observers, therefore they are not > guarded by AccessController: > - regionServerStartup > - regionServerReport > - reportRSFatalError > - reportRegionStateTransition > - reportRegionSpaceUse -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19364) Truncate_preserve fails with table when replica region > 1
[ https://issues.apache.org/jira/browse/HBASE-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373570#comment-16373570 ] Ted Yu commented on HBASE-19364: I ran TestFailedProcCleanup with patch which passed. TestCatalogJanitorInMemoryStates and TestRegionOpen are tracked by their own JIRAs. > Truncate_preserve fails with table when replica region > 1 > -- > > Key: HBASE-19364 > URL: https://issues.apache.org/jira/browse/HBASE-19364 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-19364-branch-1-v2.patch, > HBASE-19364-branch-1.patch, HBASE-19364-branch-1.patch > > > Root cause is same as HBASE-17319, here we need to exclude secondary regions > while reading meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19401) Add missing security checks in RSRpcServices
[ https://issues.apache.org/jira/browse/HBASE-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373569#comment-16373569 ] stack commented on HBASE-19401: --- +1 > Add missing security checks in RSRpcServices > > > Key: HBASE-19401 > URL: https://issues.apache.org/jira/browse/HBASE-19401 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-1 >Reporter: Balazs Meszaros >Assignee: Appy >Priority: Major > Attachments: HBASE-19401.master.001.patch, > HBASE-19401.master.002.patch > > > The following RPC methods in RSRpcServices do not have ACL check for ADMIN > rights. > - execRegionServerService -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20024) TestMergeTableRegionsProcedure is STILL flakey
[ https://issues.apache.org/jira/browse/HBASE-20024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373560#comment-16373560 ] Umesh Agashe commented on HBASE-20024: -- [~stack], I think I know what may be the problem here. Mind if I take this one? > TestMergeTableRegionsProcedure is STILL flakey > -- > > Key: HBASE-20024 > URL: https://issues.apache.org/jira/browse/HBASE-20024 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Attachments: HBASE-20024.branch-2.001.patch > > > This is a follow-on from HBASE-20015. Root issue is that merge does not > support rollback once it has hit the point-of-no-return; it can only > roll-forward at this point. > HBASE-18018 added abort to all procedures. HBASE-18016 added ignoring abort > to the truncate procedure to get around flakeyness. HBASE-20022 is a new > issue to figure what to do w/ unabortable procedures. > Meantime, merge and split have PONR and the procedure executor test harness > does abort regardless making these tests flakies. Adding an ignore of the > abort once into the PONR makes sense (Always? HBASE-20022 is for those as yet > unknown cases where it does not). Let me ignore to merge and split in this > issue to address flakeyness. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-20024) TestMergeTableRegionsProcedure is STILL flakey
[ https://issues.apache.org/jira/browse/HBASE-20024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe reassigned HBASE-20024: Assignee: Umesh Agashe (was: stack) > TestMergeTableRegionsProcedure is STILL flakey > -- > > Key: HBASE-20024 > URL: https://issues.apache.org/jira/browse/HBASE-20024 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Attachments: HBASE-20024.branch-2.001.patch > > > This is a follow-on from HBASE-20015. Root issue is that merge does not > support rollback once it has hit the point-of-no-return; it can only > roll-forward at this point. > HBASE-18018 added abort to all procedures. HBASE-18016 added ignoring abort > to the truncate procedure to get around flakeyness. HBASE-20022 is a new > issue to figure what to do w/ unabortable procedures. > Meantime, merge and split have PONR and the procedure executor test harness > does abort regardless making these tests flakies. Adding an ignore of the > abort once into the PONR makes sense (Always? HBASE-20022 is for those as yet > unknown cases where it does not). Let me ignore to merge and split in this > issue to address flakeyness. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19364) Truncate_preserve fails with table when replica region > 1
[ https://issues.apache.org/jira/browse/HBASE-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373556#comment-16373556 ] huaxiang sun commented on HBASE-19364: -- Thanks [~tedyu]. Running the failed tested cases locally passed for me. TestCatalogJanitorInMemoryStates,TestSerialReplication,TestFailedProcCleanup,TestRegionOpen > Truncate_preserve fails with table when replica region > 1 > -- > > Key: HBASE-19364 > URL: https://issues.apache.org/jira/browse/HBASE-19364 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-19364-branch-1-v2.patch, > HBASE-19364-branch-1.patch, HBASE-19364-branch-1.patch > > > Root cause is same as HBASE-17319, here we need to exclude secondary regions > while reading meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18133) Low-latency space quota size reports
[
https://issues.apache.org/jira/browse/HBASE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373500#comment-16373500
]
Hadoop QA commented on HBASE-18133:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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 12 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
5s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
58s{color} | {color:green} master 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} 4m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
24s{color} | {color:red} hbase-server: The patch generated 1 new + 580
unchanged - 3 fixed = 581 total (was 583) {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} 5m
16s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 31s{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} javadoc {color} | {color:green} 1m
3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
27s{color} | {color:green} hbase-hadoop-compat in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
32s{color} | {color:green} hbase-hadoop2-compat in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 21m 9s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 67m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.filter.TestDependentColumnFilter |
| | hadoop.hbase.coprocessor.TestCoprocessorInterface |
| | hadoop.hbase.regionserver.TestWALMonotonicallyIncreasingSeqId |
| | hadoop.hbase.coprocessor.TestRegionObserverStacking |
| | hadoop.hbase.filter.TestFilter |
| | hadoop.hbase.filter.TestInvocationRecordFilter |
| | hadoop.hbase.io.encoding.TestSeekBeforeWithReverseScan |
| | hadoop.hbase.regionserver.TestWideScanner |
| | hadoop.hbase.filter.TestColumnPrefixFilter |
| | hadoop.hbase.regionserver.TestKeepDeletes |
| | hadoop.hbase.regionserver.TestMinVersions |
| | hadoop.hbase.regionserver.TestScanWithBloomError |
| |
[jira] [Commented] (HBASE-19364) Truncate_preserve fails with table when replica region > 1
[
https://issues.apache.org/jira/browse/HBASE-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373498#comment-16373498
]
Ted Yu commented on HBASE-19364:
lgtm
nit:
{code}
+ * @return Return list of regioninfos and server addresses.
+ */
+ public static List>
getTableRegionsAndLocations(
{code}
The 'Return' in javadoc is not needed.
> Truncate_preserve fails with table when replica region > 1
> --
>
> Key: HBASE-19364
> URL: https://issues.apache.org/jira/browse/HBASE-19364
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Pankaj Kumar
>Assignee: Pankaj Kumar
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-19364-branch-1-v2.patch,
> HBASE-19364-branch-1.patch, HBASE-19364-branch-1.patch
>
>
> Root cause is same as HBASE-17319, here we need to exclude secondary regions
> while reading meta.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19364) Truncate_preserve fails with table when replica region > 1
[ https://issues.apache.org/jira/browse/HBASE-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373457#comment-16373457 ] huaxiang sun commented on HBASE-19364: -- attach v2 to address checkStyle warnings. > Truncate_preserve fails with table when replica region > 1 > -- > > Key: HBASE-19364 > URL: https://issues.apache.org/jira/browse/HBASE-19364 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-19364-branch-1-v2.patch, > HBASE-19364-branch-1.patch, HBASE-19364-branch-1.patch > > > Root cause is same as HBASE-17319, here we need to exclude secondary regions > while reading meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19364) Truncate_preserve fails with table when replica region > 1
[ https://issues.apache.org/jira/browse/HBASE-19364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-19364: - Attachment: HBASE-19364-branch-1-v2.patch > Truncate_preserve fails with table when replica region > 1 > -- > > Key: HBASE-19364 > URL: https://issues.apache.org/jira/browse/HBASE-19364 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-19364-branch-1-v2.patch, > HBASE-19364-branch-1.patch, HBASE-19364-branch-1.patch > > > Root cause is same as HBASE-17319, here we need to exclude secondary regions > while reading meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17449) Add explicit document on different timeout settings
[ https://issues.apache.org/jira/browse/HBASE-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373443#comment-16373443 ] stack commented on HBASE-17449: --- There there is HBASE-16291. It gets subsumed by this? > Add explicit document on different timeout settings > --- > > Key: HBASE-17449 > URL: https://issues.apache.org/jira/browse/HBASE-17449 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Yu Li >Assignee: Yu Li >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: 0001-Standalone.patch, WIP-HBASE-17499.master.001.patch > > > Currently we have more than one timeout settings, mainly includes: > * hbase.rpc.timeout > * hbase.client.operation.timeout > * hbase.client.scanner.timeout.period > And in latest branch-1 or master branch code, we will have two other > properties: > * hbase.rpc.read.timeout > * hbase.rpc.write.timeout > However, in current refguid we don't have explicit instruction on the > difference of these timeout settings (there're explanations for each > property, but no instruction on when to use which) > In my understanding, for RPC layer timeout, or say each rpc call: > * Scan (openScanner/next): controlled by hbase.client.scanner.timeout.period > * Other operations: >1. For released versions: controlled by hbase.rpc.timeout >2. For 1.4+ versions: read operation controlled by hbase.rpc.read.timeout, > write operation controlled by hbase.rpc.write.timeout, or hbase.rpc.timeout > if the previous two are not set. > And hbase.client.operation.timeout is a higher-level control counting retry > in, or say the overall control for one user call. > After this JIRA, I hope when users ask questions like "What settings I should > use if I don't want to wait for more than 1 second for a single > put/get/scan.next call", we could give a neat answer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-17449) Add explicit document on different timeout settings
[ https://issues.apache.org/jira/browse/HBASE-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373433#comment-16373433 ] stack edited comment on HBASE-17449 at 2/22/18 9:00 PM: It is noted above by Duo. Was hoping we'd have a rationalization of it all at the end of this issue. What you think [~psomogyi]? If you search [~yangzhe1991] issues, he was in here and dig a bunch of fixes. I linked them here. In one IIRC, he talked about how operation timeout shouldn't cover scans... Trying to find it. Meantime let me link relevant seeming issues. HBASE-16492 is the umbrella issue. was (Author: stack): It is noted above by Duo. Was hoping we'd have a rationalization of it all at the end of this issue. What you think [~psomogyi]? If you search [~yangzhe1991] issues, he was in here and dig a bunch of fixes. I linked them here. In one IIRC, he talked about how operation timeout shouldn't cover scans... Trying to find it. Meantime let me link relevant seeming issues. > Add explicit document on different timeout settings > --- > > Key: HBASE-17449 > URL: https://issues.apache.org/jira/browse/HBASE-17449 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Yu Li >Assignee: Yu Li >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: 0001-Standalone.patch, WIP-HBASE-17499.master.001.patch > > > Currently we have more than one timeout settings, mainly includes: > * hbase.rpc.timeout > * hbase.client.operation.timeout > * hbase.client.scanner.timeout.period > And in latest branch-1 or master branch code, we will have two other > properties: > * hbase.rpc.read.timeout > * hbase.rpc.write.timeout > However, in current refguid we don't have explicit instruction on the > difference of these timeout settings (there're explanations for each > property, but no instruction on when to use which) > In my understanding, for RPC layer timeout, or say each rpc call: > * Scan (openScanner/next): controlled by hbase.client.scanner.timeout.period > * Other operations: >1. For released versions: controlled by hbase.rpc.timeout >2. For 1.4+ versions: read operation controlled by hbase.rpc.read.timeout, > write operation controlled by hbase.rpc.write.timeout, or hbase.rpc.timeout > if the previous two are not set. > And hbase.client.operation.timeout is a higher-level control counting retry > in, or say the overall control for one user call. > After this JIRA, I hope when users ask questions like "What settings I should > use if I don't want to wait for more than 1 second for a single > put/get/scan.next call", we could give a neat answer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17449) Add explicit document on different timeout settings
[ https://issues.apache.org/jira/browse/HBASE-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373433#comment-16373433 ] stack commented on HBASE-17449: --- It is noted above by Duo. Was hoping we'd have a rationalization of it all at the end of this issue. What you think [~psomogyi]? If you search [~yangzhe1991] issues, he was in here and dig a bunch of fixes. I linked them here. In one IIRC, he talked about how operation timeout shouldn't cover scans... Trying to find it. Meantime let me link relevant seeming issues. > Add explicit document on different timeout settings > --- > > Key: HBASE-17449 > URL: https://issues.apache.org/jira/browse/HBASE-17449 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Yu Li >Assignee: Yu Li >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: 0001-Standalone.patch, WIP-HBASE-17499.master.001.patch > > > Currently we have more than one timeout settings, mainly includes: > * hbase.rpc.timeout > * hbase.client.operation.timeout > * hbase.client.scanner.timeout.period > And in latest branch-1 or master branch code, we will have two other > properties: > * hbase.rpc.read.timeout > * hbase.rpc.write.timeout > However, in current refguid we don't have explicit instruction on the > difference of these timeout settings (there're explanations for each > property, but no instruction on when to use which) > In my understanding, for RPC layer timeout, or say each rpc call: > * Scan (openScanner/next): controlled by hbase.client.scanner.timeout.period > * Other operations: >1. For released versions: controlled by hbase.rpc.timeout >2. For 1.4+ versions: read operation controlled by hbase.rpc.read.timeout, > write operation controlled by hbase.rpc.write.timeout, or hbase.rpc.timeout > if the previous two are not set. > And hbase.client.operation.timeout is a higher-level control counting retry > in, or say the overall control for one user call. > After this JIRA, I hope when users ask questions like "What settings I should > use if I don't want to wait for more than 1 second for a single > put/get/scan.next call", we could give a neat answer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20054) Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet replicated in case of KeeperException
[ https://issues.apache.org/jira/browse/HBASE-20054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20054: --- Status: Patch Available (was: Open) > Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet > replicated in case of KeeperException > > > Key: HBASE-20054 > URL: https://issues.apache.org/jira/browse/HBASE-20054 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Major > Fix For: 3.0.0 > > Attachments: 20054.v1.txt > > > Some changes from HBASE-18282 were missing in master branch: > * The retry in ReplicationSourceManager#adoptAbandonedQueues > * new tests in TestLogsCleaner > This issue is to forward port the above to master branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20054) Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet replicated in case of KeeperException
[ https://issues.apache.org/jira/browse/HBASE-20054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373430#comment-16373430 ] Ted Yu commented on HBASE-20054: [~benlau]: Mind taking a look ? > Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet > replicated in case of KeeperException > > > Key: HBASE-20054 > URL: https://issues.apache.org/jira/browse/HBASE-20054 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Major > Fix For: 3.0.0 > > Attachments: 20054.v1.txt > > > Some changes from HBASE-18282 were missing in master branch: > * The retry in ReplicationSourceManager#adoptAbandonedQueues > * new tests in TestLogsCleaner > This issue is to forward port the above to master branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20054) Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet replicated in case of KeeperException
[ https://issues.apache.org/jira/browse/HBASE-20054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20054: --- Attachment: 20054.v1.txt > Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet > replicated in case of KeeperException > > > Key: HBASE-20054 > URL: https://issues.apache.org/jira/browse/HBASE-20054 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Major > Fix For: 3.0.0 > > Attachments: 20054.v1.txt > > > Some changes from HBASE-18282 were missing in master branch: > * The retry in ReplicationSourceManager#adoptAbandonedQueues > * new tests in TestLogsCleaner > This issue is to forward port the above to master branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20054) Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet replicated in case of KeeperException
Ted Yu created HBASE-20054: -- Summary: Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet replicated in case of KeeperException Key: HBASE-20054 URL: https://issues.apache.org/jira/browse/HBASE-20054 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu Fix For: 3.0.0 Attachments: 20054.v1.txt Some changes from HBASE-18282 were missing in master branch: * The retry in ReplicationSourceManager#adoptAbandonedQueues * new tests in TestLogsCleaner This issue is to forward port the above to master branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20001) cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
[
https://issues.apache.org/jira/browse/HBASE-20001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvel Thirumoolan updated HBASE-20001:
-
Attachment: HBASE-20001.branch-1.4.003.patch
> cleanIfNoMetaEntry() uses encoded instead of region name to lookup region
> -
>
> Key: HBASE-20001
> URL: https://issues.apache.org/jira/browse/HBASE-20001
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.1.7
>Reporter: Francis Liu
>Assignee: Thiruvel Thirumoolan
>Priority: Major
> Fix For: 1.3.2, 1.5.0, 1.2.7, 1.4.3
>
> Attachments: HBASE-20001.branch-1.4.001.patch,
> HBASE-20001.branch-1.4.002.patch, HBASE-20001.branch-1.4.003.patch
>
>
> In RegionStates.cleanIfNoMetaEntry()
> {{if (MetaTableAccessor.getRegion(server.getConnection(),
> hri.getEncodedNameAsBytes()) == null) {}}
> {{regionOffline(hri);}}
> {{FSUtils.deleteRegionDir(server.getConfiguration(), hri);}}
> }
> But api expects regionname
> {{public static Pair getRegion(Connection
> connection, byte [] regionName)}}
> So we might end up cleaning good regions.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20003) WALLess HBase on Persistent Memory
[ https://issues.apache.org/jira/browse/HBASE-20003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373420#comment-16373420 ] Andrew Purtell commented on HBASE-20003: Can't assume in a failure the primary (or even any replica at all) will survive. > WALLess HBase on Persistent Memory > -- > > Key: HBASE-20003 > URL: https://issues.apache.org/jira/browse/HBASE-20003 > Project: HBase > Issue Type: New Feature >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Major > > This JIRA aims to make use of persistent memory (pmem) technologies in HBase. > One such usage is to make the Memstore to reside on pmem. Making a persistent > memstore would remove the need for WAL and paves way for a WALLess HBase. > The existing region replica feature could be used here and ensure the data > written to memstores are synchronously replicated to the replicas and ensure > strong consistency of the data. (pipeline model) > Advantages : > - Data Availability : Since the data across replicas are consistent > (synchronously written) our data is always 100 % available. > - Lower MTTR : It becomes easier/faster to switch over to the replicas on a > primary region failure as there is no WAL replay involved. Building the > memstore map data also is much faster than reading the WAL and replaying the > WAL. > - Possibility of bigger memstores : These pmems are designed to have more > memory than DRAMs so it would also enable us to have bigger sized memstores > which leads to lesser flushes/compaction IO. > - Removes the dependency of HDFS on the write path > Initial PoC has been designed and developed. Testing is underway and we would > publish the PoC results along with the design doc sooner. The PoC doc will > talk about the design decisions, the libraries considered to work with these > pmem devices, pros and cons of those libraries and the performance results. > Note : Next gen memory technologies using 3DXPoint gives persistent memory > feature. Such memory DIMMs are soon to appear in the market. The PoC is done > around Intel's ApachePass (AEP) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20052) TestRegionOpen#testNonExistentRegionReplica fails due to NPE
[
https://issues.apache.org/jira/browse/HBASE-20052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-20052:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0-beta-2
1.5.0
Status: Resolved (was: Patch Available)
Thanks for the review, Huaxiang.
> TestRegionOpen#testNonExistentRegionReplica fails due to NPE
>
>
> Key: HBASE-20052
> URL: https://issues.apache.org/jira/browse/HBASE-20052
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Fix For: 1.5.0, 2.0.0-beta-2
>
> Attachments: 20052.v1.txt, 20052.v2.txt
>
>
> After HBASE-19391 was integrated, the following test failure can be observed:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.TestRegionOpen.testNonExistentRegionReplica(TestRegionOpen.java:122)
> {code}
> This was due null being returned from
> HRegionFileSystem#createRegionOnFileSystem().
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20041) cannot start mini mapreduce cluster for ITs
[ https://issues.apache.org/jira/browse/HBASE-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373404#comment-16373404 ] Hudson commented on HBASE-20041: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4631 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4631/]) HBASE-20041 move jersey-1 exclusions to hbase-rest (mdrob: rev aef60a11b5a2deac19216ff396ba31c5df0c70d0) * (edit) pom.xml * (edit) hbase-rest/pom.xml > cannot start mini mapreduce cluster for ITs > --- > > Key: HBASE-20041 > URL: https://issues.apache.org/jira/browse/HBASE-20041 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-20041.patch > > > We killed a lot of the jersey yarn dependencies, so now we can't start the > hadoop3 mini MR cluster. This make ITs sad. > Need to fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19391) Calling HRegion#initializeRegionInternals from a region replica can still re-create a region directory
[ https://issues.apache.org/jira/browse/HBASE-19391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373405#comment-16373405 ] Hudson commented on HBASE-19391: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4631 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4631/]) HBASE-19391 Calling HRegion#initializeRegionInternals from a region (stack: rev 11af33af2a5baeecac7fb1773d5a1c27291f68dc) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionOpen.java > Calling HRegion#initializeRegionInternals from a region replica can still > re-create a region directory > -- > > Key: HBASE-19391 > URL: https://issues.apache.org/jira/browse/HBASE-19391 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-4, 1.4.2 >Reporter: Esteban Gutierrez >Assignee: Esteban Gutierrez >Priority: Major > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: > 0001-HBASE-19391-Calling-HRegion-initializeRegionInternal.patch, > HBASE-19391.master.v0.patch > > > This is a follow up from HBASE-18024. There stills a chance that attempting > to open a region that is not the default region replica can still create a > GC'd region directory by the CatalogJanitor causing inconsistencies with hbck. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20035) .TestQuotaStatusRPCs.testQuotaStatusFromMaster failed with NPEs and RuntimeExceptions
[
https://issues.apache.org/jira/browse/HBASE-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373403#comment-16373403
]
Hudson commented on HBASE-20035:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4631 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4631/])
HBASE-20035 Stabilize the flaky TestQuotaStatusRPCs (elserj: rev
4cf846d08570256115ac8c2787d0f7fbf162be23)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/quotas/TestQuotaStatusRPCs.java
> .TestQuotaStatusRPCs.testQuotaStatusFromMaster failed with NPEs and
> RuntimeExceptions
> -
>
> Key: HBASE-20035
> URL: https://issues.apache.org/jira/browse/HBASE-20035
> Project: HBase
> Issue Type: Sub-task
>Reporter: stack
>Assignee: Josh Elser
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-20035.001.branch-2.patch
>
>
> It failed the nightly.
> Says this...
> Error Message
> Waiting timed out after [30,000] msec
> Stacktrace
> java.lang.AssertionError: Waiting timed out after [30,000] msec
> at
> org.apache.hadoop.hbase.quotas.TestQuotaStatusRPCs.testQuotaStatusFromMaster(TestQuotaStatusRPCs.java:267)
> ... but looking in log I see following:
> Odd thing is the test is run three times and it failed all three times for
> same reason.
> [ERROR] Failures:
> [ERROR]
> org.apache.hadoop.hbase.quotas.TestQuotaStatusRPCs.testQuotaStatusFromMaster(org.apache.hadoop.hbase.quotas.TestQuotaStatusRPCs)
> [ERROR] Run 1: TestQuotaStatusRPCs.testQuotaStatusFromMaster:267 Waiting
> timed out after [30,000] msec
> [ERROR] Run 2: TestQuotaStatusRPCs.testQuotaStatusFromMaster:267 Waiting
> timed out after [30,000] msec
> [ERROR] Run 3: TestQuotaStatusRPCs.testQuotaStatusFromMaster:267 Waiting
> timed out after [30,000] msec
> If you go to build artifacts you can download full -output.txt log. I see
> stuff like this which might be ok
> {code}
> 2018-02-21 01:29:59,546 INFO
> [StoreCloserThread-testQuotaStatusFromMaster4,0,1519176558800.1dbd00f38915cd276410065f85140b26.-1]
> regionserver.HStore(930): Closed f1
> 2018-02-21 01:29:59,551 ERROR [master/ad51e354307e:0.Chore.2]
> hbase.ScheduledChore(189): Caught error
> java.lang.RuntimeException: java.util.concurrent.RejectedExecutionException:
> Task
> org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture@79ec2ef9
> rejected from java.util.concurrent.ThreadPoolExecutor@5198a326[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 142]
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithoutRetries(RpcRetryingCallerImpl.java:200)
> at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:269)
> at
> org.apache.hadoop.hbase.client.ClientScanner.loadCache(ClientScanner.java:437)
> at
> org.apache.hadoop.hbase.client.ClientScanner.nextWithSyncCache(ClientScanner.java:312)
> at org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:597)
> at
> org.apache.hadoop.hbase.quotas.QuotaRetriever.next(QuotaRetriever.java:106)
> at
> org.apache.hadoop.hbase.quotas.QuotaRetriever$Iter.(QuotaRetriever.java:125)
> at
> org.apache.hadoop.hbase.quotas.QuotaRetriever.iterator(QuotaRetriever.java:117)
> at
> org.apache.hadoop.hbase.quotas.QuotaObserverChore.fetchAllTablesWithQuotasDefined(QuotaObserverChore.java:458)
> at
> org.apache.hadoop.hbase.quotas.QuotaObserverChore._chore(QuotaObserverChore.java:148)
> at
> org.apache.hadoop.hbase.quotas.QuotaObserverChore.chore(QuotaObserverChore.java:136)
> at org.apache.hadoop.hbase.ScheduledChore.run(ScheduledChore.java:186)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> org.apache.hadoop.hbase.JitterScheduledThreadPoolExecutorImpl$JitteredRunnableScheduledFuture.run(JitterScheduledThreadPoolExecutorImpl.java:111)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.concurrent.RejectedExecutionException: Task
> org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture@79ec2ef9
> rejected from java.util.concurrent.ThreadPoolExecutor@5198a326[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 142]
> at
>
[jira] [Commented] (HBASE-18133) Low-latency space quota size reports
[ https://issues.apache.org/jira/browse/HBASE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373382#comment-16373382 ] Josh Elser commented on HBASE-18133: .004 fixes the checkstyle and test failures (Eclipse apparently failed at this). I think the other UT failures are related to another bug that affected many tests. > Low-latency space quota size reports > > > Key: HBASE-18133 > URL: https://issues.apache.org/jira/browse/HBASE-18133 > Project: HBase > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-18133.001.patch, HBASE-18133.002.patch, > HBASE-18133.003.patch, HBASE-18133.004.patch > > > Presently space quota enforcement relies on RegionServers sending reports to > the master about each Region that they host. This is done by periodically, > reading the cached size of each HFile in each Region (which was ultimately > computed from HDFS). > This means that the Master is unaware of Region size growth until the the > next time this chore in a RegionServer fires which is a fair amount of > latency (a few minutes, by default). Operations like flushes, compactions, > and bulk-loads are delayed even though the RegionServer is running those > operations locally. > Instead, we can create an API which these operations could invoke that would > automatically update the size of the Region being operated on. For example, a > successful flush can report that the size of a Region increased by the size > of the flush. A compaction can subtract the size of the input files of the > compaction and add in the size of the resulting file. > This de-couples the computation of a Region's size from sending the Region > sizes to the Master, allowing us to send reports more frequently, increasing > the responsiveness of the cluster to size changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-18133) Low-latency space quota size reports
[ https://issues.apache.org/jira/browse/HBASE-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18133: --- Attachment: HBASE-18133.004.patch > Low-latency space quota size reports > > > Key: HBASE-18133 > URL: https://issues.apache.org/jira/browse/HBASE-18133 > Project: HBase > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-18133.001.patch, HBASE-18133.002.patch, > HBASE-18133.003.patch, HBASE-18133.004.patch > > > Presently space quota enforcement relies on RegionServers sending reports to > the master about each Region that they host. This is done by periodically, > reading the cached size of each HFile in each Region (which was ultimately > computed from HDFS). > This means that the Master is unaware of Region size growth until the the > next time this chore in a RegionServer fires which is a fair amount of > latency (a few minutes, by default). Operations like flushes, compactions, > and bulk-loads are delayed even though the RegionServer is running those > operations locally. > Instead, we can create an API which these operations could invoke that would > automatically update the size of the Region being operated on. For example, a > successful flush can report that the size of a Region increased by the size > of the flush. A compaction can subtract the size of the input files of the > compaction and add in the size of the resulting file. > This de-couples the computation of a Region's size from sending the Region > sizes to the Master, allowing us to send reports more frequently, increasing > the responsiveness of the cluster to size changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20052) TestRegionOpen#testNonExistentRegionReplica fails due to NPE
[
https://issues.apache.org/jira/browse/HBASE-20052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373340#comment-16373340
]
Hadoop QA commented on HBASE-20052:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{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:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
58s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
17s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m
15s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m
12s{color} | {color:red} The patch causes 10 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m
17s{color} | {color:red} The patch causes 10 errors with Hadoop v3.0.0. {color}
|
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}105m
42s{color} | {color:green} hbase-server in the patch passed. {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}132m 39s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20052 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12911584/20052.v2.txt |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 76b57d0163db 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/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 11af33af2a |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test
[jira] [Commented] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master
[
https://issues.apache.org/jira/browse/HBASE-20049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373284#comment-16373284
]
Hadoop QA commented on HBASE-20049:
---
| (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:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
11s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
36s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
23s{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} 5m
5s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 36s{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} hbaseprotoc {color} | {color:green}
1m 4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
34s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
15s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}153m 6s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20049 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12911573/HBASE-20049.master.002.patch
|
| Optional Tests | asflicense cc unit hbaseprotoc javac javadoc findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux cb7bbb36cf80 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
|
[jira] [Created] (HBASE-20053) Remove .cmake file extension from .gitignore
Ted Yu created HBASE-20053: -- Summary: Remove .cmake file extension from .gitignore Key: HBASE-20053 URL: https://issues.apache.org/jira/browse/HBASE-20053 Project: HBase Issue Type: Sub-task Reporter: Ted Yu There are .cmake files under hbase-native-client/cmake/ which are under source control. The .cmake extension should be taken out of hbase-native-client/.gitignore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20052) TestRegionOpen#testNonExistentRegionReplica fails due to NPE
[
https://issues.apache.org/jira/browse/HBASE-20052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373240#comment-16373240
]
huaxiang sun commented on HBASE-20052:
--
+1, if the primary region does not exist , the replica region will be a
non-existing replica region and it wont create fs layout for the primary region.
> TestRegionOpen#testNonExistentRegionReplica fails due to NPE
>
>
> Key: HBASE-20052
> URL: https://issues.apache.org/jira/browse/HBASE-20052
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20052.v1.txt, 20052.v2.txt
>
>
> After HBASE-19391 was integrated, the following test failure can be observed:
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.TestRegionOpen.testNonExistentRegionReplica(TestRegionOpen.java:122)
> {code}
> This was due null being returned from
> HRegionFileSystem#createRegionOnFileSystem().
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20051) Correct usage statement of endtime for VerifyReplication
[
https://issues.apache.org/jira/browse/HBASE-20051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373234#comment-16373234
]
Sean Busbey commented on HBASE-20051:
-
> -1test4tests
We don't have tests for CLI help messages, AFAICT. Would like to ignore this
one.
> -1unit88m 54s hbase-server in the patch failed.
> Failed junit testshadoop.hbase.regionserver.TestEndToEndSplitTransaction
> hadoop.hbase.util.TestHBaseFsck
I don't see how either of these could be failing due to my change and reading
the test output doesn't seem to point at VerifyReplication at all.
Unfortunately we don't have a flakey dashboard for maintenance branches, but I
see TestEndToEndSplitTransaction failed in nightly for branch-1.3 last night.
Fine with going forward still [~elserj]?
> Correct usage statement of endtime for VerifyReplication
>
>
> Key: HBASE-20051
> URL: https://issues.apache.org/jira/browse/HBASE-20051
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.2.0, 1.3.0, 1.2.1, 1.2.2, 1.3.1, 1.2.3, 1.2.4, 1.2.5,
> 1.2.6
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Trivial
> Fix For: 1.3.2, 1.2.7
>
> Attachments: HBASE-20051-branch-1.3.v0.patch
>
>
> VerifyReplication's usage claims that {{\-\-stoptime}} will give end of time
> range, but then parses {{\-\-endtime}}.
> Not an issue on branches that already have HBASE-16772, because it fixed the
> usage as a side effect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-20042) TestRegionServerAbort flakey
[ https://issues.apache.org/jira/browse/HBASE-20042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-20042. --- Resolution: Fixed Assignee: stack Resolving. No longer on flakies list. > TestRegionServerAbort flakey > > > Key: HBASE-20042 > URL: https://issues.apache.org/jira/browse/HBASE-20042 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Attachments: > 0001-HBASE-20042-TestRegionServerAbort-flakey-ADDENDUM-RE.patch, > HBASE-20042.branch-2.001.patch > > > Failed with a hang and an index out of bounds in last 30 runs. The timeout > has no logs. The indexoutofbounds seems basic... Looking at logs all seems to > be working... eventually... as it should. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-20044) TestClientClusterStatus is flakey
[
https://issues.apache.org/jira/browse/HBASE-20044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-20044.
---
Resolution: Fixed
Assignee: stack
Resolving. No longer on flakies list.
> TestClientClusterStatus is flakey
> -
>
> Key: HBASE-20044
> URL: https://issues.apache.org/jira/browse/HBASE-20044
> Project: HBase
> Issue Type: Sub-task
> Components: flakey
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20044.branch-2.001.patch
>
>
> It killed a nightly. Failed in flakey suite. The compare is too sensitive to
> slightest variance. Here are two failiures... one because the previous test
> had not finished putting back a Region that had been offlined, and the other
> because the count of requests was off slightly. Let me make the compare
> coarser
> {code}
> Test set: org.apache.hadoop.hbase.TestClientClusterStatus
> ---
> Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 27.858 s <<<
> FAILURE! - in org.apache.hadoop.hbase.TestClientClusterStatus
> testNone(org.apache.hadoop.hbase.TestClientClusterStatus) Time elapsed:
> 0.236 s <<< FAILURE!
> java.lang.AssertionError:
> expected: Number of backup masters: 2
> asf903.gq1.ygridcore.net,34661,1519246530655
> asf903.gq1.ygridcore.net,34734,1519246533133
> Number of live region servers: 4
> asf903.gq1.ygridcore.net,37432,1519246533632
> asf903.gq1.ygridcore.net,42964,1519246533554
> asf903.gq1.ygridcore.net,43699,1519246533376
> asf903.gq1.ygridcore.net,56911,1519246533711
> Number of dead region servers: 1
> asf903.gq1.ygridcore.net,57278,1519246533770
> Average load: 0.25
> Number of requests: 17
> Number of regions: 1
> Number of regions in transition: 0> but was: asf903.gq1.ygridcore.net,45687,1519246533030
> Number of backup masters: 2
> asf903.gq1.ygridcore.net,34661,1519246530655
> asf903.gq1.ygridcore.net,34734,1519246533133
> Number of live region servers: 4
> asf903.gq1.ygridcore.net,37432,1519246533632
> asf903.gq1.ygridcore.net,42964,1519246533554
> asf903.gq1.ygridcore.net,43699,1519246533376
> asf903.gq1.ygridcore.net,56911,1519246533711
> Number of dead region servers: 1
> asf903.gq1.ygridcore.net,57278,1519246533770
> Average load: 0.5
> Number of requests: 17
> Number of regions: 2
> Number of regions in transition: 0>
> at
> org.apache.hadoop.hbase.TestClientClusterStatus.testNone(TestClientClusterStatus.java:107)
> {code}
> and
> {code}
> [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.416
> s <<< FAILURE! - in org.apache.hadoop.hbase.TestClientClusterStatus
> [ERROR] testNone(org.apache.hadoop.hbase.TestClientClusterStatus) Time
> elapsed: 0.065 s <<< FAILURE!
> java.lang.AssertionError:
> expected: Number of backup masters: 2
> 9845c79afe69,35076,1519227086213
> 9845c79afe69,45963,1519227086363
> Number of live region servers: 4
> 9845c79afe69,34709,1519227086571
> 9845c79afe69,34961,1519227086645
> 9845c79afe69,35891,1519227086720
> 9845c79afe69,36139,1519227086486
> Number of dead region servers: 1
> 9845c79afe69,41992,1519227086820
> Average load: 0.5
> Number of requests: 17
> Number of regions: 2
> Number of regions in transition: 0> but was: 9845c79afe69,46509,1519227084385
> Number of backup masters: 2
> 9845c79afe69,35076,1519227086213
> 9845c79afe69,45963,1519227086363
> Number of live region servers: 4
> 9845c79afe69,34709,1519227086571
> 9845c79afe69,34961,1519227086645
> 9845c79afe69,35891,1519227086720
> 9845c79afe69,36139,1519227086486
> Number of dead region servers: 1
> 9845c79afe69,41992,1519227086820
> Average load: 0.5
> Number of requests: 19
> Number of regions: 2
> Number of regions in transition: 0>
> at
> org.apache.hadoop.hbase.TestClientClusterStatus.testNone(TestClientClusterStatus.java:107)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
