[
https://issues.apache.org/jira/browse/HTRACE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649998#comment-14649998
]
Colin Patrick McCabe commented on HTRACE-214:
---------------------------------------------
So, a little more background about this change. The main goal here is to make
it easier to integrate HTrace into more applications without a lot of
boilerplate (like the various SpanReceiverHost cruft we've accumulated in
Hadoop, HBase, Accumlo). Ideally, a simple application should be able to add
HTracing just by implementing an HTraceConfiguration, and calling:
{code}
Tracer tracer = new TracerBuilder().name("MyApp").conf(conf).build();
{code}
Details like closing all the {{SpanReceivers}} when the process exits,
constructing the {{Sampler}} objects, and constructing the {{SpanReceiver}}
objects are all handled just by this simple code.
{{Samplers}} are no longer managed by the application. Instead, they're
managed by the {{Tracer}} object itself. The {{TracerBuilder}} gives the
{{Tracer}} the {{Samplers}} which it was configured to have. When there is a
top-level span, we sample. (Top-level spans are spans that don't occur
underneath any other span.)
So, for example, in this case:
{code}
TraceScope outerScope = tracer.newScope("outerScope");
TraceScope innerScope = tracer.newScope("innerScope");
innerScope.close();
outerScope.close();
{code}
We apply the sampler to {{outerScope}}, but not to {{innerScope}}. The inner
scope will be sampled only if the outer scope was. This is easier for
application writers since they don't have to remember which spans are
underneath which other spans. They don't have to pass around Sampler objects
either.
Applications can still manually add or remove sampler objects if they wish, but
in general it is no longer necessary. Hadoop in particular will want to add,
remove, and list {{Samplers}} to implement its "add tracing at runtime" API.
Similarly with span receivers.
The list of span receivers continues to be global. It is now stored in
{{TracerPool}}. The span receivers are closed either when the process is about
to exit, or when all {{Tracers}} have been closed.
> 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,
> HTRACE-214.003.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)
