[jira] [Resolved] (HBASE-20904) Prometheus /metrics http endpoint for monitoring integration

[Duo Zhang (Jira)]

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

Duo Zhang resolved HBASE-20904.
---
Fix Version/s: 2.6.0
   3.0.0-alpha-4
 Hadoop Flags: Reviewed
   Resolution: Fixed

Pushed to master and branch-2.

Thanks [~lkovacs] for contributing!

This is a new feature and 2.5.0 is on due so I do not commit this to branch-2.5.

[~apurtell] [~ndimiduk] FYI.

> Prometheus /metrics http endpoint for monitoring integration
> 
>
> Key: HBASE-20904
> URL: https://issues.apache.org/jira/browse/HBASE-20904
> Project: HBase
>  Issue Type: New Feature
>  Components: metrics, monitoring
>Reporter: Hari Sekhon
>Assignee: Luca Kovacs
>Priority: Major
> Fix For: 2.6.0, 3.0.0-alpha-4
>
>
> Feature Request to add Prometheus /metrics http endpoint for monitoring 
> integration:
> [https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cscrape_config%3E]
> Prometheus metrics format for that endpoint:
> [https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (HBASE-27321) The ReplicationLogCleaner is not thread safe but can be called from different thread at the same time

[Duo Zhang (Jira)]

Duo Zhang created HBASE-27321:
-

 Summary: The ReplicationLogCleaner is not thread safe but can be 
called from different thread at the same time
 Key: HBASE-27321
 URL: https://issues.apache.org/jira/browse/HBASE-27321
 Project: HBase
  Issue Type: Bug
Reporter: Duo Zhang


In preClean method we will update the class fields and then use them in the 
getDeletableFiles method. This implies that we will have only one cleaner run 
at the same time.

But actually, in MasterRpcServices.runCleanerChore, we will call execute the 
HFileCleaner and LogCleaner directly, not in the cleanerChore thread.

This could cause data loss for replication, which is a very serious problem.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] HBase 2.4.14 release candidate (RC0) is available

[Huaxiang Sun]

s/HBASE-27215/HBASE-27125 in the previous email I sent.

On Tue, Aug 23, 2022 at 9:26 AM Huaxiang Sun  wrote:

> Ok, I went through the jira list for 2.4.14 again. For some reason, I
> marked "fixed version" for HBASE-27301 by accident, which was supposed to
> be
>
> HBASE-27125. For HBASE-27215, it was released in 2.4.13, however, its
> "fixed version" is marked as 2.4.14 by accident.
>
> So HBASE-27215 was not included in 2.4.13's release notes.
>
>
> I corrected both jira's fixed versions and respining a new RC.
>
>
>
>
> On Tue, Aug 23, 2022 at 8:44 AM Huaxiang Sun 
> wrote:
>
>> Sorry to miss your message, checking it now, I may marked the wrong jira,
>> let me check the jira list and respin RC.
>>
>> Thanks
>> Huaxiang
>>
>> On Mon, Aug 22, 2022 at 6:41 PM 张铎(Duo Zhang) 
>> wrote:
>>
>>> Sorry but -1.
>>>
>>> I replied on HBASE-27301 that the issue should be included in 2.4.14
>>> but got no response.
>>>
>>> And I checked the CHANGES.md, there is no HBASE-27301 in it, neither
>>> in 2.4.13 nor 2.4.14.
>>>
>>> Please fix this issue and publish an RC again.
>>>
>>> Thanks.
>>>
>>> Huaxiang Sun  于2022年8月23日周二 07:15写道：
>>> >
>>> > Please vote on this Apache hbase release candidate,
>>> >
>>> > hbase-2.4.14RC0
>>> >
>>> >
>>> > The VOTE will remain open for at least 72 hours.
>>> >
>>> >
>>> > [ ] +1 Release this package as Apache hbase 2.4.14
>>> >
>>> > [ ] -1 Do not release this package because ...
>>> >
>>> >
>>> > The tag to be voted on is 2.4.14RC0:
>>> >
>>> >
>>> >   https://github.com/apache/hbase/tree/2.4.14RC0
>>> >
>>> >
>>> > This tag currently points to git reference
>>> >
>>> >
>>> >   f507fb71c6724ed44eb4ac25bbdd3e35b2441a1a
>>> >
>>> >
>>> > The release files, including signatures, digests, as well as CHANGES.md
>>> >
>>> > and RELEASENOTES.md included in this RC can be found at:
>>> >
>>> >
>>> >   https://dist.apache.org/repos/dist/dev/hbase/2.4.14RC0/
>>> >
>>> >
>>> > Maven artifacts are available in a staging repository at:
>>> >
>>> >
>>> >
>>> https://repository.apache.org/content/repositories/orgapachehbase-1493/
>>> >
>>> >
>>> > Artifacts were signed with the 0x117C835E key which can be found in:
>>> >
>>> >
>>> >   https://downloads.apache.org/hbase/KEYS
>>> >
>>> >
>>> > To learn more about Apache hbase, please see
>>> >
>>> >
>>> >   http://hbase.apache.org/
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Your HBase Release Manager
>>>
>>

