[
https://issues.apache.org/jira/browse/HTRACE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643530#comment-14643530
]
Colin Patrick McCabe commented on HTRACE-214:
---------------------------------------------
The biggest win for deglobalization is letting client code and application code
live in harmony. To give a more concrete example, previously we had a bad
situation where if someone configured both an HDFS client span receiver and an
HBase span region server span receiver, we would have "double tracing" -- two
different SpanReceiver objects would be created, and all spans would be sent
twice over. This is because the HDFS client lives in the same process as the
HBase server-- it is a library.
With this change, we no longer have double tracing-- instead, we share
SpanReceivers between different Tracers intelligently. If both Tracers are
configured to use the same span receiver, we only create it once. (On the
other hand, if they are configured to use different span receivers, then we
respect that.)
As we add HTrace to more projects, this will become more and more important.
We don't want having HTrace in project A to be a barrier to adding HTrace in
project B.
This change also moves Sampler objects inside the Tracer objects. Now,
Samplers are managed automatically by the Tracer-- eliminating a lot of sampler
construction and management boilerplate in code which uses HTrace. (However,
there are still Tracer#addSampler and Tracer#removeSampler APIs for
applications that want to make use of them.)
It is nice to have Tracer objects managing Samplers for other reasons as well.
For example, if we decide to implement something like HTRACE-69 in the future,
we will be able to do it without making any changes to client code.
> De-globalize Tracer.java
> ------------------------
>
> Key: HTRACE-214
> URL: https://issues.apache.org/jira/browse/HTRACE-214
> Project: HTrace
> Issue Type: Sub-task
> Affects Versions: 4.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HTRACE-214.001.patch, HTRACE-214.002.patch
>
>
> De-globalize Tracer.java.
> Currently, Tracer is a Singleton managed by TracerHolder. Instead, Tracer
> objects should be created by each process or library that needs to use
> HTrace. This enables a few things:
> * When the Tracer object is created, we can give it a name. Then we can use
> this name in the "process id" of all spans created by that tracer, rather
> than trying to scrape the JVM name using "questionable" methods.
> * SpanReceivers can be shared between multiple Tracer objects in the same
> process. The span receivers are reference counted. This should eliminate
> the "double tracing" issues we have had when tracing client libraries inside
> processes which also want tracing.
> * Tracers can be closed by calling Tracer#close. If the Tracer being closed
> is the last tracer in the process, it will close all the span receivers.
> * We will have a TracerFactory that takes care of the details of creating the
> right span receivers based on the configuration. This removes some
> boilerplate that is currently needed to enable HTrace in an application or
> library. We can also make SpanReceiverFactory package-private since it will
> no longer need to be publicly visible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
