[jira] [Resolved] (HBASE-23202) ExportSnapshot (import) will fail if copying files to root directory takes longer than cleaner TTL

[Huaxiang Sun (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-23202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Huaxiang Sun resolved HBASE-23202.
--
Fix Version/s: 3.0.0-alpha-1
   Resolution: Fixed

I updated the patch based on review comments (addressed the missed case when 
snapshot working dir is different from the hbase root dir, added a new test 
case for the described case), pushed the patch to branch-2.3, branch-2 and 
master, resolving it.

> ExportSnapshot (import) will fail if copying files to root directory takes 
> longer than cleaner TTL
> --
>
> Key: HBASE-23202
> URL: https://issues.apache.org/jira/browse/HBASE-23202
> Project: HBase
>  Issue Type: Bug
>  Components: snapshots
>Affects Versions: 3.0.0-alpha-1, 1.5.0, 2.2.1, 1.4.11, 2.1.7
>Reporter: Zach York
>Assignee: Guangxu Cheng
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.0
>
>
> HBASE-17330 removed the checking of the snapshot .tmp directory when 
> determining which files are candidates for deletes. It appears that in the 
> latest branches, this isn't an issue for taking a snapshot as it checks 
> whether a snapshot is in progress via the SnapshotManager.
> However, when using the ExportSnapshot tool to import a snapshot into a 
> cluster, it will first copy the snapshot manifest into 
> /.snapshot/.tmp/ [1], copies the files, and then renames the 
> snapshot manifest to the final snapshot directory. If the copyFiles job takes 
> longer than the cleaner TTL, the ExportSnapshot job will fail because HFiles 
> will get deleted before the snapshot is committed to the final directory. 
> The ExportSnapshot tool already has a functionality to skipTmp and write the 
> manifest directly to the final location. However, this has unintended 
> consequences such as the snapshot appearing to the user before it is usable. 
> So it looks like we will have to bring back the tmp directory check to avoid 
> this situation.
> [1] 
> https://github.com/apache/hbase/blob/master/hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/snapshot/ExportSnapshot.java#L1029



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Fwd: Anyone could Help To Review These 2 HBase BuldLoad Related Patchs

[Chang Wu]

Hi  ,
I have 2 patches which is used to fix some issues I found for the BuldLoad
of HBase.
I has been refined it and currently everything looks fine.
Very appreciated if anyone could save your time and have a further review
for these 2 patches.
HBASE-24403 FsDelegationToken Should Cache Token After Acquired A New One :
Issue: https://issues.apache.org/jira/browse/HBASE-24403
Patch: https://github.com/apache/hbase/pull/1743

HBASE-24420 Avoid Meaningless Retry Attempts in Unrecoverable Failure
Issue: https://issues.apache.org/jira/browse/HBASE-24420
Patch: https://github.com/apache/hbase/pull/1764

Thanks,
Chang Wu

[jira] [Resolved] (HBASE-24517) AssignmentManager.start should add meta region to ServerStateNode

[Duo Zhang (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-24517.
---
Hadoop Flags: Reviewed
  Resolution: Fixed

Pushed to branch-2.2+.

Thanks all for reviewing.

> AssignmentManager.start should add meta region to ServerStateNode
> -
>
> Key: HBASE-24517
> URL: https://issues.apache.org/jira/browse/HBASE-24517
> Project: HBase
>  Issue Type: Bug
>  Components: amv2
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Critical
> Fix For: 3.0.0-alpha-1, 2.3.0, 2.2.6
>
>
> In AssignmentManager.start, we will load the meta region state and location 
> from zk and create the RegionStateNode, but we forget to call 
> regionStates.addRegionToServer to add the region to the region server.
> Found this when implementing HBASE-24390. As in HBASE-24390, we will remove 
> RegionInfoBuilder.FIRST_META_REGIONINFO so in SCP, we need to use the 
> getRegionsOnServer instead of RegionInfoBuilder.FIRST_META_REGIONINFO when 
> assigning meta, so the bug becomes a real problem.
> Though it is not a big problem for SCP for current 2.x and master branches, 
> it is a high risky bug. For example, in AssignmentManager.submitServerCrash, 
> now we use the RegionStateNode of meta regions to determine whether the given 
> region server carries meta regions. But it is also valid to test through the 
> ServerStateNode's region list. If later we change this method to use 
> ServerStateNode, it will cause very serious data loss bug.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24444) Should shutdown mini cluster after class in TestMetaAssignmentWithStopMaster

[Guanghao Zhang (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang resolved HBASE-2.

Fix Version/s: 2.2.6
   2.3.0
   3.0.0-alpha-1
   Resolution: Fixed

Pushed to branch-2.2+. Thanks [~wenfeiyi666] for contributing.

> Should shutdown mini cluster after class in TestMetaAssignmentWithStopMaster
> 
>
> Key: HBASE-2
> URL: https://issues.apache.org/jira/browse/HBASE-2
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0-alpha-1, 2.3.0, 2.2.6
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24523) Include target hostname/ip/port in `ipc.ServerNotRunningYetException`

[Nick Dimiduk (Jira)]

Nick Dimiduk created HBASE-24523:


 Summary: Include target hostname/ip/port in 
`ipc.ServerNotRunningYetException`
 Key: HBASE-24523
 URL: https://issues.apache.org/jira/browse/HBASE-24523
 Project: HBase
  Issue Type: Task
  Components: IPC/RPC
Affects Versions: 2.3.0
Reporter: Nick Dimiduk


We get almost 100 lines of exception backtrace along with this exception, but 
the identity of the server with whom the client is trying to communication is 
not included. For example,

{noformat}
2020-06-06 00:35:37,123 WARN  [ChaosMonkey] client.ConnectionImplementation: 
Checking master connection
org.apache.hadoop.hbase.ipc.ServerNotRunningYetException: 
org.apache.hadoop.hbase.ipc.ServerNotRunningYetException: Server is not running 
yet
at 
org.apache.hadoop.hbase.master.HMaster.checkServiceStarted(HMaster.java:2901)
at 
org.apache.hadoop.hbase.master.MasterRpcServices.isMasterRunning(MasterRpcServices.java:1178)
at 
org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:393)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
at 
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:338)
at 
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:318)
...
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24493) [flakey test] TestExportSnapshot family of tests failing due to timeout in AbstractDelegationTokenSecretManager$ExpiredTokenRemover