[jira] [Created] (HBASE-27320) hide some sensitive configuration information in the UI

[ruanhui (Jira)]

ruanhui created HBASE-27320:
---

 Summary: hide some sensitive configuration information in the UI
 Key: HBASE-27320
 URL: https://issues.apache.org/jira/browse/HBASE-27320
 Project: HBase
  Issue Type: Improvement
  Components: UI
Affects Versions: 3.0.0-alpha-3
Reporter: ruanhui
Assignee: ruanhui
 Fix For: 3.0.0-alpha-4


In the discussion about how to store keystore/truststore password securely, 
[~bbeaudreault]  mentioned and I quote here

"I agree that it seems insecure to put it directly into the hbase-site.xml. 
Another reason is due to the RS UI which (helpfully) can print the entire site 
configuration. We’d need to make sure the password is excluded from that, but 
better to remove it from site xml altogether".

I also felt that some sensitive information was exposed in the UI, for example, 
if we set superuser in the hbase-site.xml, the non-admin users can obtain 
superuser information and simulate superuser to perform some non-permitted 
operations on the cluster. So I think maybe we should hide these sensitive 
information in the UI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] HBase 2.4.14 release candidate (RC0) is available

[Huaxiang Sun]

Ok, I went through the jira list for 2.4.14 again. For some reason, I
marked "fixed version" for HBASE-27301 by accident, which was supposed to
be

HBASE-27125. For HBASE-27215, it was released in 2.4.13, however, its
"fixed version" is marked as 2.4.14 by accident.

So HBASE-27215 was not included in 2.4.13's release notes.


I corrected both jira's fixed versions and respining a new RC.




On Tue, Aug 23, 2022 at 8:44 AM Huaxiang Sun  wrote:

> Sorry to miss your message, checking it now, I may marked the wrong jira,
> let me check the jira list and respin RC.
>
> Thanks
> Huaxiang
>
> On Mon, Aug 22, 2022 at 6:41 PM 张铎(Duo Zhang) 
> wrote:
>
>> Sorry but -1.
>>
>> I replied on HBASE-27301 that the issue should be included in 2.4.14
>> but got no response.
>>
>> And I checked the CHANGES.md, there is no HBASE-27301 in it, neither
>> in 2.4.13 nor 2.4.14.
>>
>> Please fix this issue and publish an RC again.
>>
>> Thanks.
>>
>> Huaxiang Sun  于2022年8月23日周二 07:15写道：
>> >
>> > Please vote on this Apache hbase release candidate,
>> >
>> > hbase-2.4.14RC0
>> >
>> >
>> > The VOTE will remain open for at least 72 hours.
>> >
>> >
>> > [ ] +1 Release this package as Apache hbase 2.4.14
>> >
>> > [ ] -1 Do not release this package because ...
>> >
>> >
>> > The tag to be voted on is 2.4.14RC0:
>> >
>> >
>> >   https://github.com/apache/hbase/tree/2.4.14RC0
>> >
>> >
>> > This tag currently points to git reference
>> >
>> >
>> >   f507fb71c6724ed44eb4ac25bbdd3e35b2441a1a
>> >
>> >
>> > The release files, including signatures, digests, as well as CHANGES.md
>> >
>> > and RELEASENOTES.md included in this RC can be found at:
>> >
>> >
>> >   https://dist.apache.org/repos/dist/dev/hbase/2.4.14RC0/
>> >
>> >
>> > Maven artifacts are available in a staging repository at:
>> >
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapachehbase-1493/
>> >
>> >
>> > Artifacts were signed with the 0x117C835E key which can be found in:
>> >
>> >
>> >   https://downloads.apache.org/hbase/KEYS
>> >
>> >
>> > To learn more about Apache hbase, please see
>> >
>> >
>> >   http://hbase.apache.org/
>> >
>> >
>> > Thanks,
>> >
>> > Your HBase Release Manager
>>
>

