[jira] [Commented] (HTRACE-214) De-globalize Tracer.java

["Colin Patrick McCabe (JIRA)" <ji...@apache.org>]

    [ 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)