[Michael Stack (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Stack resolved HBASE-24493.
---
Fix Version/s: 2.3.0
   3.0.0-alpha-1
 Assignee: Michael Stack
   Resolution: Fixed

Pushed the disabling of these four test suites. See sub-issue for reenabling 
when we have handle on yarn history server startup.

> [flakey test] TestExportSnapshot family of tests failing due to timeout in 
> AbstractDelegationTokenSecretManager$ExpiredTokenRemover
> ---
>
> Key: HBASE-24493
> URL: https://issues.apache.org/jira/browse/HBASE-24493
> Project: HBase
>  Issue Type: Test
>  Components: test
>Affects Versions: 2.3.0
>Reporter: Nick Dimiduk
>Assignee: Michael Stack
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.0
>
> Attachments: 
> 0001-HBASE-24493-flakey-test-TestExportSnapshot-family-of.patch, 
> TEST-org.apache.hadoop.hbase.snapshot.TestExportSnapshot.xml
>
>
> I've observed another occurrence of this test timing out, over on 
> https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1786/3/
> The failure message is cryptic, but I think i found the issue. This isn't the 
> {{HBaseClassTestRule}} invoking the timeout, it's something in the test, I 
> think in the mini-cluster.
> There appears to be a timeout set in some kind of secret manager, which is 
> too aggressive for this mini-cluster test. The last component of the 
> mini-cluster, MapReduce, is finally available at T+273501ms -- ~4.5 minutes 
> after process launch. This is how I interpret the log line
> {noformat}
> 2020-06-02 03:20:49,252 INFO  [Thread-223] server.Server(419): Started 
> @273501ms
> {noformat}
> a scant 20ms later we get
> {noformat}
> 2020-06-02 03:20:50,274 ERROR [Thread[Thread-224,5,FailOnTimeoutGroup]] 
> delegation.AbstractDelegationTokenSecretManager$ExpiredTokenRemover(700): 
> ExpiredTokenRemover received java.lang.InterruptedException: sleep interrupted
> 2020-06-02 03:20:50,351 INFO  [Time-limited test] 
> hbase.HBaseTestingUtility(1272): Shutting down minicluster
> {noformat}
> These thread group names have no meaning to me.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24145) Run a correctness test with ITBLL

[Nick Dimiduk (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Dimiduk resolved HBASE-24145.
--
Resolution: Done

> Run a correctness test with ITBLL
> -
>
> Key: HBASE-24145
> URL: https://issues.apache.org/jira/browse/HBASE-24145
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.3.0
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Major
>
> Kick the tires on a recent commit.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24522) consolidate TestSnapshotFileCacheWithDifferentWorkingDir and TestSnapshotFileCache by parameterized test.

[Huaxiang Sun (Jira)]

Huaxiang Sun created HBASE-24522:


 Summary: consolidate TestSnapshotFileCacheWithDifferentWorkingDir 
and TestSnapshotFileCache by  parameterized test.
 Key: HBASE-24522
 URL: https://issues.apache.org/jira/browse/HBASE-24522
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 3.0.0-alpha-1
Reporter: Huaxiang Sun
Assignee: Huaxiang Sun


This is a followup Jira for HBASE-23202.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24521) Reenable the TestExportSnapshot family of tests

[Michael Stack (Jira)]

Michael Stack created HBASE-24521:
-

 Summary: Reenable the TestExportSnapshot family of tests
 Key: HBASE-24521
 URL: https://issues.apache.org/jira/browse/HBASE-24521
 Project: HBase
  Issue Type: Sub-task
Reporter: Michael Stack


The yarn history server can take a while to start. It is hardcoded at one 
minute before all is killed. On loaded servers can take this long to start. 
Cannot disable history server in tests nor can we configure the mini yarn 
cluster so it can take longer starting history server. After this addressed, 
and yarn history server is given more time or disabled, reenable the 
TestExportSnapshot* family of tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24208) Remove RS entry from zk draining servers node after RS been stopped