[jira] [Created] (HBASE-27319) Fix RC calculation in create-release

[Nick Dimiduk (Jira)]

Nick Dimiduk created HBASE-27319:


 Summary: Fix RC calculation in create-release
 Key: HBASE-27319
 URL: https://issues.apache.org/jira/browse/HBASE-27319
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 3.0.0-alpha-4
Reporter: Nick Dimiduk


Working on 2.5.0RC1, there exits a 2.5.0RC0 in the repo already. 
`create-release` is proposing 2.5.0RC2 as the tag.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] HBase 2.4.14 release candidate (RC0) is available

[Huaxiang Sun]

Sorry to miss your message, checking it now, I may marked the wrong jira,
let me check the jira list and respin RC.

Thanks
Huaxiang

On Mon, Aug 22, 2022 at 6:41 PM 张铎(Duo Zhang)  wrote:

> Sorry but -1.
>
> I replied on HBASE-27301 that the issue should be included in 2.4.14
> but got no response.
>
> And I checked the CHANGES.md, there is no HBASE-27301 in it, neither
> in 2.4.13 nor 2.4.14.
>
> Please fix this issue and publish an RC again.
>
> Thanks.
>
> Huaxiang Sun  于2022年8月23日周二 07:15写道：
> >
> > Please vote on this Apache hbase release candidate,
> >
> > hbase-2.4.14RC0
> >
> >
> > The VOTE will remain open for at least 72 hours.
> >
> >
> > [ ] +1 Release this package as Apache hbase 2.4.14
> >
> > [ ] -1 Do not release this package because ...
> >
> >
> > The tag to be voted on is 2.4.14RC0:
> >
> >
> >   https://github.com/apache/hbase/tree/2.4.14RC0
> >
> >
> > This tag currently points to git reference
> >
> >
> >   f507fb71c6724ed44eb4ac25bbdd3e35b2441a1a
> >
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> >
> > and RELEASENOTES.md included in this RC can be found at:
> >
> >
> >   https://dist.apache.org/repos/dist/dev/hbase/2.4.14RC0/
> >
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1493/
> >
> >
> > Artifacts were signed with the 0x117C835E key which can be found in:
> >
> >
> >   https://downloads.apache.org/hbase/KEYS
> >
> >
> > To learn more about Apache hbase, please see
> >
> >
> >   http://hbase.apache.org/
> >
> >
> > Thanks,
> >
> > Your HBase Release Manager
>

Re: Request to join the HBase Slack channel

[Henry Sowell]

Thank you!

On Mon, Aug 22, 2022 at 9:36 PM Bryan Beaudreault
 wrote:

> Sent
>
> On Mon, Aug 22, 2022 at 8:44 PM Henry Sowell 
> wrote:
>
> > Good evening,
> >
> > Following-up here, can I join the Hbase slack channel? I'm excited to
> > participate.
> >
> > Thank you!
> >
> > Henry
> >
> > On Wed, Aug 17, 2022 at 5:03 PM Henry Sowell 
> > wrote:
> >
> > > Hello!
> > >
> > > Can I please have access to the HBase slack channel?
> > >
> > > Thank you,
> > >
> > > Henry
> > >
> >
>

Re: How to store keystore/truststore password securely?

[Duo Zhang]

Maybe we could introduce two configs for a password, password-provider
and password-provider-parameter

