htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <>
Subject Re: [VOTE] htrace-3.1.0, the sixth release candidate
Date Fri, 09 Jan 2015 17:15:57 GMT
On Thu, Jan 8, 2015 at 6:29 PM, Nick Dimiduk <> wrote:

> I'm trying out this RC over in HBase code. We've broken API compatibility
> in at least two commits:
> HTRACE-1 changes the SpanReceiver interface. HBase was instantiating
> SpanReceivers itself and calling .configure(HTraceConfiguration) on each
> one. Looks like now the expectation is that SpanReceiver implementations
> provide a constructor that takes a single parameter of HTraceConfiguration.
> HTRACE-16 refactors the TraceTree interface a good bit. The handy
> getRoots() method has been replaced with the less obvious
> getSpansByParent().find(Span.ROOT_SPAN_ID) and .getSpansByParentIdMap() is
> also an invocation of getSpansByParent().find().
> Neither of these changes are a big deal, but none of this code has
> javadocs, so it's not obvious how the contract changed. I had to look at
> diffs and tests to decipher the new usage. This means that a simple
> search/replace is not sufficient for existing users to upgrade.
> For reference, my patch is over on HBASE-12810.
> I don't think this is enough to sink the RC, but my understanding of the
> earlier discussion was that this release would be a simple search/replace
> kind of upgrade. We need to document these idiom changes for folks.

Good stuff Nick. I made HTRACE-62 to add doc on how to migrate. Do we need
to add facility to make the lib easier to use?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message