[Viraj Jasani (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viraj Jasani resolved HBASE-24208.
--
Fix Version/s: (was: 2.2.6)
   (was: 2.3.1)
   2.4.0
 Hadoop Flags: Reviewed
   Resolution: Fixed

Pushed to master and branch-2.

> Remove RS entry from zk draining servers node after RS been stopped
> ---
>
> Key: HBASE-24208
> URL: https://issues.apache.org/jira/browse/HBASE-24208
> Project: HBase
>  Issue Type: Improvement
>Reporter: Anoop Sam John
>Assignee: Gaurav Kanade
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.4.0
>
>
> When a RS is been decommissioned, we will add an entry into the zk node. This 
> will be there unless the same RS instance is recommissioned. 
> But if we want to scale down a cluster, the best path would be to 
> decommission the RSs in the scaling down nodes.  The regions in these RSs 
> will get moved to live RSs. In this case these decommissioned RSs will get 
> stopped later. These will never get recommissioned.  The zk nodes will still 
> be there under draining servers path.
> We can remove this zk node when the RS is getting stopped.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[DISCUSS] Change the IA for MutableSizeHistogram and MutableTimeHistogram to LImitedPrivate

[Rushabh Shah]

Hi,
Currently the IA for MutableSizeHistogram and MutableTimeHistogram is
private. We want to use these classes in PHOENIX project and I thought we
can leverage the existing implementation from hbase histo implementation.
IIUC the private IA can't be used in other projects. Proposing to make it
LimitedPrivate and mark HBaseInterfaceAudience.PHOENIX. Please suggest.
Related jira: https://issues.apache.org/jira/browse/HBASE-24520

[jira] [Resolved] (HBASE-24519) Add ndimiduk as release manager for 2.3

[Nick Dimiduk (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Dimiduk resolved HBASE-24519.
--
Resolution: Fixed

> Add ndimiduk as release manager for 2.3
> ---
>
> Key: HBASE-24519
> URL: https://issues.apache.org/jira/browse/HBASE-24519
> Project: HBase
>  Issue Type: Sub-task
>  Components: community, documentation
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Minor
> Fix For: 3.0.0-alpha-1
>
>
> Looks like we explicitly mention the active release managers in 
> {{_chapters/community.adoc}}. Update.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24520) Change the IA for MutableSizeHistogram and MutableTimeHistogram

[Rushabh Shah (Jira)]

Rushabh Shah created HBASE-24520:


 Summary: Change the IA for MutableSizeHistogram and 
MutableTimeHistogram
 Key: HBASE-24520
 URL: https://issues.apache.org/jira/browse/HBASE-24520
 Project: HBase
  Issue Type: Task
  Components: metrics
Reporter: Rushabh Shah


Currently the IA for MutableSizeHistogram and MutableTimeHistogram is private. 
We want to use these classes in phoenix project and I thought we can leverage 
the existing implementation from hbase histo implementation. IIUC the private 
IA can't be used in other projects. Proposing to make it LimitedPrivate and 
mark HBaseInterfaceAudience.PHOENIX. Please suggest.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24519) Add ndimiduk as release manager for 2.3

[Nick Dimiduk (Jira)]

Nick Dimiduk created HBASE-24519:


 Summary: Add ndimiduk as release manager for 2.3
 Key: HBASE-24519
 URL: https://issues.apache.org/jira/browse/HBASE-24519
 Project: HBase
  Issue Type: Sub-task
  Components: community, documentation
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 3.0.0-alpha-1


Looks like we explicitly mention the active release managers in 
{{_chapters/community.adoc}}. Update.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-23997) Consider JDK11 in our support matrix

[Nick Dimiduk (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-23997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Dimiduk resolved HBASE-23997.
--
Resolution: Fixed

> Consider JDK11 in our support matrix
> 
>
> Key: HBASE-23997
> URL: https://issues.apache.org/jira/browse/HBASE-23997
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Major
> Fix For: 3.0.0-alpha-1
>
>
> Let's figure out how we present our JDK11 story to eager users and operators.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] HBASE-20904 Prometheus /metrics http endpoint for monitoring integration

[Sean Busbey]

Oh! that's a great reference. Are there docs for those over in Hadoop or
Ozone?

On Mon, Jun 8, 2020 at 10:46 AM Wei-Chiu Chuang  wrote:

> Might be useful to look at the Hadoop Prometheus end point and Ozone
> Prometheus end point as well.
>
>1. HADOOP-16398 
>
>
>1. HDDS-919 
>
>
> A known issue with the Hadoop Prometheus implementation is that it lacks
> SPENGO support, so there is a problem integrating it with the Kerberized
> environment. The solution is to whitelist the Prometheus end point so it
> doesn't require SPNEGO.
>
>
> On Sat, Jun 6, 2020 at 10:00 PM ckai2480  wrote:
>
> > Hi,
> >
> > I am working on HBASE-20904 (Prometheus /metrics http endpoint for
> > monitoring integration) and have created a patch (
> > https://github.com/apache/hbase/pull/1814). @busbey and @saintstack
> > suggested some good changes which I have incorporated in my local
> > branch and wanted to know other's suggestions on it before I commit to
> > the remote.
> >
> > Prometheus
> > 1. Prometheus is a monitoring software which uses HTTP to pull the
> > metrics from the monitored processes.
> > 2. The collected data can be used to anamoly detection, altering etc.
> >
> > Problem HBASE-20904 solves.
> > 1. Implementing a servlet to expose these metrics.
> >
> > Currently I have implemented this as follows
> > 1. Expose two end points
> >   /prometheus:
> >   exposes the metrics captured in native hbase metrics
> >   /prometheus-hadoop2:
> >   exposes the metrics captured using hadoop2 metrics.
> >
> > latter is planned to be removed once all the metric sources start
> > using the native metrics API.
> >
> > **do the endpoints names look ok?**
> >
> > 2. Make the /jmx, /prometheus-hadoop2, /prometheus, /metrics servlets
> > optional by providing a multivalued config key with the first two
> > servlets as default (values will be classnames or aliases **which one
> > do you think is good idea**).
> >
> > Out of curiosity.. Why the hadoop2 metrics still exists in HBase, I see
> > HBASE-14282 is open and task issues linked are closed. Are there any
> > unlinked issues here?
> >
> > Thanks,
> > Madhusoodan
> >
> >
>

Re: [DISCUSS] HBASE-20904 Prometheus /metrics http endpoint for monitoring integration

[Wei-Chiu Chuang]

Might be useful to look at the Hadoop Prometheus end point and Ozone
Prometheus end point as well.

   1. HADOOP-16398 


   1. HDDS-919 


A known issue with the Hadoop Prometheus implementation is that it lacks
SPENGO support, so there is a problem integrating it with the Kerberized
environment. The solution is to whitelist the Prometheus end point so it
doesn't require SPNEGO.


On Sat, Jun 6, 2020 at 10:00 PM ckai2480  wrote:

> Hi,
>
> I am working on HBASE-20904 (Prometheus /metrics http endpoint for
> monitoring integration) and have created a patch (
> https://github.com/apache/hbase/pull/1814). @busbey and @saintstack
> suggested some good changes which I have incorporated in my local
> branch and wanted to know other's suggestions on it before I commit to
> the remote.
>
> Prometheus
> 1. Prometheus is a monitoring software which uses HTTP to pull the
> metrics from the monitored processes.
> 2. The collected data can be used to anamoly detection, altering etc.
>
> Problem HBASE-20904 solves.
> 1. Implementing a servlet to expose these metrics.
>
> Currently I have implemented this as follows
> 1. Expose two end points
>   /prometheus:
>   exposes the metrics captured in native hbase metrics
>   /prometheus-hadoop2:
>   exposes the metrics captured using hadoop2 metrics.
>
> latter is planned to be removed once all the metric sources start
> using the native metrics API.
>
> **do the endpoints names look ok?**
>
> 2. Make the /jmx, /prometheus-hadoop2, /prometheus, /metrics servlets
> optional by providing a multivalued config key with the first two
> servlets as default (values will be classnames or aliases **which one
> do you think is good idea**).
>
> Out of curiosity.. Why the hadoop2 metrics still exists in HBase, I see
> HBASE-14282 is open and task issues linked are closed. Are there any
> unlinked issues here?
>
> Thanks,
> Madhusoodan
>
>

[jira] [Created] (HBASE-24518) waitForNamespaceOnline() should return false if any region is offline

[Viraj Jasani (Jira)]

Viraj Jasani created HBASE-24518:


 Summary: waitForNamespaceOnline() should return false if any 
region is offline
 Key: HBASE-24518
 URL: https://issues.apache.org/jira/browse/HBASE-24518
 Project: HBase
  Issue Type: Bug
Reporter: Viraj Jasani
Assignee: Viraj Jasani


HMaster waits for namespace regions to come online only for rolling upgrade 
scenario (from 1.x to 2.x), however, waitForNamespaceOnline() does not return 
false for any offline region. We should fix this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (HBASE-24483) Add repeated prefix logging for MultipleColumnPrefixFilter

[Viraj Jasani (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-24483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viraj Jasani resolved HBASE-24483.
--
Fix Version/s: 2.2.6
   1.7.0
   2.3.0
   3.0.0-alpha-1
 Hadoop Flags: Reviewed
   Resolution: Fixed

Pushed to master, branch-2, 2.3, 2.2 and branch-1.

> Add repeated prefix logging for MultipleColumnPrefixFilter
> --
>
> Key: HBASE-24483
> URL: https://issues.apache.org/jira/browse/HBASE-24483
> Project: HBase
>  Issue Type: Improvement
>  Components: Filters
>Reporter: Zheng Wang
>Assignee: Zheng Wang
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 2.3.0, 1.7.0, 2.2.6
>
>
> Current it is not easy to find which one is repeated if the input prefixes 
> are not a few.
>  
> {code:java}
>  java.lang.IllegalArgumentException: prefixes must be distinct
> at 
> org.apache.hadoop.hbase.filter.MultipleColumnPrefixFilter.(MultipleColumnPrefixFilter.java:50)
>  
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24517) AssignmentManager.start should add meta region to ServerStateNode

[Duo Zhang (Jira)]

Duo Zhang created HBASE-24517:
-

 Summary: AssignmentManager.start should add meta region to 
ServerStateNode
 Key: HBASE-24517
 URL: https://issues.apache.org/jira/browse/HBASE-24517
 Project: HBase
  Issue Type: Bug
  Components: amv2
Reporter: Duo Zhang
Assignee: Duo Zhang
 Fix For: 3.0.0-alpha-1, 2.3.0, 2.2.6


In AssignmentManager.start, we will load the meta region state and location 
from zk and create the RegionStateNode, but we forget to call 
regionStates.addRegionToServer to add the region to the region server.

Found this when implementing HBASE-24390. As in HBASE-24390, we will remove 
RegionInfoBuilder.FIRST_META_REGIONINFO so in SCP, we need to use the 
getRegionsOnServer instead of RegionInfoBuilder.FIRST_META_REGIONINFO when 
assigning meta, so the bug becomes a real problem.

Though it is not a big problem for SCP for current 2.x and master branches, it 
is a high risky bug. For example, in AssignmentManager.submitServerCrash, now 
we use the RegionStateNode of meta regions to determine whether the given 
region server carries meta regions. But it is also valid to test through the 
ServerStateNode's region list. If later we change this method to use 
ServerStateNode, it will cause very serious data loss bug.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24516) Parameter pass incorrectly when refactor SecureBulkLoadClient

[Qilin Cao (Jira)]

Qilin Cao created HBASE-24516:
-

 Summary: Parameter pass incorrectly when refactor 
SecureBulkLoadClient
 Key: HBASE-24516
 URL: https://issues.apache.org/jira/browse/HBASE-24516
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 2.2.5, 2.2.2
Reporter: Qilin Cao
Assignee: Qilin Cao


Parameter pass incorrectly when refactor SecureBulkLoadClient started in 
HBASE-23136.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)