The default implementation is FileBasedPasswordProvider, where the
parameter is just a location. And also an EnvVarPasswordProvider,
where the parameter is the name of the environment variable.

And users could also implement their own providers.

WDYT?

Bryan Beaudreault  于2022年8月23日周二 21:12写道：
>
> I agree that it seems insecure to put it directly into the hbase-site.xml.
> Another reason is due to the RS UI which (helpfully) can print the entire
> site configuration. We’d need to make sure the password is excluded from
> that, but better to remove it from site xml altogether.
>
> That said, we already have the concept of keystore passwords in hbase --
> search our refguide for "password" and you'll see two examples: for jmx ssl
> and for encryption-at-rest.  Both cases seem to take the approach of
> allowing an explicit password or a password file. Another example we can
> take inspiration from is Hadoop Credentials API[1] which allows specifying
> by environment variable or password file. Searching around for other
> opensource projects, these options seem to be the most common for the
> keystore password. See Cassandra[2] and Zookeeper[3] as further examples.
>
> Elastic takes the approach of allowing "secure settings" [4], which are
> stored in a separate keystore managed via elasticsearch-keystore command.
> This just pushes the problem down a level, as that keystore needs to be
> password protected as well. In which case, you are expected to provide the
> path to a password file using an environment variable at startup [5]. This
> approach is very similar to Hadoop Credentials API.
>
> Personally I think we should go with the password file path approach. This
> gives a lot of flexibility, for example one could delete it after startup
> like mentioned in [5]. I like the idea of providing a decryption interface
> option for advanced users, but I think we still need to provide an option
> which doesn't require writing a bunch of code.
>
> Alternatively I think a case could be made for unifying on Hadoop's
> Credential API. IMO, if we did that, it should be a separate initiative
> since we'd probably want to unify our existing keystore configurations into
> it and it'd probably need a major version release as a result.
>
> [1]
> https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/CredentialProviderAPI.html
> [2]
> https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/configuration/secureSSLClientToNode.html
> [3] https://zookeeper.apache.org/doc/r3.8.0/zookeeperAdmin.html
> (search keyStore.password)
> [4]
> https://www.elastic.co/guide/en/elasticsearch/reference/master/secure-settings.html
> [5]
> https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html#rpm-running-systemd
>
> On Mon, Aug 22, 2022 at 11:33 PM 张铎(Duo Zhang) 
> wrote:
>
> > In real production deployment, usually we will store an encrypted
> > password in the configuration file, and then decrypt it after loading,
> > to actually use it.
> >
> > And how to get the decryption will depend on the environment. On cloud
> > VMs, usually you can use an encryption service to decrypt the
> > password. On K8s, you can mount the key using secret.
> >
> > So maybe we should abstract a decryption interface, so users could
> > implement it on their own to find a suitable way to decrypt the
> > encrypted password?
> >
> > Andor Molnar  于2022年8月23日周二 05:55写道：
> >
> > >
> > > Hi team,
> > >
> > > Netty TLS support is now merged into master and branch-2 branches.
> > > Currently keystore/truststore passwords can only be stored in hbase-
> > > site.xml which is not the best approach from security perspective.
> > >
> > > In the docs review Sergey Soldatov mentioned (
> > > https://github.com/apache/hbase/pull/4717/files#r951768699
> > )
> > an approach
> > > in HDFS where password can be stored in special files or in environment
> > > variables.
> > >
> > > Sergey, would you please point me to the details of that
> > > implementation? Sounds like it would be acceptable for HBase too.
> > >
> > > Is there any other idea that folks could recommend?
> > >
> > > Thanks,
> > > Andor
> > >
> > >
> > >
> >

[jira] [Created] (HBASE-27318) Configuration to allow fallback to non-SSL if handshake fails

[Bryan Beaudreault (Jira)]

Bryan Beaudreault created HBASE-27318:
-

 Summary: Configuration to allow fallback to non-SSL if handshake 
fails
 Key: HBASE-27318
 URL: https://issues.apache.org/jira/browse/HBASE-27318
 Project: HBase
  Issue Type: Improvement
