[
https://issues.apache.org/jira/browse/HBASE-26766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522539#comment-17522539
]
Andrew Kyle Purtell edited comment on HBASE-26766 at 4/14/22 9:55 PM:
----------------------------------------------------------------------
Proposals and patches are to be submitted for 'master' branch first. Changes
might then be backported depending on requirements and whether the change meets
compatibility guidelines. This is unlikely to attract committer attention if
targeting branch-1 first.
Unfortunately beyond that I do not expect there will be much appetite for a
unique and custom framework for "thread attributes". Let's start by noting that
Java already provides generic facilities for associating attributes with
threads, see
[ThreadLocal|https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html].
A custom framework for decorating threads, admittedly with some different
semantics and a notion of inheritance, must provide significant value in
comparison especially for the needs of HBase users and/or developers. Thread
handling is critical and performance sensitive. The bar is fairly high here.
Phoenix represents only a subset of use cases and someone's internal fork is
only a small subset of that subset, so the scope of utility seems fairly small
at this point.
On the topic of request tracing requirements and capabilities, as [~ndimiduk]
has mentioned OpenTelemetry is already integrated into HBase as a framework for
request tracing (in HBASE-26419) and Hadoop (HADOOP-15566) and I will note
Phoenix is also actively integrating OpenTelemetry via PHOENIX-5215.
[~sairampola6] you should perhaps talk with [~kiran.maturi], to whom
PHOENIX-5215 is assigned, on an end to end request tracing solution that meets
your Phoenix request tracing related needs.
was (Author: apurtell):
Proposals and patches are to be submitted for 'master' branch first. Changes
might then be backported depending on requirements and whether the change meets
compatibility guidelines. This is unlikely to attract committer attention if
targeting branch-1 first.
Unfortunately beyond that I do not expect there will be much appetite for a
unique and custom framework for "thread attributes". Phoenix represents only a
subset of use cases and someone's internal fork is only a small subset of that
subset. The bar is fairly high here. This should benefit HBase users and
developers in some way. Java already provides generic facilities for thread
attributes, see
[ThreadLocal|https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html].
A custom framework for "thread attributes" on its own does not provide
significant value in comparison.
On the topic of request tracing requirements and capabilities, as [~ndimiduk]
has mentioned OpenTelemetry is already integrated into HBase as a framework for
request tracing (in HBASE-26419) and Hadoop (HADOOP-15566) and I will note
Phoenix is also actively integrating OpenTelemetry via PHOENIX-5215.
[~sairampola6] you should perhaps talk with [~kiran.maturi], to whom
PHOENIX-5215 is assigned, on an end to end request tracing solution that meets
your Phoenix request tracing related needs.
> Introduce custom attributes to threads
> --------------------------------------
>
> Key: HBASE-26766
> URL: https://issues.apache.org/jira/browse/HBASE-26766
> Project: HBase
> Issue Type: New Feature
> Reporter: Pola Sairam
> Assignee: Pola Sairam
> Priority: Major
> Fix For: 1.7.2
>
>
> The idea is to introduce custom attributes to a thread. We will be passing
> this from thread to newly spawned thread. More details can be found here:
> https://docs.google.com/document/d/1b6CJt7_E8NU5fe41yeZZhuVPx-5SDx7x1jNtIRmnR_g/edit#heading=h.bv19tq8gxgcv
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
