[
https://issues.apache.org/jira/browse/HTRACE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654431#comment-14654431
]
Colin Patrick McCabe commented on HTRACE-214:
---------------------------------------------
bq. Some tests expecting there is no receivers yet failed due to existing
receivers other tests created.
Good point. I think the best way to prevent this problem is to use a custom
{{TracerPool}} in unit tests. That way, each unit test function uses its own
pool of {{Tracer}} objects, and no unit test function interferes with another.
I will change it so each unit test runs in its own {{TracerPool}} rather than
using a global one...
bq. We can close tracers before or after of unit tests otherwise.
Yeah, all the unit tests should close their {{Tracer}} objects. The main
reason why it might not happen is if there is an unexpected exception thrown
inside the test. It will be good to use a separate {{TracerPool}} so that we
don't get multiple test failures when one test fails and doesn't close its
{{Tracer}}.
bq. TracerPool#removeReceiver and TracerPool#removeAndCloseReceiver are not
called from anywhere. We can remove them if we go with the proposed design.
These functions are needed in Hadoop, since we support adding new
{{SpanReceiver}} objects that weren't in the original configuration via
{{TraceAdminProtocol}} RPCs.
> 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)