Reporter: Bryan Beaudreault


[~zhangduo] brought up a great idea when reviewing the new native TLS docs. 
Since HMasters and RegionServers are both clients and servers, currently it 
requires multiple cluster restarts to transition an existing cluster to TLS:
{quote}1. Enable {{hbase.server.netty.tls.enabled}} only, with 
supportPlaintext=true. After restart, servers will _accept_ TLS, but not _send_ 
TLS. 

2. Additionally enable {{hbase.client.netty.tls.enabled}} on servers, keeping 
supportPlaintext=true. After restart, servers will now _accept and send_ TLS.

3. Remove supportPlaintext=true. After restart, servers will reject requests if 
not TLS.

Clients can be updated to use {{hbase.client.netty.tls.enabled}} either after 
step 1 or 2, but before 3.
{quote}
This could be simplified by allowing the client-side to also fallback to 
plaintext if handshake fails:
{quote}Theoretically at client side it is possible. In the NettyRpcConnection 
implementation, before the ssl handshake finishes, we will not send any data 
out. So if we want to fallback to non ssl communication, we could just remove 
the ssl handler and set up the connection without encryption. But probably at 
server side we will just close the connection...
{quote}
We'd need to test to see how the server-side handles this downgrade, per the 
last sentence above.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: How to store keystore/truststore password securely?

[Bryan Beaudreault]

I agree that it seems insecure to put it directly into the hbase-site.xml.
Another reason is due to the RS UI which (helpfully) can print the entire
site configuration. We’d need to make sure the password is excluded from
that, but better to remove it from site xml altogether.

That said, we already have the concept of keystore passwords in hbase --
search our refguide for "password" and you'll see two examples: for jmx ssl
and for encryption-at-rest.  Both cases seem to take the approach of
allowing an explicit password or a password file. Another example we can
take inspiration from is Hadoop Credentials API[1] which allows specifying
by environment variable or password file. Searching around for other
opensource projects, these options seem to be the most common for the
keystore password. See Cassandra[2] and Zookeeper[3] as further examples.

Elastic takes the approach of allowing "secure settings" [4], which are
stored in a separate keystore managed via elasticsearch-keystore command.
This just pushes the problem down a level, as that keystore needs to be
password protected as well. In which case, you are expected to provide the
path to a password file using an environment variable at startup [5]. This
approach is very similar to Hadoop Credentials API.

Personally I think we should go with the password file path approach. This
gives a lot of flexibility, for example one could delete it after startup
like mentioned in [5]. I like the idea of providing a decryption interface
option for advanced users, but I think we still need to provide an option
which doesn't require writing a bunch of code.

Alternatively I think a case could be made for unifying on Hadoop's
Credential API. IMO, if we did that, it should be a separate initiative
since we'd probably want to unify our existing keystore configurations into
it and it'd probably need a major version release as a result.

[1]
https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/CredentialProviderAPI.html
[2]
https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/configuration/secureSSLClientToNode.html
[3] https://zookeeper.apache.org/doc/r3.8.0/zookeeperAdmin.html
(search keyStore.password)
[4]
https://www.elastic.co/guide/en/elasticsearch/reference/master/secure-settings.html
[5]
https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html#rpm-running-systemd

On Mon, Aug 22, 2022 at 11:33 PM 张铎(Duo Zhang) 
wrote:

> In real production deployment, usually we will store an encrypted
> password in the configuration file, and then decrypt it after loading,
> to actually use it.
>
> And how to get the decryption will depend on the environment. On cloud
> VMs, usually you can use an encryption service to decrypt the
> password. On K8s, you can mount the key using secret.
>
> So maybe we should abstract a decryption interface, so users could
> implement it on their own to find a suitable way to decrypt the
> encrypted password?
>
> Andor Molnar  于2022年8月23日周二 05:55写道：
>
> >
> > Hi team,
> >
> > Netty TLS support is now merged into master and branch-2 branches.
> > Currently keystore/truststore passwords can only be stored in hbase-
> > site.xml which is not the best approach from security perspective.
> >
> > In the docs review Sergey Soldatov mentioned (
> > https://github.com/apache/hbase/pull/4717/files#r951768699
> )
> an approach
> > in HDFS where password can be stored in special files or in environment
> > variables.
> >
> > Sergey, would you please point me to the details of that
> > implementation? Sounds like it would be acceptable for HBase too.
> >
> > Is there any other idea that folks could recommend?
> >
> > Thanks,
> > Andor
> >
> >
> >
>

