[jira] [Resolved] (HBASE-27171) Fix Annotation Error in HRegionFileSystem
[
https://issues.apache.org/jira/browse/HBASE-27171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-27171.
---
Fix Version/s: 2.5.0
3.0.0-alpha-4
2.4.14
Hadoop Flags: Reviewed
Resolution: Fixed
Pushed to branch-2.4+.
Thanks [~tangtianhang] for contributing!
> Fix Annotation Error in HRegionFileSystem
> -
>
> Key: HBASE-27171
> URL: https://issues.apache.org/jira/browse/HBASE-27171
> Project: HBase
> Issue Type: Bug
>Reporter: tianhang tang
>Assignee: tianhang tang
>Priority: Trivial
> Fix For: 2.5.0, 3.0.0-alpha-4, 2.4.14
>
>
> The annotation of setStoragePolicy:
> {code:java}
> See see hadoop 2.6+ ... {code}
> should be
> {code:java}
> See hadoop 2.6+ {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (HBASE-23330) Expose cluster ID for clients using it for delegation token based auth
[
https://issues.apache.org/jira/browse/HBASE-23330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-23330.
---
Fix Version/s: 2.5.0
2.4.14
(was: 2.3.0)
Hadoop Flags: Reviewed
Resolution: Fixed
> Expose cluster ID for clients using it for delegation token based auth
>
>
> Key: HBASE-23330
> URL: https://issues.apache.org/jira/browse/HBASE-23330
> Project: HBase
> Issue Type: Sub-task
> Components: Client, master
>Affects Versions: 3.0.0-alpha-1
>Reporter: Bharath Vissapragada
>Assignee: Bharath Vissapragada
>Priority: Major
> Fix For: 2.5.0, 2.4.14, 1.7.0, 3.0.0-alpha-1
>
>
> As Gary Helming noted in HBASE-18095, some clients use Cluster ID for
> delgation based auth.
> {quote}
> There is an additional complication here for token-based authentication. When
> a delegation token is used for SASL authentication, the client uses the
> cluster ID obtained from Zookeeper to select the token identifier to use. So
> there would also need to be some Zookeeper-less, unauthenticated way to
> obtain the cluster ID as well.
> {quote}
> Once we move ZK out of the picture, cluster ID sits behind an end point that
> needs to be authenticated. Figure out a way to expose this to clients.
> One suggestion in the comments (from Andrew)
> {quote}
> Cluster ID lookup is most easily accomplished with a new servlet on the
> HTTP(S) endpoint on the masters, serving the cluster ID as plain text. It
> can't share the RPC server endpoint when SASL is enabled because any
> interaction with that endpoint must be authenticated. This is ugly but
> alternatives seem worse. One alternative would be a second RPC port for APIs
> that do not / cannot require prior authentication.
> {quote}
> There could be implications if SPNEGO is enabled on these http(s) end points.
> We need to make sure that it is handled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-27181) Replica region support in HBCK2 setRegionState option
Huaxiang Sun created HBASE-27181: Summary: Replica region support in HBCK2 setRegionState option Key: HBASE-27181 URL: https://issues.apache.org/jira/browse/HBASE-27181 Project: HBase Issue Type: Improvement Components: hbck2 Affects Versions: 2.4.13 Reporter: Huaxiang Sun Assignee: Huaxiang Sun Replica region id is not recognized by hbck2's setRegionState as it does not show up in meta. We run into cases that it needs to set region state in meta for replica regions in order to fix inconsistency. We ended up writing the state manually into meta table and did a master failover to sync state from meta table. hbck2's setRegionState needs to support replica region id and handles it nicely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-27173) Consider adding ResourceLeakDetector to RefCnt
[ https://issues.apache.org/jira/browse/HBASE-27173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Beaudreault resolved HBASE-27173. --- Resolution: Duplicate This ended up being added in HBASE-27170 > Consider adding ResourceLeakDetector to RefCnt > -- > > Key: HBASE-27173 > URL: https://issues.apache.org/jira/browse/HBASE-27173 > Project: HBase > Issue Type: Improvement >Reporter: Bryan Beaudreault >Priority: Minor > > In my quest to figure out HBASE-27170, I ended up adding ResourceLeakDetector > to RefCnt in my local fork. This immediately reports the leak to the logs, > making it hard to miss. ResourceLeakDetector is already active in the netty > layer, and the default state is designed to be very low overhead. We could > add it directly to RefCnt, or make it further configurable if we're concerned > about performance. Either way it's good to have and document, to aid future > leak investigations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27180) Multiple possible buffer leaks
Norman Maurer created HBASE-27180: - Summary: Multiple possible buffer leaks Key: HBASE-27180 URL: https://issues.apache.org/jira/browse/HBASE-27180 Project: HBase Issue Type: Bug Reporter: Norman Maurer When using ByteBuf you need to be very careful about releasing it as otherwise you might leak data. There are various places in the code-base where such a leak could happen as the buffer is not correctly released -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HBASE-14452) Allow enabling tracing from configuration
[ https://issues.apache.org/jira/browse/HBASE-14452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk resolved HBASE-14452. -- Resolution: Not A Problem OpenTelemetry solves this problem at the process level via Sampler configuration. I think there's nothing additional for us to do. > Allow enabling tracing from configuration > - > > Key: HBASE-14452 > URL: https://issues.apache.org/jira/browse/HBASE-14452 > Project: HBase > Issue Type: Bug > Components: Client, Operability >Reporter: Nick Dimiduk >Priority: Major > > Over on HDFS-8213 [~colinmccabe] convinced me that we should enable operators > to trace HDFS requests independent of applications enabling the same. At the > risk of adding a new, superset configuration, I think we should allow the > same for HBase. Any objections to following HDFS's lead on this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