[jira] [Resolved] (HBASE-27297) Backport "HBASE-26810 Add dynamic configuration support for system coprocessors" to branch-2.5

[Nick Dimiduk (Jira)]

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

Nick Dimiduk resolved HBASE-27297.
--
  Assignee: (was: Tak-Lon (Stephen) Wu)
Resolution: Duplicate

Resolved via HBASE-26882.

> Backport "HBASE-26810 Add dynamic configuration support for system 
> coprocessors" to branch-2.5
> --
>
> Key: HBASE-27297
> URL: https://issues.apache.org/jira/browse/HBASE-27297
> Project: HBase
>  Issue Type: Improvement
>  Components: conf, Coprocessors
>Affects Versions: 2.5.0, 2.5.1
>Reporter: Tak-Lon (Stephen) Wu
>Priority: Major
>
> Backport HBASE-26810 dynamic configuration for system coprocessor to 
> branch-2.5 , this have been done in master and branch-2, so let's see if we 
> can have it in branch-2.5 before 2.5.0 or 2.5.1 release



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-26882) Backport "HBASE-26810 Add dynamic configuration support for system coprocessors" to branch-2

[Nick Dimiduk (Jira)]

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

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

> Backport "HBASE-26810 Add dynamic configuration support for system 
> coprocessors" to branch-2
> 
>
> Key: HBASE-26882
> URL: https://issues.apache.org/jira/browse/HBASE-26882
> Project: HBase
>  Issue Type: Task
>  Components: Coprocessors, master, regionserver
>Affects Versions: 2.5.0, 2.6.0, 2.4.12
>Reporter: Tak-Lon (Stephen) Wu
>Assignee: Tak-Lon (Stephen) Wu
>Priority: Major
> Fix For: 2.5.0, 2.4.12
>
>
> Backport HBASE-26810 to streams of branch-2



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (HBASE-27317) Correcting the Store file tracker tool help doc option

[Abhradeep Kundu (Jira)]

Abhradeep Kundu created HBASE-27317:
---

 Summary: Correcting the Store file tracker tool help doc option
 Key: HBASE-27317
 URL: https://issues.apache.org/jira/browse/HBASE-27317
 Project: HBase
  Issue Type: Sub-task
Reporter: Abhradeep Kundu
Assignee: Abhradeep Kundu


Column family is not an optional parameter, we need to correct the sysout msg 
properly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (HBASE-27316) Time based metrics will be reset after any get request

[Yunbo Fan (Jira)]

Yunbo Fan created HBASE-27316:
-

 Summary: Time based metrics will be reset after any get request
 Key: HBASE-27316
 URL: https://issues.apache.org/jira/browse/HBASE-27316
 Project: HBase
  Issue Type: Bug
  Components: metrics
Affects Versions: 2.4.13
Reporter: Yunbo Fan


Jmx metrics can be query by http request.

But metrics will be reset after any get request.

The root cause may be the implement of Histogram's method "snapshot"
{code:java}
@Override
public Snapshot snapshot() {
  return histogram.snapshotAndReset();
} {code}
It will call snapshot and reset at the same time.

I think it should not be reset cause we may need history metrics.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27311) The implementation of syncReplicationPeerLock is incomplete

[Duo Zhang (Jira)]

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

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

Merged to master.

Thanks [~sunxin] for reviewing!

> The implementation of syncReplicationPeerLock is incomplete
> ---
>
> Key: HBASE-27311
> URL: https://issues.apache.org/jira/browse/HBASE-27311
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2, Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0-alpha-4
>
>
> We also need to restore the state after loading the procedure after master 
> restarts.
> And we'd better not just let the PEWorker hand there on waiting the 
> semaphore, better to let the procedure suspend and retry later.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)