[jira] [Created] (HTRACE-377) The HTrace website should include the Apache incubator disclaimer
Colin Patrick McCabe created HTRACE-377: --- Summary: The HTrace website should include the Apache incubator disclaimer Key: HTRACE-377 URL: https://issues.apache.org/jira/browse/HTRACE-377 Project: HTrace Issue Type: Bug Reporter: Colin Patrick McCabe The HTrace website should include the Apache incubator disclaimer. From http://incubator.apache.org/guides/branding.html bq. Apache Podling-Name is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the name of Apache TLP sponsor. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-363) Add tests for newScope with parent id
[ https://issues.apache.org/jira/browse/HTRACE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363093#comment-15363093 ] Colin Patrick McCabe commented on HTRACE-363: - Thanks for the update, [~nisala12]. I attached HTRACE-363.002.patch as a patch file so that people can see what we're commenting on here. Can you please close the trace scopes you're opening in these tests? Keeping the thread-local data around could cause issues with other tests. > Add tests for newScope with parent id > - > > Key: HTRACE-363 > URL: https://issues.apache.org/jira/browse/HTRACE-363 > Project: HTrace > Issue Type: Test > Components: core >Reporter: Mike Drob >Assignee: Nisala Mendis > Attachments: HTRACE-363.002.patch > > > We should add some tests to verify that when there is a currently active > scope and `newScope` is called with a valid parent id that both are included > in the child span. The current code does this correctly, I think, but we > should have tests to prevent accidental regressions in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-363) Add tests for newScope with parent id
[ https://issues.apache.org/jira/browse/HTRACE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-363: Attachment: HTRACE-363.002.patch > Add tests for newScope with parent id > - > > Key: HTRACE-363 > URL: https://issues.apache.org/jira/browse/HTRACE-363 > Project: HTrace > Issue Type: Test > Components: core >Reporter: Mike Drob >Assignee: Nisala Mendis > Attachments: HTRACE-363.002.patch > > > We should add some tests to verify that when there is a currently active > scope and `newScope` is called with a valid parent id that both are included > in the child span. The current code does this correctly, I think, but we > should have tests to prevent accidental regressions in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-376) HTrace should support nanosecond time granularities
[
https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357642#comment-15357642
]
Colin Patrick McCabe commented on HTRACE-376:
-
Hi [~adriancole],
Very interesting discussion as always!
This brings to mind the famous distinction between accuracy and precision that
tends to come up in statistics. We might be able to calculate the expected
value of some random variable to 5 digits right of the decimal point, but if
there is a wide variance in the probability distribution, we can say that our
calculated expected value isn't very precise.
I agree that our software's time measurements certainly becomes imprecise when
we get down to nanoseconds. And displaying that value with high accuracy could
be misleading. However, I think nanoseconds is still the way to go, for a few
reasons:
* Some systems are more precise than others. For example, some PC systems are
configured to use the high-resolution timer (the HPET hardware) rather than the
TSC hardware. Those systems will have more accuracy. If we artificially limit
accuracy, we won't serve the more precise systems well. We don't really know
what the limits of accuracy are, and we especially don't know what the accuracy
limits of future systems might be.
* A lot of times, people want to know about durations rather than absolute
times. For example, [~pranavanc5e] is probably hoping to get some insight into
things happening on a single node in Phoenix. For this purpose, it doesn't
matter if the call to get the time has a fixed overhead. Since both the start
and end time are shifted forward, the duration will still be in the ballpark.
* People should be collecting a lot of trace data which should allow them to
look at the variance in different values for the same span. People should also
be exercising common sense and not reading too much into the duration
difference between a 500 ns span and a 501 ns span.
* People are not used to thinking in terms of microseconds because APIs tend to
be in milliseconds or nanoseconds.
bq. Moreover, eventhough unix can report time in microseconds using the
presumably cheaper gettimeofday, it cannot in nanos.
Hmm. I haven't seen anything suggesting {{gettimeofday}} is cheaper than
{{clock_gettime}}. I thought they were both implemented via the VDSO hack on
Linux, so their performance should be the same? At least on my system, the man
page for {{gettimeofday}} says that's obsolete and {{clock_gettime}} should be
used.
> HTrace should support nanosecond time granularities
> ---
>
> Key: HTRACE-376
> URL: https://issues.apache.org/jira/browse/HTRACE-376
> Project: HTrace
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.1.0
>Reporter: Colin Patrick McCabe
>Assignee: Colin Patrick McCabe
> Attachments: HTRACE-376.001.patch, HTRACE-376.002.patch,
> HTRACE-376.003.patch
>
>
> HTrace should support nanosecond time granularities. Currently only a
> granularity of milliseconds is supported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-376) HTrace should support nanosecond time granularities
[ https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15349841#comment-15349841 ] Colin Patrick McCabe commented on HTRACE-376: - Thanks [~pranavanc5e]. And [~fabbri], [~saint@gmail.com], [~abec], take a look at my patch if you get a chance. We talked about doing nanotime in the past-- I think this is a great way to do it > HTrace should support nanosecond time granularities > --- > > Key: HTRACE-376 > URL: https://issues.apache.org/jira/browse/HTRACE-376 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 3.1.0 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe > Attachments: HTRACE-376.001.patch, HTRACE-376.002.patch, > HTRACE-376.003.patch > > > HTrace should support nanosecond time granularities. Currently only a > granularity of milliseconds is supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-376) HTrace should support nanosecond time granularities
[
https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15342898#comment-15342898
]
Colin Patrick McCabe commented on HTRACE-376:
-
So, there's a bunch of fairly complicated issues here. I posted a patch which
I think addresses them all.
First of all, like I said, we can't "cheat" and use times that are only
meaningful on a single node. If node1 says an event happened at time 1, and
node2 says another event happened at time 1000, we should be able to assume
that there were 999 time units in between them. This rules out using
{{System.nanoTime}} directly, as I've mentioned several times. It is a
system-local time, and we need a global time. Unfortunately, Java doesn't
offer any API to get a wall-clock time with nanosecond granularity.
There will be better time APIs coming out in future JVM versions. Until then,
as a workaround, we can try to correlate the monotonic clock with the wall
clock, and get a wall-clock nanosecond estimate out of that. The code I posted
uses {{NanoTimeTimeSource}} to do that.
Secondly, there shouldn't be any need to store times in both milliseconds and
nanoseconds. If we put nanoseconds since the epoch into a long, we still have
(2^63) / (10^9 * 60 * 24 * 365) = 17548 years of post-1970 time which we can
cover. I'm OK with the HTrace project lasting for "only" 17,000 years.
Overwriting the time in milliseconds should also set the time in nanoseconds,
and vice versa.
We need to change the Span JSON to support nanoseconds. I have done this by
adding the 'E' and 'B' (i.e. capital letter) fields in addition to the 'b' and
'e' fields. Also, we need nanosecond granularity for span time annotations as
well as spans.
Finally, we need some way of choosing to use millisecond granularity versus
nanosecond granularity. The code does this by looking at the configuration key
{{time.granularity}}, which can be either {{ns}} for nanoseconds or {{ms} for
milliseconds. This determines which {{TimeSource}} we use when creating spans.
bq. Nano time call is pretty expensive because it will take like 100+ cpu clock
cycles whereas System.currentMillis() will just take 5 or 6 cpu clock cycles.
Nanotime is an expensive operation. (In my opinion calling nanotime is a
barrier for performance)
That is true only on Windows, not on Linux. There are some relevant answers on
Stack Overflow you could look at. In any case, this will be configurable and
the default will be milliseconds.
> HTrace should support nanosecond time granularities
> ---
>
> Key: HTRACE-376
> URL: https://issues.apache.org/jira/browse/HTRACE-376
> Project: HTrace
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.1.0
>Reporter: Colin Patrick McCabe
>Assignee: Pranavan
> Attachments: HTRACE-376.001.patch, HTRACE-376.002.patch,
> HTRACE-376.003.patch
>
>
> HTrace should support nanosecond time granularities. Currently only a
> granularity of milliseconds is supported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HTRACE-376) HTrace should support nanosecond time granularities
[ https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-376: Attachment: (was: HTRACE-376.003.patch) > HTrace should support nanosecond time granularities > --- > > Key: HTRACE-376 > URL: https://issues.apache.org/jira/browse/HTRACE-376 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 3.1.0 >Reporter: Colin Patrick McCabe >Assignee: Pranavan > Attachments: HTRACE-376.001.patch, HTRACE-376.002.patch, > HTRACE-376.003.patch > > > HTrace should support nanosecond time granularities. Currently only a > granularity of milliseconds is supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-376) HTrace should support nanosecond time granularities
[ https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15338293#comment-15338293 ] Colin Patrick McCabe commented on HTRACE-376: - Hi [~pranavanc5e], Thanks for working on this. Can you please combine these changes into a single patch that I can review? (Assuming you want to make the changes as a single commit rather than multiple). Unfortunately, it is not going to be possible for people to follow the discussion here on JIRA if the change history gets erased each time you re-push the branch. That's one reason I still prefer attaching numbered patch files. It's easy and we know exactly what is being reviewed. If you want to keep using github only, then kindly provide links to specific commits so that people can understand what patch each set of comments is referencing. Thanks! > HTrace should support nanosecond time granularities > --- > > Key: HTRACE-376 > URL: https://issues.apache.org/jira/browse/HTRACE-376 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 3.1.0 >Reporter: Colin Patrick McCabe >Assignee: Pranavan > Attachments: HTRACE-376.001.patch > > > HTrace should support nanosecond time granularities. Currently only a > granularity of milliseconds is supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-376) HTrace should support nanosecond time granularities
[
https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15334321#comment-15334321
]
Colin Patrick McCabe commented on HTRACE-376:
-
Thanks for looking at this.
{code}
+ begin(System.currentTimeMillis(),System.nanoTime()).
{code}
If you read the documentation of {{System#nanoTime}} here
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime() ,
it says that "This method can only be used to measure elapsed time and is not
related to any other notion of system or wall-clock time." Since HTrace uses
wall-clock time in its span times, nanotime is not suitable for us. We also do
not want to be fetching the time twice each time we create a span. There is a
cost associated with this. Once is enough.
{code}
-public Builder begin(long begin) {
+public Builder begin(long begin, long beginNano) {
{code}
{{MilliSpan#Builder#begin}} is a public function which is part of the API. It
can't be changed in the htrace 4.x line. You will need to add a new function
to preserve backwards compatibility.
We also need to add the nanoTimes to the Span JSON, both on the JSON parsing
and JSON emitting side.
> HTrace should support nanosecond time granularities
> ---
>
> Key: HTRACE-376
> URL: https://issues.apache.org/jira/browse/HTRACE-376
> Project: HTrace
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.1.0
>Reporter: Colin Patrick McCabe
>Assignee: Pranavan
> Attachments: HTRACE-376.001.patch
>
>
> HTrace should support nanosecond time granularities. Currently only a
> granularity of milliseconds is supported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HTRACE-376) HTrace should support nanosecond time granularities
[ https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-376: Attachment: HTRACE-376.001.patch > HTrace should support nanosecond time granularities > --- > > Key: HTRACE-376 > URL: https://issues.apache.org/jira/browse/HTRACE-376 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 3.1.0 >Reporter: Colin Patrick McCabe >Assignee: Pranavan > Attachments: HTRACE-376.001.patch > > > HTrace should support nanosecond time granularities. Currently only a > granularity of milliseconds is supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-376) HTrace should support nanosecond time granularities
[ https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-376: Attachment: (was: HTRACE-362.001.patch) > HTrace should support nanosecond time granularities > --- > > Key: HTRACE-376 > URL: https://issues.apache.org/jira/browse/HTRACE-376 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 3.1.0 >Reporter: Colin Patrick McCabe >Assignee: Pranavan > Attachments: HTRACE-376.001.patch > > > HTrace should support nanosecond time granularities. Currently only a > granularity of milliseconds is supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-376) HTrace should support nanosecond time granularities
[ https://issues.apache.org/jira/browse/HTRACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-376: Attachment: HTRACE-362.001.patch > HTrace should support nanosecond time granularities > --- > > Key: HTRACE-376 > URL: https://issues.apache.org/jira/browse/HTRACE-376 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 3.1.0 >Reporter: Colin Patrick McCabe >Assignee: Pranavan > Attachments: HTRACE-376.001.patch > > > HTrace should support nanosecond time granularities. Currently only a > granularity of milliseconds is supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-363) Add tests for newScope with parent id
[ https://issues.apache.org/jira/browse/HTRACE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-363: Assignee: Nisala Mendis > Add tests for newScope with parent id > - > > Key: HTRACE-363 > URL: https://issues.apache.org/jira/browse/HTRACE-363 > Project: HTrace > Issue Type: Test > Components: core >Reporter: Mike Drob >Assignee: Nisala Mendis > > We should add some tests to verify that when there is a currently active > scope and `newScope` is called with a valid parent id that both are included > in the child span. The current code does this correctly, I think, but we > should have tests to prevent accidental regressions in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-373) Add markdown docs for config keys
[ https://issues.apache.org/jira/browse/HTRACE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-373. - Resolution: Fixed Fix Version/s: 4.2 Committed to 4.2. Thanks, [~lewismc]. > Add markdown docs for config keys > - > > Key: HTRACE-373 > URL: https://issues.apache.org/jira/browse/HTRACE-373 > Project: HTrace > Issue Type: New Feature > Components: docs >Reporter: Colin Patrick McCabe >Assignee: Lewis John McGibbney > Fix For: 4.2 > > Attachments: HTRACE-373.patch, HTRACE-373.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-362) Apache KUDU Span receiver implementation for Apache HTrace
[
https://issues.apache.org/jira/browse/HTRACE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333197#comment-15333197
]
Colin Patrick McCabe commented on HTRACE-362:
-
Thanks for posting this, [~nisala12]! Very encouraging!
It's more traditional to attach a patch to the JIRA than to use a reference to
an external site. We can certainly do either one, but it makes it hard to
refer to specific versions of patches when you just link to a branch which
changes over time. I attached the code that is there now to the JIRA as
HTRACE-362.001.patch to make it easier for others to review this specific
version. One tip is that in github, you can get the patch version of a branch
by doing something like this:
{{wget
https://github.com/nisalanirmana/incubator-htrace/commit/6752709e6d078465f55f88233ec3357328aa6d1e.patch}}
(notice the ".patch" at the end).
{code}
+
+htrace
+org.apache.htrace
+4.1.0-incubating-SNAPSHOT
+..
+
{code}
Version 4.1 of HTrace has already been released. This should be version
4.2.0-incubating-SNAPSHOT.
{code}
+
+UTF-8
+1.0.0-SNAPSHOT
+2.6.0-cdh5.4.7
+true
+
{code}
It's good that you are using UTF8. However, a few questions:
* I don't see why Hadoop is needed here? Kudu is a separate project from
Hadoop; it's client doesn't depend on Hadoop as far as I know.
* Has Kudu published a non-snapshot version of its client library? We
generally should not be depending on SNAPSHOT versions of things in Maven if we
can help it, since it makes for non-repeatable builds.
{code}
+
+
+ cdh.repo
+ Cloudera Repositories
+ https://repository.cloudera.com/artifactory/cloudera-repos
+
+false
+
+
+
{code}
Shouldn't Kudu be available from Apache repos at this point? We generally do
not include vendor repos in upstream projects.
I can see that you are manually serializing the span fields to protobuf and
then storing it in Kudu. However, this approach discards all the benefits of
Kudu's knowledge about types and columnar in-memory data optimizations.
Instead of storing everything as a binary blob, you should store it by setting
up an appropriate schema in Kudu. Another benefit is that by using Kudu's own
type system, you will also not need to drag in all the protobuf dependencies.
{{KuduHTraceConfiguration.java}}: I don't see any point to this file. The way
we configure HTrace is determined by the system we're integrating with, not the
span receiver we are using. Span Receivers are very specifically isolated from
configuration details.
{{KuduClientConfiguration.java}}: why is this class mutable? These fields
should be {{final}} since we don't plan on changing them after the
{{SpanReceiver}} is constructed. Otherwise we have to worry about what could
happen if someone changes these fields later.
{code}
+ public KuduClient buildClient() {
+KuduClientBuilder builder = new KuduClient
+.KuduClientBuilder(host.concat(":").concat(port));
+if (Integer.valueOf(workerCount) != null) {
+ builder.workerCount(workerCount);
+}
+if (Integer.valueOf(bossCount) != null) {
+ builder.bossCount(bossCount);
+}
+if (!Boolean.valueOf(isStatisticsEnabled)) {
+ builder.disableStatistics();
+}
+if (Long.valueOf(adminOperationTimeout) != null) {
+ builder.defaultAdminOperationTimeoutMs(adminOperationTimeout);
+}
+if (Long.valueOf(operationTimeout) != null) {
+ builder.defaultOperationTimeoutMs(operationTimeout);
+}
+if (Long.valueOf(socketReadTimeout) != null) {
{code}
{{valueOf}} a primitive integer or long will never be {{null}}, so these checks
don't accomplish anything. It seems like perhaps the intention here was to
avoid explicitly setting these quantities unless they were explicitly
configured, which is a nice goal. It would allow Kudu's own defaults to be
honored when the user had no preferences. However, the code is not
accomplishing this at the moment. Suggest storing the elements as boxed
integers and longs if it is important that they be nullable.
{{KuduConstants.java}}: I don't know if "KuduCinstants" is a good name for this
file since that suggests something internal to kudu, not to our span receiver.
{code}
+ public static final String KUDU_MASTER_HOST_KEY = "htrace.kudu.master.host";
+ public static final String DEFAULT_KUDU_MASTER_HOST = "127.0.0.1";
...
{code}
One minor thing here: The typical pattern is {{KUDU_MASTER_HOST_KEY}} /
{{KUDU_MASTER_HOST_KEY_DEFAULT}}
One not-so-minor thing: configuration keys accepted by span receivers should
not start with "htrace." The configuration objects used by end-users (such as
the Hadoop one) strip off prefixes like "htrace." before passing them to the
span receiver.
> Apache KUDU Span receiver implementation for Apache HTrace
>
[jira] [Updated] (HTRACE-362) Apache KUDU Span receiver implementation for Apache HTrace
[ https://issues.apache.org/jira/browse/HTRACE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-362: Attachment: HTRACE-362.001.patch > Apache KUDU Span receiver implementation for Apache HTrace > -- > > Key: HTRACE-362 > URL: https://issues.apache.org/jira/browse/HTRACE-362 > Project: HTrace > Issue Type: Bug >Reporter: Nisala Mendis >Assignee: Nisala Mendis > Attachments: HTRACE-362.001.patch, kudu_span_receiver_basic_design.pdf > > > Implementation should be carried two components as span receiver that writes > kudu back end and span viewer to view written span/traces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-376) HTrace should support nanosecond time granularities
Colin Patrick McCabe created HTRACE-376: --- Summary: HTrace should support nanosecond time granularities Key: HTRACE-376 URL: https://issues.apache.org/jira/browse/HTRACE-376 Project: HTrace Issue Type: Improvement Components: core Affects Versions: 3.1.0 Reporter: Colin Patrick McCabe HTrace should support nanosecond time granularities. Currently only a granularity of milliseconds is supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-362) Apache KUDU Span receiver implementation for Apache HTrace
[ https://issues.apache.org/jira/browse/HTRACE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327988#comment-15327988 ] Colin Patrick McCabe commented on HTRACE-362: - There is some work on this here: https://github.com/nisalanirmana/incubator-htrace/commits/GSOC_HTRACE > Apache KUDU Span receiver implementation for Apache HTrace > -- > > Key: HTRACE-362 > URL: https://issues.apache.org/jira/browse/HTRACE-362 > Project: HTrace > Issue Type: Bug >Reporter: Nisala Mendis >Assignee: Nisala Mendis > Attachments: kudu_span_receiver_basic_design.pdf > > > Implementation should be carried two components as span receiver that writes > kudu back end and span viewer to view written span/traces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-370) htrace-hbase: fix jdk8 javadoc build error
[ https://issues.apache.org/jira/browse/HTRACE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295808#comment-15295808 ] Colin Patrick McCabe commented on HTRACE-370: - +1. Thanks, [~nisala12] and [~iwasakims]. > htrace-hbase: fix jdk8 javadoc build error > -- > > Key: HTRACE-370 > URL: https://issues.apache.org/jira/browse/HTRACE-370 > Project: HTrace > Issue Type: Bug > Components: docs >Affects Versions: 4.0 >Reporter: Colin Patrick McCabe >Priority: Minor > Fix For: 4.2 > > > htrace-hbase: fix jdk8 javadoc build error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-370) htrace-hbase: fix jdk8 javadoc build error
[ https://issues.apache.org/jira/browse/HTRACE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-370. - Resolution: Fixed Assignee: Nisala Mendis Fix Version/s: 4.2 > htrace-hbase: fix jdk8 javadoc build error > -- > > Key: HTRACE-370 > URL: https://issues.apache.org/jira/browse/HTRACE-370 > Project: HTrace > Issue Type: Bug > Components: docs >Affects Versions: 4.0 >Reporter: Colin Patrick McCabe >Assignee: Nisala Mendis >Priority: Minor > Fix For: 4.2 > > > htrace-hbase: fix jdk8 javadoc build error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-375) LocalFileSpanReceiver should create file if local.file.span.receiver.path points to directory
[ https://issues.apache.org/jira/browse/HTRACE-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15293857#comment-15293857 ] Colin Patrick McCabe commented on HTRACE-375: - I thought this created the file if it didn't exist. I have to look into this > LocalFileSpanReceiver should create file if local.file.span.receiver.path > points to directory > - > > Key: HTRACE-375 > URL: https://issues.apache.org/jira/browse/HTRACE-375 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 4.1 >Reporter: Lewis John McGibbney >Assignee: Lewis John McGibbney > > Right now the property local.file.span.receiver.path actually requires a file > on disk to be present in order for spans to be written there once the span > buffer is full. > Either > * the property should be changed to local.file.span.receiver.file.path > indicating that an actual FILE at a patch is required, or > * alternatively (probably my preferred option) if a path is given e.g. > /data/htrace/spans, then the file htrace.log is created and spans are written > there. Just like log4j does with the daily rolling file appender, after > 24hrs, the file will be moved to a timestamped file and a new htrace.log will > be created and written to. > What do you all think? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-373) Add markdown docs for config keys
[ https://issues.apache.org/jira/browse/HTRACE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15293834#comment-15293834 ] Colin Patrick McCabe commented on HTRACE-373: - Thanks, [~lewismc]. This is great. bq. ##Configuration Key Should be "Keys" bq. | htraced.dropped.spans.log.max.size | 1024L * 1024L | The Maximum size of a span log file on disk | no | single integer | Maybe add "maximum size in bytes" to clarify that it's in bytes +1 once these are fixed > Add markdown docs for config keys > - > > Key: HTRACE-373 > URL: https://issues.apache.org/jira/browse/HTRACE-373 > Project: HTrace > Issue Type: New Feature > Components: docs >Reporter: Colin Patrick McCabe >Assignee: Lewis John McGibbney > Attachments: HTRACE-373.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-374) Add markdown documentation about htraced span receiver
Colin Patrick McCabe created HTRACE-374: --- Summary: Add markdown documentation about htraced span receiver Key: HTRACE-374 URL: https://issues.apache.org/jira/browse/HTRACE-374 Project: HTrace Issue Type: New Feature Components: docs Reporter: Colin Patrick McCabe -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-373) Add markdown docs for config keys
Colin Patrick McCabe created HTRACE-373: --- Summary: Add markdown docs for config keys Key: HTRACE-373 URL: https://issues.apache.org/jira/browse/HTRACE-373 Project: HTrace Issue Type: New Feature Components: docs Reporter: Colin Patrick McCabe -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-363) Add tests for newScope with parent id
[
https://issues.apache.org/jira/browse/HTRACE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281750#comment-15281750
]
Colin Patrick McCabe commented on HTRACE-363:
-
Thanks, [~nisala12].
{code}
+Assert.assertNotNull(childScope);
+Assert.assertEquals(childScope.getSpan().getParents().length, 2);
+Assert.assertEquals(childScope.getSpan().getParents()[1].getHigh(), 100L);
+Assert.assertEquals(childScope.getSpan().getParents()[1].getLow(), 200L);
{code}
Hmm. I don't think we should assume that we know which order the parents will
appear in the parents array. Maybe sort the array first?
> Add tests for newScope with parent id
> -
>
> Key: HTRACE-363
> URL: https://issues.apache.org/jira/browse/HTRACE-363
> Project: HTrace
> Issue Type: Test
> Components: core
>Reporter: Mike Drob
>
> We should add some tests to verify that when there is a currently active
> scope and `newScope` is called with a valid parent id that both are included
> in the child span. The current code does this correctly, I think, but we
> should have tests to prevent accidental regressions in the future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-362) Apache KUDU Span receiver implementation for Apache HTrace
[ https://issues.apache.org/jira/browse/HTRACE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280526#comment-15280526 ] Colin Patrick McCabe commented on HTRACE-362: - bq. The only snag here is that Kudu doesn't currently have a pure C API, only C+, and wrapping C+ is typically a bit harder (though doable). I'm a bit surprised that there isn't a C API yet since that's typically how people do Python, Ruby, Lua, etc. etc. bindings. However, you can use SWIG to wrap C\+\+ in Go. http://www.swig.org/Doc2.0/Go.html bq. Some kind of small daemon in java or C++ which speaks thrift or grpc and asks as a "proxy" to Kudu might be the easiest bet in terms of connecting from go, even though it's one more moving piece. If you are going to write a new daemon, you might as well go with solution #2, where you just have a new standalone web server. You could probably go with Java for this piece. The number of concurrent connections to the web server will not be high. bq. Or, a small C library which you can embed in Go, and internally is implemented on top of the C++ kudu client, should work pretty well too. A lot of projects find it difficult or impossible to actually have a stable C\+\+ ABI. It's very easy to end up with two different C\+\+ library versions that look compatible but which crash when you use code linked against one with code linked against another. I think an external C library would have the same problems. However, implementing a C API in Kudu could be one way to go. > Apache KUDU Span receiver implementation for Apache HTrace > -- > > Key: HTRACE-362 > URL: https://issues.apache.org/jira/browse/HTRACE-362 > Project: HTrace > Issue Type: Bug >Reporter: Nisala Mendis >Assignee: Nisala Mendis > Attachments: kudu_span_receiver_basic_design.pdf > > > Implementation should be carried two components as span receiver that writes > kudu back end and span viewer to view written span/traces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-273) Add or change default package name of span reciever
[
https://issues.apache.org/jira/browse/HTRACE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe resolved HTRACE-273.
-
Resolution: Won't Fix
Like I said above, I'm concerned that changing this behavior could cause
serious compatibility problems in a scenario where the 3.x jars are on the
CLASSPATH. Let's close this out for now unless we can think of a safer way of
doing it.
> Add or change default package name of span reciever
> ---
>
> Key: HTRACE-273
> URL: https://issues.apache.org/jira/browse/HTRACE-273
> Project: HTrace
> Issue Type: Bug
> Components: core
>Reporter: Masatake Iwasaki
>Assignee: Masatake Iwasaki
> Attachments: HTRACE-273.001.patch
>
>
> If the package name of span receiver is ommitted, {{org.apache.htrace.core}}
> is used as default but only receivers for testing purpose are in the package.
> Practical span receiver implementations are in {{org.apache.htrace.impl}} now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HTRACE-56) Add bootstrap font files
[ https://issues.apache.org/jira/browse/HTRACE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-56. Resolution: Won't Fix Let's reopen this later if we have more interest in doing this. > Add bootstrap font files > > > Key: HTRACE-56 > URL: https://issues.apache.org/jira/browse/HTRACE-56 > Project: HTrace > Issue Type: Task >Reporter: Abraham Elmahrek > > The HTrace font files were left out so that compilation would be quick. When > compilation time problems have been fixed, the font files can be added back > in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-362) Apache KUDU Span receiver implementation for Apache HTrace
[ https://issues.apache.org/jira/browse/HTRACE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278897#comment-15278897 ] Colin Patrick McCabe commented on HTRACE-362: - Thanks, [~nisala12]. I think Kudu will be great as an HTrace span receiver. I think the most difficult part of this project will be hooking up the existing HTrace web UI to the new Kudu-based span receiver. I can see at least two ways of doing that: 1. Add some code to htraced to allow it to store and retrieve data from Kudu. 2. Create a new standalone web server in htrace-kudu which can talk to Kudu. 3. Integrate the htrace web UI into Kudu itself. The first approach would require htraced to wrap the C APIs of Kudu. It shouldn't be too hard to do this from Go, since Go has a pretty good foreign function interface (FFI) for C. The second approach might require us to run something like a Tomcat or Jetty web server. This web server would have to implement the same REST API as htraced, so that we could use the same Javascript code for both. Alternately, we could serve slightly different Javascript, but that would be complex and somewhat difficult to maintain, I think. I don't think the third approach is that practical. Kudu is a separate project and this user interface logically belongs to HTrace, not to Kudu. > Apache KUDU Span receiver implementation for Apache HTrace > -- > > Key: HTRACE-362 > URL: https://issues.apache.org/jira/browse/HTRACE-362 > Project: HTrace > Issue Type: Bug >Reporter: Nisala Mendis >Assignee: Nisala Mendis > Attachments: kudu_span_receiver_basic_design.pdf > > > Implementation should be carried two components as span receiver that writes > kudu back end and span viewer to view written span/traces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-370) htrace-hbase: fix jdk8 javadoc build error
[ https://issues.apache.org/jira/browse/HTRACE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278871#comment-15278871 ] Colin Patrick McCabe commented on HTRACE-370: - It's frustrating that SpanProtos.java is a generated file. I wonder if we could re-generate it with fixed javadoc? Or perhaps do a suppression of linting for the whole file? > htrace-hbase: fix jdk8 javadoc build error > -- > > Key: HTRACE-370 > URL: https://issues.apache.org/jira/browse/HTRACE-370 > Project: HTrace > Issue Type: Bug > Components: docs >Affects Versions: 4.0 >Reporter: Colin Patrick McCabe >Priority: Minor > > htrace-hbase: fix jdk8 javadoc build error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-370) htrace-hbase: fix jdk8 javadoc build error
[
https://issues.apache.org/jira/browse/HTRACE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278869#comment-15278869
]
Colin Patrick McCabe commented on HTRACE-370:
-
Building {{mvn javadoc:javadoc}} under jdk8 without the {{\-Xdoclint:none}}
option, I get lots of errors from {{SpanProtos.java}}:
{code}
88 warnings
[WARNING] Javadoc Warnings
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:633:
warning: no @return
[WARNING] boolean hasTraceId();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:637:
warning: no @return
[WARNING] long getTraceId();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:643:
warning: no @return
[WARNING] boolean hasParentId();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:647:
warning: no @return
[WARNING] long getParentId();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:653:
warning: no @return
[WARNING] boolean hasStart();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:657:
warning: no @return
[WARNING] long getStart();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:663:
warning: no @return
[WARNING] boolean hasStop();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:667:
warning: no @return
[WARNING] long getStop();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:673:
warning: no @return
[WARNING] boolean hasSpanId();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:677:
warning: no @return
[WARNING] long getSpanId();
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-hbase/src/main/java/org/apache/htrace/protobuf/generated/SpanProtos.java:683:
warning: no @return
[WARNING] boolean hasProcessId();
...
{code}
> htrace-hbase: fix jdk8 javadoc build error
> --
>
> Key: HTRACE-370
> URL: https://issues.apache.org/jira/browse/HTRACE-370
> Project: HTrace
> Issue Type: Bug
> Components: docs
>Affects Versions: 4.0
>Reporter: Colin Patrick McCabe
>Priority: Minor
>
> htrace-hbase: fix jdk8 javadoc build error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HTRACE-372) htrace4-core: fix new jdk8 javadoc build errors
Colin Patrick McCabe created HTRACE-372:
---
Summary: htrace4-core: fix new jdk8 javadoc build errors
Key: HTRACE-372
URL: https://issues.apache.org/jira/browse/HTRACE-372
Project: HTrace
Issue Type: Bug
Components: docs
Affects Versions: 4.2
Reporter: Colin Patrick McCabe
It seems like we've accumulated some new jdk8 javadoc build errors:
{code}
5 warnings
[WARNING] Javadoc Warnings
[WARNING]
/home/cmccabe/htrace1/htrace-core4/src/main/java/org/apache/htrace/core/Span.java:94:
warning: no @param for description
[WARNING] Span child(String description);
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-core4/src/main/java/org/apache/htrace/core/TraceRunnable.java:32:
warning: no @param for tracer
[WARNING] public TraceRunnable(Tracer tracer, TraceScope parent,
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-core4/src/main/java/org/apache/htrace/core/TraceRunnable.java:32:
warning: no @param for parent
[WARNING] public TraceRunnable(Tracer tracer, TraceScope parent,
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-core4/src/main/java/org/apache/htrace/core/TraceRunnable.java:32:
warning: no @param for runnable
[WARNING] public TraceRunnable(Tracer tracer, TraceScope parent,
[WARNING] ^
[WARNING]
/home/cmccabe/htrace1/htrace-core4/src/main/java/org/apache/htrace/core/TraceRunnable.java:32:
warning: no @param for description
[WARNING] public TraceRunnable(Tracer tracer, TraceScope parent,
[WARNING] ^
{code}
It seems like we need to start doing a javadoc build as part of our Jenkins
post-commit job.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-371) Fix build failure of htraced due to link flags on go 1.4
[ https://issues.apache.org/jira/browse/HTRACE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274920#comment-15274920 ] Colin Patrick McCabe commented on HTRACE-371: - Fair enough. If you want to revert HTRACE-361, that's fine with me. We can wait for a "must-have-feature" to make upgrading go mandatory. We should probably print the version of go somewhere in gobuild.sh, to make diagnosing problems like this easier in the future. > Fix build failure of htraced due to link flags on go 1.4 > > > Key: HTRACE-371 > URL: https://issues.apache.org/jira/browse/HTRACE-371 > Project: HTrace > Issue Type: Bug > Components: build, htraced >Affects Versions: 4.2 >Reporter: Masatake Iwasaki > > Build of htraced fails on go 1.4 after HTRACE-361 which replaced link flags > from "-X name value" to "-X name=value". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-358) Provide convenience wrapper around ScheduledExecutorService
[
https://issues.apache.org/jira/browse/HTRACE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274624#comment-15274624
]
Colin Patrick McCabe commented on HTRACE-358:
-
bq. If we did this, we'd end up implementing the same `wrap` methods twice in
`TraceExecutorService` and `ScheduledTraceExecutorService` and I don't think
that will lead to sustainable code in the future.
I was envisioning doing without this method, and just calling the Tracer#wrap
method directly. However, if you feel that would be too unwieldy, go ahead and
leave the wrap methods in there, as long as they are package-private. We can
always change it later.
bq. Do protected methods show up in the public API? I was unaware of this
previously, but have no problems with doing package-private instead.
The class isn't final, so anyone can subclass it and start depending on these
protected methods. Remember, you should be looking at developers as
adversaries who will try as hard as possible to write code that breaks on a
library version change. And we have to prevent that breakage.
> Provide convenience wrapper around ScheduledExecutorService
> ---
>
> Key: HTRACE-358
> URL: https://issues.apache.org/jira/browse/HTRACE-358
> Project: HTrace
> Issue Type: Improvement
> Components: core
>Affects Versions: 4.1
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-358.patch.txt
>
>
> We already provide a convenience wrapper around {{ExecutorService}}, it would
> not be onerous to also provide a wrapper around {{ScheduledExecutorService}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-371) Fix build failure of htraced due to link flags on go 1.4
[ https://issues.apache.org/jira/browse/HTRACE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273371#comment-15273371 ] Colin Patrick McCabe commented on HTRACE-371: - Good find, [~iwasakims]. Maybe we should fix the build to complain if the version of Go is too old? There is really no reason to be using Go 1.4 any more now. The stable version is 1.6 now, and it generates much faster binaries, from what I've read. There's been a lot of GC improvements as well. Unlike with Java, where end-users have to go through a painful JVM upgrade process, with Go our end-users just run a binary. So we can use any version of Go we want, and they don't have to install anything new. What do you guys think? > Fix build failure of htraced due to link flags on go 1.4 > > > Key: HTRACE-371 > URL: https://issues.apache.org/jira/browse/HTRACE-371 > Project: HTrace > Issue Type: Bug > Components: build, htraced >Affects Versions: 4.2 >Reporter: Masatake Iwasaki > > Build of htraced fails on go 1.4 after HTRACE-361 which replaced link flags > from "-X name value" to "-X name=value". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-370) htrace-hbase: fix jdk8 javadoc build error
Colin Patrick McCabe created HTRACE-370: --- Summary: htrace-hbase: fix jdk8 javadoc build error Key: HTRACE-370 URL: https://issues.apache.org/jira/browse/HTRACE-370 Project: HTrace Issue Type: Bug Components: docs Affects Versions: 4.0 Reporter: Colin Patrick McCabe Priority: Minor htrace-hbase: fix jdk8 javadoc build error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-369) htrace-zipkin: fix jdk8 javadoc build error
Colin Patrick McCabe created HTRACE-369: --- Summary: htrace-zipkin: fix jdk8 javadoc build error Key: HTRACE-369 URL: https://issues.apache.org/jira/browse/HTRACE-369 Project: HTrace Issue Type: Bug Components: docs Affects Versions: 4.0 Reporter: Colin Patrick McCabe Priority: Minor htrace-zipkin: fix jdk8 javadoc build error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-368) Cannot build Javadoc with JDK1.8.X
[
https://issues.apache.org/jira/browse/HTRACE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273288#comment-15273288
]
Colin Patrick McCabe commented on HTRACE-368:
-
Thanks for the update. Fixing the javadoc for those subprojects could be a
good newbie jira...
> Cannot build Javadoc with JDK1.8.X
> --
>
> Key: HTRACE-368
> URL: https://issues.apache.org/jira/browse/HTRACE-368
> Project: HTrace
> Issue Type: Improvement
> Components: build, docs
>Affects Versions: 4.1
>Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Minor
> Attachments: HTRACE-368.patch, help-doc.html
>
>
> Right now if I attempt to build Javadoc in master branch with following JDK I
> get a hellish error which indicates Javadoc in HTrace Java source needs some
> attention.
> {code}
> lmcgibbn@LMC-032857 /usr/local/incubator-htrace(master) $ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T04:57:37-07:00)
> Maven home: /usr/local/apache-maven-3.3.3
> Java version: 1.8.0_66, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
> {code}
> For the interim I propose to submit a profile which would allow us to work
> around the Javadoc issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-367) Publish Aggrgate Javadocs
[ https://issues.apache.org/jira/browse/HTRACE-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273287#comment-15273287 ] Colin Patrick McCabe commented on HTRACE-367: - These are good points. We should post the full javadoc as soon as it's building cleanly under JDK8. The reason why we didn't do it earlier is just that the core javadoc is the most important one and there was a lot of other stuff to do. > Publish Aggrgate Javadocs > - > > Key: HTRACE-367 > URL: https://issues.apache.org/jira/browse/HTRACE-367 > Project: HTrace > Issue Type: Improvement > Components: docs >Reporter: Lewis John McGibbney >Priority: Minor > > Right now, one is required to download source and manually build the full > Javadoc e.g. mvn javadoc;aggregate in order to see aggregate, full Javadoc > for HTrace. > We should simply provide this over on > http://htrace.incubator.apache.org/#javadoc > Can someone please generate the full Javadoc and commit it to SVN r wherever > the HTrace site is published from? Thanks in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-358) Provide convenience wrapper around ScheduledExecutorService
[
https://issues.apache.org/jira/browse/HTRACE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273278#comment-15273278
]
Colin Patrick McCabe commented on HTRACE-358:
-
Also, let's have some javadoc for the new class
thanks, [~mdrob]!
> Provide convenience wrapper around ScheduledExecutorService
> ---
>
> Key: HTRACE-358
> URL: https://issues.apache.org/jira/browse/HTRACE-358
> Project: HTrace
> Issue Type: Improvement
> Components: core
>Affects Versions: 4.1
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-358.patch.txt
>
>
> We already provide a convenience wrapper around {{ExecutorService}}, it would
> not be onerous to also provide a wrapper around {{ScheduledExecutorService}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-358) Provide convenience wrapper around ScheduledExecutorService
[
https://issues.apache.org/jira/browse/HTRACE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273112#comment-15273112
]
Colin Patrick McCabe commented on HTRACE-358:
-
Seems reasonable. I wish there were a more elegant way to do this without
creating another subclass, but I don't see one. I like the overload on
{{Tracer#newTraceExecutorService}}.
{code}
87protected Runnable wrap(Runnable runnable) {
88 return tracer.wrap(runnable, scopeName);
89}
90
91protected Callable wrap(Callable callable) {
92 return tracer.wrap(callable, scopeName);
93}
{code}
Hmm. Rather than adding these new APIs, can we just have an API for getting
the Tracer owned by the base class? The derived class has access to this
anyway because it needs it to construct the base class. I would also prefer
that this method be package-private for now rather than protected... let's keep
the API surface small.
> Provide convenience wrapper around ScheduledExecutorService
> ---
>
> Key: HTRACE-358
> URL: https://issues.apache.org/jira/browse/HTRACE-358
> Project: HTrace
> Issue Type: Improvement
> Components: core
>Affects Versions: 4.1
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-358.patch.txt
>
>
> We already provide a convenience wrapper around {{ExecutorService}}, it would
> not be onerous to also provide a wrapper around {{ScheduledExecutorService}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-368) Cannot build Javadoc with JDK1.8.X
[
https://issues.apache.org/jira/browse/HTRACE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15272704#comment-15272704
]
Colin Patrick McCabe commented on HTRACE-368:
-
Can you be clearer about what error you are seeing?
We spent a lot of effort fixing jdk8 JavaDoc lint errors in HTRACE-354 and
HTRACE-232. The doclint should work correctly in all subprojects, except
htrace-hbase and htrace-zipkin. We suppress the doclint on just those
subprojects. Perhaps we need to fix those subprojects as well? In any case,
turning off doclint for everything is not the right answer, since we will just
see errors start creeping in again with new changes.
> Cannot build Javadoc with JDK1.8.X
> --
>
> Key: HTRACE-368
> URL: https://issues.apache.org/jira/browse/HTRACE-368
> Project: HTrace
> Issue Type: Improvement
> Components: build, docs
>Affects Versions: 4.1
>Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Minor
> Attachments: HTRACE-368.patch
>
>
> Right now if I attempt to build Javadoc in master branch with following JDK I
> get a hellish error which indicates Javadoc in HTrace Java source needs some
> attention.
> {code}
> lmcgibbn@LMC-032857 /usr/local/incubator-htrace(master) $ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T04:57:37-07:00)
> Maven home: /usr/local/apache-maven-3.3.3
> Java version: 1.8.0_66, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
> {code}
> For the interim I propose to submit a profile which would allow us to work
> around the Javadoc issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HTRACE-359) TraceRunnable and TraceCallable should be built using parent spanId not scope
[ https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-359. - Resolution: Fixed Fix Version/s: 4.2 > TraceRunnable and TraceCallable should be built using parent spanId not scope > - > > Key: HTRACE-359 > URL: https://issues.apache.org/jira/browse/HTRACE-359 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.0 >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 4.2 > > Attachments: HTRACE-359.patch.txt, HTRACE-359.patch.txt, > HTRACE-359.v3.patch.txt, HTRACE-359.v4.patch.txt > > > TraceRunnable/Callable both take a parent TraceScope and extract the span Id > from it when executing the task. Instead, we should allow users to create > custom TraceRunnable/Callable instances with only a SpanId instead of a full > TraceScope, for instance when reading a span id from an RPC call and a > TraceScope object is not available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-367) Publish Aggrgate Javadocs
[ https://issues.apache.org/jira/browse/HTRACE-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15272688#comment-15272688 ] Colin Patrick McCabe commented on HTRACE-367: - Hi [~lewismc], I assume you've seen the JavaDocs for htrace-core4 available at http://htrace.incubator.apache.org/javadoc/4.1/htrace-core/index.html ? This should be very helpful for people integrating HTrace into applications, since the htrace-core4 API is the one they need to use. When you say aggregate JavaDoc, you mean the JavaDoc for all subprojects combined? That would certainly be helpful for people developing HTrace itself, although not for outside users. > Publish Aggrgate Javadocs > - > > Key: HTRACE-367 > URL: https://issues.apache.org/jira/browse/HTRACE-367 > Project: HTrace > Issue Type: Improvement > Components: docs >Reporter: Lewis John McGibbney >Priority: Minor > > Right now, one is required to download source and manually build the full > Javadoc e.g. mvn javadoc;aggregate in order to see aggregate, full Javadoc > for HTrace. > We should simply provide this over on > http://htrace.incubator.apache.org/#javadoc > Can someone please generate the full Javadoc and commit it to SVN r wherever > the HTrace site is published from? Thanks in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should be built using parent spanId not scope
[ https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15272683#comment-15272683 ] Colin Patrick McCabe commented on HTRACE-359: - +1. Thanks, [~mdrob]. > TraceRunnable and TraceCallable should be built using parent spanId not scope > - > > Key: HTRACE-359 > URL: https://issues.apache.org/jira/browse/HTRACE-359 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.0 >Reporter: Mike Drob >Assignee: Mike Drob > Attachments: HTRACE-359.patch.txt, HTRACE-359.patch.txt, > HTRACE-359.v3.patch.txt, HTRACE-359.v4.patch.txt > > > TraceRunnable/Callable both take a parent TraceScope and extract the span Id > from it when executing the task. Instead, we should allow users to create > custom TraceRunnable/Callable instances with only a SpanId instead of a full > TraceScope, for instance when reading a span id from an RPC call and a > TraceScope object is not available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-361) Fix "link: warning: option -X main.RELEASE_VERSION unknown_release may not work in future releases" warning message
[ https://issues.apache.org/jira/browse/HTRACE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266867#comment-15266867 ] Colin Patrick McCabe commented on HTRACE-361: - Thanks, [~iwasakims]. > Fix "link: warning: option -X main.RELEASE_VERSION unknown_release may not > work in future releases" warning message > --- > > Key: HTRACE-361 > URL: https://issues.apache.org/jira/browse/HTRACE-361 > Project: HTrace > Issue Type: Bug > Components: htraced >Affects Versions: 4.0 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe >Priority: Minor > Fix For: 4.2 > > Attachments: HTRACE-361.001.patch > > > Fix "link: warning: option -X main.RELEASE_VERSION unknown_release may not > work in future releases" warning message -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-366) Add JavaDoc to missing classes.
[ https://issues.apache.org/jira/browse/HTRACE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262880#comment-15262880 ] Colin Patrick McCabe commented on HTRACE-366: - Yeah, it would be great to have more docs! And the 4.2 release will have javadocs that build cleanly under jdk8, too, which is nice. > Add JavaDoc to missing classes. > --- > > Key: HTRACE-366 > URL: https://issues.apache.org/jira/browse/HTRACE-366 > Project: HTrace > Issue Type: Bug > Components: core, docs >Affects Versions: 4.1 >Reporter: Mike Drob > > Now that we have JavaDoc published on our site, we can easily see that some > of public classes/methods are missing docs. We should write some. > For class level docs, I don't see them on MilliSpan.MilliSpanDeserializer, > Span.SpanSerializer, TimelineAnnotation, TraceExecutorService, Tracer.Builder > For method level docs, there are many many more. Adding JavaDoc build > enforcement could be done in a follow-on issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-364) Bump the version up to 4.2.0-incubating-SNAPSHOT
[ https://issues.apache.org/jira/browse/HTRACE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261561#comment-15261561 ] Colin Patrick McCabe commented on HTRACE-364: - +1, thanks [~iwasakims] > Bump the version up to 4.2.0-incubating-SNAPSHOT > > > Key: HTRACE-364 > URL: https://issues.apache.org/jira/browse/HTRACE-364 > Project: HTrace > Issue Type: Bug >Reporter: Masatake Iwasaki >Assignee: Masatake Iwasaki > Attachments: HTRACE-364.001.patch, HTRACE-364.002.patch > > > Since the 4.1.0-incubating has been released, we have to bump the version up > to 4.2.0-incubating-SNAPSHOT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-364) Bump the version up to 4.2.0-incubating-SNAPSHOT
[ https://issues.apache.org/jira/browse/HTRACE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15259623#comment-15259623 ] Colin Patrick McCabe commented on HTRACE-364: - also we should update the version in htrace.h > Bump the version up to 4.2.0-incubating-SNAPSHOT > > > Key: HTRACE-364 > URL: https://issues.apache.org/jira/browse/HTRACE-364 > Project: HTrace > Issue Type: Bug >Reporter: Masatake Iwasaki >Assignee: Masatake Iwasaki > Attachments: HTRACE-364.001.patch > > > Since the 4.1.0-incubating has been released, we have to bump the version up > to 4.2.0-incubating-SNAPSHOT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-364) Bump the version up to 4.2.0-incubating-SNAPSHOT
[
https://issues.apache.org/jira/browse/HTRACE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15259622#comment-15259622
]
Colin Patrick McCabe commented on HTRACE-364:
-
Good idea.. however, there are other pom.xml files that need to be updated. One
nice shortcut is:
{code}
mvn versions:set -DnewVersion=4.2.0-incbuating-SNAPSHOT
{code}
> Bump the version up to 4.2.0-incubating-SNAPSHOT
>
>
> Key: HTRACE-364
> URL: https://issues.apache.org/jira/browse/HTRACE-364
> Project: HTrace
> Issue Type: Bug
>Reporter: Masatake Iwasaki
>Assignee: Masatake Iwasaki
> Attachments: HTRACE-364.001.patch
>
>
> Since the 4.1.0-incubating has been released, we have to bump the version up
> to 4.2.0-incubating-SNAPSHOT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HTRACE-347) We should update the website for the 4.1 release, and fix index.html
[ https://issues.apache.org/jira/browse/HTRACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-347. - Resolution: Fixed Fix Version/s: 4.2 Committed... and updated the site. Thanks, everyone. > We should update the website for the 4.1 release, and fix index.html > > > Key: HTRACE-347 > URL: https://issues.apache.org/jira/browse/HTRACE-347 > Project: HTrace > Issue Type: Improvement > Components: docs >Affects Versions: 4.2 >Reporter: Mike Drob >Assignee: Colin Patrick McCabe > Fix For: 4.2 > > Attachments: HTRACE-347.001.patch > > > We should update the website for the 4.1 release, and fix index.html. > The website is out of date now. The website for dependency information lists > how to use the latest snapshot instead of the latest release. While the > details are not difficult for a user to extrapolate, ideally, it would list > examples for both. > http://htrace.incubator.apache.org/dependency-info.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-347) We should update the website for the 4.1 release, and fix index.html
[ https://issues.apache.org/jira/browse/HTRACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-347: Description: We should update the website for the 4.1 release, and fix index.html. The website is out of date now. The website for dependency information lists how to use the latest snapshot instead of the latest release. While the details are not difficult for a user to extrapolate, ideally, it would list examples for both. http://htrace.incubator.apache.org/dependency-info.html was: The website for dependency information lists how to use the latest snapshot instead of the latest release. While the details are not difficult for a user to extrapolate, ideally, it would list examples for both. http://htrace.incubator.apache.org/dependency-info.html > We should update the website for the 4.1 release, and fix index.html > > > Key: HTRACE-347 > URL: https://issues.apache.org/jira/browse/HTRACE-347 > Project: HTrace > Issue Type: Improvement > Components: docs >Affects Versions: 4.2 >Reporter: Mike Drob >Assignee: Colin Patrick McCabe > Attachments: HTRACE-347.001.patch > > > We should update the website for the 4.1 release, and fix index.html. > The website is out of date now. The website for dependency information lists > how to use the latest snapshot instead of the latest release. While the > details are not difficult for a user to extrapolate, ideally, it would list > examples for both. > http://htrace.incubator.apache.org/dependency-info.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-347) We should update the website for the 4.1 release, and fix index.html
[ https://issues.apache.org/jira/browse/HTRACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-347: Attachment: HTRACE-347.001.patch This patch adds a better landing page (index.html) for our site. > We should update the website for the 4.1 release, and fix index.html > > > Key: HTRACE-347 > URL: https://issues.apache.org/jira/browse/HTRACE-347 > Project: HTrace > Issue Type: Improvement > Components: docs >Reporter: Mike Drob > Attachments: HTRACE-347.001.patch > > > The website for dependency information lists how to use the latest snapshot > instead of the latest release. While the details are not difficult for a user > to extrapolate, ideally, it would list examples for both. > http://htrace.incubator.apache.org/dependency-info.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-347) We should update the website for the 4.1 release, and fix index.html
[ https://issues.apache.org/jira/browse/HTRACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-347: Summary: We should update the website for the 4.1 release, and fix index.html (was: Dependency info page lists snapshots instead of releases) > We should update the website for the 4.1 release, and fix index.html > > > Key: HTRACE-347 > URL: https://issues.apache.org/jira/browse/HTRACE-347 > Project: HTrace > Issue Type: Improvement > Components: docs >Reporter: Mike Drob > > The website for dependency information lists how to use the latest snapshot > instead of the latest release. While the details are not difficult for a user > to extrapolate, ideally, it would list examples for both. > http://htrace.incubator.apache.org/dependency-info.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-353) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/HTRACE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-353. - Resolution: Fixed Assignee: Colin Patrick McCabe Fix Version/s: n/a I removed 3.1.0 and 3.2.0 from dist. > Please delete old releases from mirroring system > > > Key: HTRACE-353 > URL: https://issues.apache.org/jira/browse/HTRACE-353 > Project: HTrace > Issue Type: Bug > Environment: > https://dist.apache.org/repos/dist/release/incubator/htrace/ >Reporter: Sebb >Assignee: Colin Patrick McCabe > Fix For: n/a > > > To reduce the load on the ASF mirrors, projects are required to delete old > releases [1] > Please can you remove all non-current releases? > Thanks! > [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-353) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/HTRACE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15259270#comment-15259270 ] Colin Patrick McCabe commented on HTRACE-353: - Yeah, let's remove the 3.x releases from dist/, since we're not actively developing that line any more. > Please delete old releases from mirroring system > > > Key: HTRACE-353 > URL: https://issues.apache.org/jira/browse/HTRACE-353 > Project: HTrace > Issue Type: Bug > Environment: > https://dist.apache.org/repos/dist/release/incubator/htrace/ >Reporter: Sebb > > To reduce the load on the ASF mirrors, projects are required to delete old > releases [1] > Please can you remove all non-current releases? > Thanks! > [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should be built using parent spanId not scope
[
https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15259078#comment-15259078
]
Colin Patrick McCabe commented on HTRACE-359:
-
Ha! That's a fair criticism. Adding the new constructor does commit us to
maintaining it forever (in v4 at least), which is why I was hesitant earlier.
Based on our discussion here, though, I think there might be some value in
making it look different from wrap() though, given the different semantics.
Also, the fact that {{TraceRunnable}} already has a public constructor tends to
strengthen the argument for giving them both public constructors (but not
adding a TraceScope form... we shouldn't have added that in the first place :P )
> TraceRunnable and TraceCallable should be built using parent spanId not scope
> -
>
> Key: HTRACE-359
> URL: https://issues.apache.org/jira/browse/HTRACE-359
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-359.patch.txt, HTRACE-359.patch.txt,
> HTRACE-359.v3.patch.txt
>
>
> TraceRunnable/Callable both take a parent TraceScope and extract the span Id
> from it when executing the task. Instead, we should allow users to create
> custom TraceRunnable/Callable instances with only a SpanId instead of a full
> TraceScope, for instance when reading a span id from an RPC call and a
> TraceScope object is not available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should be built using parent spanId not scope
[ https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15258752#comment-15258752 ] Colin Patrick McCabe commented on HTRACE-359: - bq. As an aside, it looks like there are no unit tests that verify a new scope with two parents. Yeah, we should add some more tests for this. > TraceRunnable and TraceCallable should be built using parent spanId not scope > - > > Key: HTRACE-359 > URL: https://issues.apache.org/jira/browse/HTRACE-359 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.0 >Reporter: Mike Drob >Assignee: Mike Drob > Attachments: HTRACE-359.patch.txt, HTRACE-359.patch.txt, > HTRACE-359.v3.patch.txt > > > TraceRunnable/Callable both take a parent TraceScope and extract the span Id > from it when executing the task. Instead, we should allow users to create > custom TraceRunnable/Callable instances with only a SpanId instead of a full > TraceScope, for instance when reading a span id from an RPC call and a > TraceScope object is not available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should be built using parent spanId not scope
[
https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15258657#comment-15258657
]
Colin Patrick McCabe commented on HTRACE-359:
-
One thing that might confuse users is that the API here for {{public
Callable wrap(Callable callable, String description, SpanId parentId)}}
is different than the existing {{newScope}} API. If there is an existing trace
scope and a span ID was also passed, the {{newScope}} API will add both as
parents of the new span (if a span is created), whereas this API just adds the
pass-in span ID. We should carefully document this in the JavaDoc.
Currently the JavaDoc for wrap is misleading:
{code}
* @param parentId If this is a valid span ID, it will be added to
* the parents of the new span we create.
{code}
> TraceRunnable and TraceCallable should be built using parent spanId not scope
> -
>
> Key: HTRACE-359
> URL: https://issues.apache.org/jira/browse/HTRACE-359
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-359.patch.txt, HTRACE-359.patch.txt,
> HTRACE-359.v3.patch.txt
>
>
> TraceRunnable/Callable both take a parent TraceScope and extract the span Id
> from it when executing the task. Instead, we should allow users to create
> custom TraceRunnable/Callable instances with only a SpanId instead of a full
> TraceScope, for instance when reading a span id from an RPC call and a
> TraceScope object is not available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-347) Dependency info page lists snapshots instead of releases
[ https://issues.apache.org/jira/browse/HTRACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257439#comment-15257439 ] Colin Patrick McCabe commented on HTRACE-347: - Thanks, guys. I'm taking a look at doing the redploy, but there are a few things I'd like to add to our index.html first. Right now the landing page feels a bit... bare. I'll post a patch in a little bit. > Dependency info page lists snapshots instead of releases > > > Key: HTRACE-347 > URL: https://issues.apache.org/jira/browse/HTRACE-347 > Project: HTrace > Issue Type: Improvement > Components: docs >Reporter: Mike Drob > > The website for dependency information lists how to use the latest snapshot > instead of the latest release. While the details are not difficult for a user > to extrapolate, ideally, it would list examples for both. > http://htrace.incubator.apache.org/dependency-info.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HTRACE-347) Dependency info page lists snapshots instead of releases
[ https://issues.apache.org/jira/browse/HTRACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257439#comment-15257439 ] Colin Patrick McCabe edited comment on HTRACE-347 at 4/26/16 2:19 AM: -- Thanks, guys. I'm taking a look at doing the redeploy, but there are a few things I'd like to add to our index.html first. Right now the landing page feels a bit... bare. I'll post a patch in a little bit. was (Author: cmccabe): Thanks, guys. I'm taking a look at doing the redploy, but there are a few things I'd like to add to our index.html first. Right now the landing page feels a bit... bare. I'll post a patch in a little bit. > Dependency info page lists snapshots instead of releases > > > Key: HTRACE-347 > URL: https://issues.apache.org/jira/browse/HTRACE-347 > Project: HTrace > Issue Type: Improvement > Components: docs >Reporter: Mike Drob > > The website for dependency information lists how to use the latest snapshot > instead of the latest release. While the details are not difficult for a user > to extrapolate, ideally, it would list examples for both. > http://htrace.incubator.apache.org/dependency-info.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-347) Dependency info page lists snapshots instead of releases
[
https://issues.apache.org/jira/browse/HTRACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257059#comment-15257059
]
Colin Patrick McCabe commented on HTRACE-347:
-
Thanks for the reminder, [~billie.rinaldi]. Based on the discussion there, it
seems like the website is updated via running {{mvn site:stage}} and then
manually checking those generated files into the subversion directory for our
website. [~saint@gmail.com], should we add this to our how-to-release
document?
Also, I would really like to add an online JavaDoc reference, does anyone have
ideas about how to do that? It seems like we could do something very similar
where we run a Maven command to generate the HTML from JavaDoc, and then check
that in. It would be nice to keep up the JavaDoc directories for the old
releases when doing this, of course...
> Dependency info page lists snapshots instead of releases
>
>
> Key: HTRACE-347
> URL: https://issues.apache.org/jira/browse/HTRACE-347
> Project: HTrace
> Issue Type: Improvement
> Components: docs
>Reporter: Mike Drob
>
> The website for dependency information lists how to use the latest snapshot
> instead of the latest release. While the details are not difficult for a user
> to extrapolate, ideally, it would list examples for both.
> http://htrace.incubator.apache.org/dependency-info.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HTRACE-361) Fix "link: warning: option -X main.RELEASE_VERSION unknown_release may not work in future releases" warning message
[ https://issues.apache.org/jira/browse/HTRACE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-361: Attachment: HTRACE-361.001.patch > Fix "link: warning: option -X main.RELEASE_VERSION unknown_release may not > work in future releases" warning message > --- > > Key: HTRACE-361 > URL: https://issues.apache.org/jira/browse/HTRACE-361 > Project: HTrace > Issue Type: Bug > Components: htraced >Affects Versions: 4.0 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe >Priority: Minor > Attachments: HTRACE-361.001.patch > > > Fix "link: warning: option -X main.RELEASE_VERSION unknown_release may not > work in future releases" warning message -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should be built using parent spanId not scope
[
https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253122#comment-15253122
]
Colin Patrick McCabe commented on HTRACE-359:
-
Hi [~mdrob],
Thanks for the patch. Looks good overall.
One small note: It's a bit confusing to upload multiple patch files with the
same name... usually we add numbers to the end to make sure that the correct
patch gets committed.
{code}
- public TraceRunnable(Tracer tracer, TraceScope parent,
+ public TraceRunnable(Tracer tracer, SpanId parentId,
{code}
Hmm, we have to be careful here. We can't change the type signature of a
public htrace4-core API. It breaks our compatibility guidelines. If you
haven't read them yet, please check out the compatibility policy here:
http://markmail.org/message/g4t4aivhvi2yyuqq On the other hand, we can add a
new constructor with the type signature that includes {{SpanId}}.
> TraceRunnable and TraceCallable should be built using parent spanId not scope
> -
>
> Key: HTRACE-359
> URL: https://issues.apache.org/jira/browse/HTRACE-359
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-359.patch.txt, HTRACE-359.patch.txt
>
>
> TraceRunnable/Callable both take a parent TraceScope and extract the span Id
> from it when executing the task. Instead, we should allow users to create
> custom TraceRunnable/Callable instances with only a SpanId instead of a full
> TraceScope, for instance when reading a span id from an RPC call and a
> TraceScope object is not available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should store parent spanId not scope
[
https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248504#comment-15248504
]
Colin Patrick McCabe commented on HTRACE-359:
-
Thanks for giving the example. I agree, you should not create an extra scope
just to be able to use this convenience method. This would be bad for other
reasons as well... you would be creating an extra trace span which doesn't
serve any purpose. Remember, you should minimize the number of trace spans you
are creating-- make each one meaningful and useful so that users can look at
traces and see what's going on.
I guess we could add another {{Tracer#wrap}} method which took a {{SpanId}} in
addition to the {{Callable}} and description. This essentially would match the
two {{Tracer#newScope}} overloads.
> TraceRunnable and TraceCallable should store parent spanId not scope
>
>
> Key: HTRACE-359
> URL: https://issues.apache.org/jira/browse/HTRACE-359
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-359.patch.txt
>
>
> TraceRunnable/Callable both take a parent TraceScope and extract the span Id
> from it when executing the task. Instead, we should allow users to create
> custom TraceRunnable/Callable instances with only a SpanId instead of a full
> TraceScope, for instance when reading a span id from an RPC call and a
> TraceScope object is not available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should store parent spanId not scope
[ https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248355#comment-15248355 ] Colin Patrick McCabe commented on HTRACE-359: - bq. Does HTrace use semantic versioning? Yes, we use semantic versioning. bq. Would you suggest making the TraceRunnable constructor non-public as well then? I would like to, but I don't want to remove an existing API. The htrace-core4 API contract specifies that we will not remove or alter public APIs in htrace4-core without bumping the major version to 5.x. We are allowed to add new APIs, though. More info here: http://markmail.org/message/g4t4aivhvi2yyuqq We should probably just change the internal implementation to store the spanId rather than the scope, but leave the type signatures unchanged. bq. What is defined as the HTrace public API? In general, the HTrace public API is any function that's public. We don't use interface annotations... in my experience, end users tend to ignore them. > TraceRunnable and TraceCallable should store parent spanId not scope > > > Key: HTRACE-359 > URL: https://issues.apache.org/jira/browse/HTRACE-359 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.0 >Reporter: Mike Drob >Assignee: Mike Drob > Attachments: HTRACE-359.patch.txt > > > TraceRunnable/Callable both take a parent TraceScope and extract the span Id > from it when executing the task. Instead, we should allow users to create > custom TraceRunnable/Callable instances with only a SpanId instead of a full > TraceScope, for instance when reading a span id from an RPC call and a > TraceScope object is not available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-360) Missing space in Sampler.java "Cannot find a constructor" error log message
[
https://issues.apache.org/jira/browse/HTRACE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe resolved HTRACE-360.
-
Resolution: Fixed
Fix Version/s: 4.2
committed to 4.2
> Missing space in Sampler.java "Cannot find a constructor" error log message
> ---
>
> Key: HTRACE-360
> URL: https://issues.apache.org/jira/browse/HTRACE-360
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Trivial
> Fix For: 4.2
>
> Attachments: HTRACE-360.patch.txt
>
>
> Missing space in the log message {{SEVERE: Cannot find a constructor for
> class com.example.BadSamplerwhich takes an HTraceConfiguration.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HTRACE-360) Missing space in Sampler.java "Cannot find a constructor" error log message
[
https://issues.apache.org/jira/browse/HTRACE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated HTRACE-360:
Summary: Missing space in Sampler.java "Cannot find a constructor" error
log message (was: Missing space in Sampler.java )
> Missing space in Sampler.java "Cannot find a constructor" error log message
> ---
>
> Key: HTRACE-360
> URL: https://issues.apache.org/jira/browse/HTRACE-360
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Trivial
> Attachments: HTRACE-360.patch.txt
>
>
> Missing space in the log message {{SEVERE: Cannot find a constructor for
> class com.example.BadSamplerwhich takes an HTraceConfiguration.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HTRACE-360) Missing space in Sampler.java
[
https://issues.apache.org/jira/browse/HTRACE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated HTRACE-360:
Summary: Missing space in Sampler.java (was: Missing space in
Sampler.java)
> Missing space in Sampler.java
> --
>
> Key: HTRACE-360
> URL: https://issues.apache.org/jira/browse/HTRACE-360
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Trivial
> Attachments: HTRACE-360.patch.txt
>
>
> Missing space in the log message {{SEVERE: Cannot find a constructor for
> class com.example.BadSamplerwhich takes an HTraceConfiguration.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-360) Missing space in Sampler.java
[
https://issues.apache.org/jira/browse/HTRACE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248326#comment-15248326
]
Colin Patrick McCabe commented on HTRACE-360:
-
+1. Thanks, [~mdrob]
> Missing space in Sampler.java
> -
>
> Key: HTRACE-360
> URL: https://issues.apache.org/jira/browse/HTRACE-360
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Trivial
> Attachments: HTRACE-360.patch.txt
>
>
> Missing space in the log message {{SEVERE: Cannot find a constructor for
> class com.example.BadSamplerwhich takes an HTraceConfiguration.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-359) TraceRunnable and TraceCallable should store parent spanId not scope
[ https://issues.apache.org/jira/browse/HTRACE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248323#comment-15248323 ] Colin Patrick McCabe commented on HTRACE-359: - Please let's not add public constructors, or deprecated constructors. One of the nice things about not having them is that this change can be made without changing any APIs at all. > TraceRunnable and TraceCallable should store parent spanId not scope > > > Key: HTRACE-359 > URL: https://issues.apache.org/jira/browse/HTRACE-359 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.0 >Reporter: Mike Drob >Assignee: Mike Drob > Attachments: HTRACE-359.patch.txt > > > TraceRunnable/Callable both take a parent TraceScope and extract the span Id > from it when executing the task. Instead, we should allow users to create > custom TraceRunnable/Callable instances with only a SpanId instead of a full > TraceScope, for instance when reading a span id from an RPC call and a > TraceScope object is not available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-357) Rename htrace-htraced/go/src/org/apache/htrace to htrace-htraced/go/src/htrace
[ https://issues.apache.org/jira/browse/HTRACE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-357: Attachment: HTRACE-357.001.patch patch is just a rename, plus changing the build script to build htrace/... rather than org/apache/htrace... > Rename htrace-htraced/go/src/org/apache/htrace to htrace-htraced/go/src/htrace > -- > > Key: HTRACE-357 > URL: https://issues.apache.org/jira/browse/HTRACE-357 > Project: HTrace > Issue Type: Improvement > Components: htraced >Affects Versions: 4.0 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe >Priority: Minor > Attachments: HTRACE-357.001.patch > > > We should rename htrace-htraced/go/src/org/apache/htrace to > htrace-htraced/go/src/htrace. The use of long, domain-like names is not > really considered good style in Golang (unlike in Java). This doesn't affect > the generated code at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-357) Rename htrace-htraced/go/src/org/apache/htrace to htrace-htraced/go/src/htrace
Colin Patrick McCabe created HTRACE-357: --- Summary: Rename htrace-htraced/go/src/org/apache/htrace to htrace-htraced/go/src/htrace Key: HTRACE-357 URL: https://issues.apache.org/jira/browse/HTRACE-357 Project: HTrace Issue Type: Improvement Components: htraced Affects Versions: 4.0 Reporter: Colin Patrick McCabe Priority: Minor We should rename htrace-htraced/go/src/org/apache/htrace to htrace-htraced/go/src/htrace. The use of long, domain-like names is not really considered good style in Golang (unlike in Java). This doesn't affect the generated code at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HTRACE-357) Rename htrace-htraced/go/src/org/apache/htrace to htrace-htraced/go/src/htrace
[ https://issues.apache.org/jira/browse/HTRACE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe reassigned HTRACE-357: --- Assignee: Colin Patrick McCabe > Rename htrace-htraced/go/src/org/apache/htrace to htrace-htraced/go/src/htrace > -- > > Key: HTRACE-357 > URL: https://issues.apache.org/jira/browse/HTRACE-357 > Project: HTrace > Issue Type: Improvement > Components: htraced >Affects Versions: 4.0 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe >Priority: Minor > > We should rename htrace-htraced/go/src/org/apache/htrace to > htrace-htraced/go/src/htrace. The use of long, domain-like names is not > really considered good style in Golang (unlike in Java). This doesn't affect > the generated code at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-355) TraceRunnable and TraceCallable should pull description from child thread instead of parent
[
https://issues.apache.org/jira/browse/HTRACE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe resolved HTRACE-355.
-
Resolution: Fixed
Fix Version/s: 4.2
> TraceRunnable and TraceCallable should pull description from child thread
> instead of parent
> ---
>
> Key: HTRACE-355
> URL: https://issues.apache.org/jira/browse/HTRACE-355
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 4.2
>
> Attachments: HTRACE-355.patch.txt, HTRACE-355.patch.txt
>
>
> If a TraceRunnable or TraceCallable is passed a null scope name, then it will
> set the description to the current thread's name, which happens to be the
> parent thread. It would be much more useful to set the description to the
> child thread's name.
> A nice side effect of this change is that we can add a version of
> {{tracer.newTraceExecutor}} that doesn't need to take a description for use
> by applications that take great care to name their threads in an informative
> manner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-355) TraceRunnable and TraceCallable should pull description from child thread instead of parent
[
https://issues.apache.org/jira/browse/HTRACE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246512#comment-15246512
]
Colin Patrick McCabe commented on HTRACE-355:
-
Thanks, [~mdrob].
bq. Also switched from using a countdown latch to using the futures returned by
the ExecutorService, as that ends up being a bit more straightforward, I
thought.
Looks good!
+1. Committed to 4.2.
> TraceRunnable and TraceCallable should pull description from child thread
> instead of parent
> ---
>
> Key: HTRACE-355
> URL: https://issues.apache.org/jira/browse/HTRACE-355
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-355.patch.txt, HTRACE-355.patch.txt
>
>
> If a TraceRunnable or TraceCallable is passed a null scope name, then it will
> set the description to the current thread's name, which happens to be the
> parent thread. It would be much more useful to set the description to the
> child thread's name.
> A nice side effect of this change is that we can add a version of
> {{tracer.newTraceExecutor}} that doesn't need to take a description for use
> by applications that take great care to name their threads in an informative
> manner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HTRACE-356) Docker: test via oracle-jdk8 rather than oracle-jdk7
[ https://issues.apache.org/jira/browse/HTRACE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-356: Attachment: HTRACE-356.001.patch > Docker: test via oracle-jdk8 rather than oracle-jdk7 > > > Key: HTRACE-356 > URL: https://issues.apache.org/jira/browse/HTRACE-356 > Project: HTrace > Issue Type: Improvement > Components: test >Affects Versions: 4.1 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe > Attachments: HTRACE-356.001.patch > > > When using Docker, we should test via oracle-jdk8 rather than oracle-jdk7. > (We use Docker for our postcommit builds, for example). This will make sure > that if incorrect javadoc is introduced by some change, we will notice and be > able to correct it. Of course, we will continue to build targetting > source-version jdk7, so there are no compatibility implications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-354) Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks in jdk7 because of unknown doclint flag
[ https://issues.apache.org/jira/browse/HTRACE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15243855#comment-15243855 ] Colin Patrick McCabe commented on HTRACE-354: - I filed a follow-on JIRA to do our Docker testing with jdk8. That will help spot bad javadoc issues and prevent otherwise inevitable regressions. > Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks > in jdk7 because of unknown doclint flag > - > > Key: HTRACE-354 > URL: https://issues.apache.org/jira/browse/HTRACE-354 > Project: HTrace > Issue Type: Bug > Components: docs >Affects Versions: 4.2 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe > Attachments: HTRACE-354.001.patch > > > Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks > in jdk7 because of unknown doclint flag -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-356) Docker: test via oracle-jdk8 rather than oracle-jdk7
Colin Patrick McCabe created HTRACE-356: --- Summary: Docker: test via oracle-jdk8 rather than oracle-jdk7 Key: HTRACE-356 URL: https://issues.apache.org/jira/browse/HTRACE-356 Project: HTrace Issue Type: Improvement Components: test Affects Versions: 4.1 Reporter: Colin Patrick McCabe Assignee: Colin Patrick McCabe When using Docker, we should test via oracle-jdk8 rather than oracle-jdk7. (We use Docker for our postcommit builds, for example). This will make sure that if incorrect javadoc is introduced by some change, we will notice and be able to correct it. Of course, we will continue to build targetting source-version jdk7, so there are no compatibility implications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-354) Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks in jdk7 because of unknown doclint flag
[ https://issues.apache.org/jira/browse/HTRACE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-354. - Resolution: Fixed committed to 4.2, thanks > Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks > in jdk7 because of unknown doclint flag > - > > Key: HTRACE-354 > URL: https://issues.apache.org/jira/browse/HTRACE-354 > Project: HTrace > Issue Type: Bug > Components: docs >Affects Versions: 4.2 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe > Attachments: HTRACE-354.001.patch > > > Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks > in jdk7 because of unknown doclint flag -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-355) TraceRunnable and TraceCallable should pull description from child thread instead of parent
[
https://issues.apache.org/jira/browse/HTRACE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated HTRACE-355:
Affects Version/s: (was: 4.1)
4.0
> TraceRunnable and TraceCallable should pull description from child thread
> instead of parent
> ---
>
> Key: HTRACE-355
> URL: https://issues.apache.org/jira/browse/HTRACE-355
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-355.patch.txt
>
>
> If a TraceRunnable or TraceCallable is passed a null scope name, then it will
> set the description to the current thread's name, which happens to be the
> parent thread. It would be much more useful to set the description to the
> child thread's name.
> A nice side effect of this change is that we can add a version of
> {{tracer.newTraceExecutor}} that doesn't need to take a description for use
> by applications that take great care to name their threads in an informative
> manner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-355) TraceRunnable and TraceCallable should pull description from child thread instead of parent
[
https://issues.apache.org/jira/browse/HTRACE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15243559#comment-15243559
]
Colin Patrick McCabe commented on HTRACE-355:
-
This is basically a bug... we intended to set the scope name based on the child
thread's name, as was done in 3.2 and earlier releases. I don't think anyone
has started to depend on the new behavior yet, so we should be able to fix this
easily in 4.2.
{code}
runnableLatch.await(1, TimeUnit.SECONDS);
{code}
This is a very short timeout. It seems like this could lead to spurious test
failures on a GC or similar event. This should be at least 60 seconds to match
our other test timeouts.
{code}
38 @Before
39public void setup() {
40 tracer = new
Tracer.Builder("TestTraceExecutor").conf(HTraceConfiguration.fromKeyValuePairs("sampler.classes",
"AlwaysSampler")).build();
41}
42
43@After
44public void teardown() {
45 tracer.close();
46}
{code}
Considering it's just one line of setup, can we just do this in the test
itself? If we want to add another test to this file, we may not want this
Tracer object. JUnit test files with global state are annoying to extend.
> TraceRunnable and TraceCallable should pull description from child thread
> instead of parent
> ---
>
> Key: HTRACE-355
> URL: https://issues.apache.org/jira/browse/HTRACE-355
> Project: HTrace
> Issue Type: Bug
> Components: core
>Affects Versions: 4.0
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HTRACE-355.patch.txt
>
>
> If a TraceRunnable or TraceCallable is passed a null scope name, then it will
> set the description to the current thread's name, which happens to be the
> parent thread. It would be much more useful to set the description to the
> child thread's name.
> A nice side effect of this change is that we can add a version of
> {{tracer.newTraceExecutor}} that doesn't need to take a description for use
> by applications that take great care to name their threads in an informative
> manner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HTRACE-354) Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks in jdk7 because of unknown doclint flag
[ https://issues.apache.org/jira/browse/HTRACE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240070#comment-15240070 ] Colin Patrick McCabe commented on HTRACE-354: - * htrace-flume: fix a bad javadoc comment and enable javadoc lint * htrace-htraced: enable javadoc lint * htrace-zipkin: fix javadoc lint suppression to work with both jdk7 and jdk8 * htrace-hbase: fix javadoc lint suppression to work with both jdk7 and jdk8 I wanted to fix zipkin and hbase, but they have a lot of generated code which is a pain to fix by hand. We can do these in follow-on jiras (perhaps by updating the code generators?) > Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks > in jdk7 because of unknown doclint flag > - > > Key: HTRACE-354 > URL: https://issues.apache.org/jira/browse/HTRACE-354 > Project: HTrace > Issue Type: Bug > Components: docs >Affects Versions: 4.2 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe > Attachments: HTRACE-354.001.patch > > > Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks > in jdk7 because of unknown doclint flag -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-232) Make htrace4-core work with the new Javadoc lint standards in jdk8
[ https://issues.apache.org/jira/browse/HTRACE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240065#comment-15240065 ] Colin Patrick McCabe commented on HTRACE-232: - I posted HTRACE-354 as a follow-on to fix the build under jdk7 and clean up some more subprojects. > Make htrace4-core work with the new Javadoc lint standards in jdk8 > -- > > Key: HTRACE-232 > URL: https://issues.apache.org/jira/browse/HTRACE-232 > Project: HTrace > Issue Type: Task > Components: build, docs >Affects Versions: 3.1.0 > Environment: java 8, maven 3 >Reporter: Arun Khetarpal >Assignee: Colin Patrick McCabe >Priority: Trivial > Labels: newbie > Fix For: 4.2 > > Attachments: HTRACE-232.002.patch > > > Doclint gives the following errors while compiling with Java 8 > [ERROR] > /Users/arun.khetarpal/Opensource/apache/htrace/incubator-htrace/htrace-core/src/main/java/org/apache/htrace/core/Span.java:62: > warning: no @return > [ERROR] boolean isRunning(); > The errors could be divided into two groups > a) No @return > b) no self-closed HTML tags, such as or -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-354) Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks in jdk7 because of unknown doclint flag
Colin Patrick McCabe created HTRACE-354: --- Summary: Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks in jdk7 because of unknown doclint flag Key: HTRACE-354 URL: https://issues.apache.org/jira/browse/HTRACE-354 Project: HTrace Issue Type: Bug Components: docs Affects Versions: 4.2 Reporter: Colin Patrick McCabe Assignee: Colin Patrick McCabe Enable javadoc lint in htrace-flume and htrace-htraced and avoid build breaks in jdk7 because of unknown doclint flag -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HTRACE-232) Make htrace4-core work with the new Javadoc lint standards in jdk8
[ https://issues.apache.org/jira/browse/HTRACE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240012#comment-15240012 ] Colin Patrick McCabe commented on HTRACE-232: - Hmm. For some reason, after this patch, the build fails on jdk7 with "javadoc: error - invalid flag: -Xdoclint:none". I'm not sure why this would be the case, since we used that flag with jdk7 previously without any problem. The difference is that we used it in the root pom.xml, rather than in a child pom.xml. Probably the simplest way to resolve this is to fix the javadoc in the other subprojects. That way, we can get a clean javadoc build of the whole project (and hopefully put that JavaDoc online soon.) > Make htrace4-core work with the new Javadoc lint standards in jdk8 > -- > > Key: HTRACE-232 > URL: https://issues.apache.org/jira/browse/HTRACE-232 > Project: HTrace > Issue Type: Task > Components: build, docs >Affects Versions: 3.1.0 > Environment: java 8, maven 3 >Reporter: Arun Khetarpal >Assignee: Colin Patrick McCabe >Priority: Trivial > Labels: newbie > Fix For: 4.2 > > Attachments: HTRACE-232.002.patch > > > Doclint gives the following errors while compiling with Java 8 > [ERROR] > /Users/arun.khetarpal/Opensource/apache/htrace/incubator-htrace/htrace-core/src/main/java/org/apache/htrace/core/Span.java:62: > warning: no @return > [ERROR] boolean isRunning(); > The errors could be divided into two groups > a) No @return > b) no self-closed HTML tags, such as or -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-232) Make htrace4-core work with the new Javadoc lint standards in jdk8
[ https://issues.apache.org/jira/browse/HTRACE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-232. - Resolution: Fixed Fix Version/s: 4.2 Target Version/s: 4.2 Committed to 4.2, thanks! > Make htrace4-core work with the new Javadoc lint standards in jdk8 > -- > > Key: HTRACE-232 > URL: https://issues.apache.org/jira/browse/HTRACE-232 > Project: HTrace > Issue Type: Task > Components: build, docs >Affects Versions: 3.1.0 > Environment: java 8, maven 3 >Reporter: Arun Khetarpal >Assignee: Colin Patrick McCabe >Priority: Trivial > Labels: newbie > Fix For: 4.2 > > Attachments: HTRACE-232.002.patch > > > Doclint gives the following errors while compiling with Java 8 > [ERROR] > /Users/arun.khetarpal/Opensource/apache/htrace/incubator-htrace/htrace-core/src/main/java/org/apache/htrace/core/Span.java:62: > warning: no @return > [ERROR] boolean isRunning(); > The errors could be divided into two groups > a) No @return > b) no self-closed HTML tags, such as or -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-232) Make htrace4-core work with the new Javadoc lint standards in jdk8
[ https://issues.apache.org/jira/browse/HTRACE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-232: Summary: Make htrace4-core work with the new Javadoc lint standards in jdk8 (was: Java Docs do not compile with Java 8 ) > Make htrace4-core work with the new Javadoc lint standards in jdk8 > -- > > Key: HTRACE-232 > URL: https://issues.apache.org/jira/browse/HTRACE-232 > Project: HTrace > Issue Type: Task > Components: build, docs >Affects Versions: 3.1.0 > Environment: java 8, maven 3 >Reporter: Arun Khetarpal >Priority: Trivial > Labels: newbie > Attachments: HTRACE-232.002.patch > > > Doclint gives the following errors while compiling with Java 8 > [ERROR] > /Users/arun.khetarpal/Opensource/apache/htrace/incubator-htrace/htrace-core/src/main/java/org/apache/htrace/core/Span.java:62: > warning: no @return > [ERROR] boolean isRunning(); > The errors could be divided into two groups > a) No @return > b) no self-closed HTML tags, such as or -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-232) Make htrace4-core work with the new Javadoc lint standards in jdk8
[ https://issues.apache.org/jira/browse/HTRACE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-232: Attachment: HTRACE-232.002.patch > Make htrace4-core work with the new Javadoc lint standards in jdk8 > -- > > Key: HTRACE-232 > URL: https://issues.apache.org/jira/browse/HTRACE-232 > Project: HTrace > Issue Type: Task > Components: build, docs >Affects Versions: 3.1.0 > Environment: java 8, maven 3 >Reporter: Arun Khetarpal >Priority: Trivial > Labels: newbie > Attachments: HTRACE-232.002.patch > > > Doclint gives the following errors while compiling with Java 8 > [ERROR] > /Users/arun.khetarpal/Opensource/apache/htrace/incubator-htrace/htrace-core/src/main/java/org/apache/htrace/core/Span.java:62: > warning: no @return > [ERROR] boolean isRunning(); > The errors could be divided into two groups > a) No @return > b) no self-closed HTML tags, such as or -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-350) Add a developer guide
[ https://issues.apache.org/jira/browse/HTRACE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-350: Attachment: (was: HTRACE-350.002.patch) > Add a developer guide > - > > Key: HTRACE-350 > URL: https://issues.apache.org/jira/browse/HTRACE-350 > Project: HTrace > Issue Type: Improvement > Components: docs >Affects Versions: 4.2 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe > Attachments: HTRACE-350.001.patch, HTRACE-350.002.patch > > > We should add a developer guide to make it easier for people to integrate > HTrace into their applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-352) Dependency info in site documentation should refer to htrace-core4
[ https://issues.apache.org/jira/browse/HTRACE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-352. - Resolution: Fixed Fix Version/s: 4.2 Target Version/s: 4.2 > Dependency info in site documentation should refer to htrace-core4 > -- > > Key: HTRACE-352 > URL: https://issues.apache.org/jira/browse/HTRACE-352 > Project: HTrace > Issue Type: Bug > Components: docs >Affects Versions: 4.0 >Reporter: Masatake Iwasaki >Assignee: Masatake Iwasaki > Fix For: 4.2 > > Attachments: HTRACE-352.001.patch > > > Projects using HTrace should add dependency to htrace-core4 rather than > htrace. Site documentation should show htrace-core4/dependency-info.html > instead of dependency-info.html of the parent project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-351) Add JavaPropertyConfiguration
[
https://issues.apache.org/jira/browse/HTRACE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe resolved HTRACE-351.
-
Resolution: Fixed
Fix Version/s: 4.2
> Add JavaPropertyConfiguration
> -
>
> Key: HTRACE-351
> URL: https://issues.apache.org/jira/browse/HTRACE-351
> Project: HTrace
> Issue Type: New Feature
> Components: core
>Affects Versions: 4.0
>Reporter: Colin Patrick McCabe
>Assignee: Colin Patrick McCabe
>Priority: Minor
> Fix For: 4.2
>
> Attachments: HTRACE-351.001.patch, HTRACE-351.002.patch
>
>
> Add {{JavaPropertyConfiguration}}. This class reads configuration properties
> from the System configuration space. It can serve as an example of how to
> write an {{HTraceConfiguration}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HTRACE-351) Add JavaPropertyConfiguration
Colin Patrick McCabe created HTRACE-351:
---
Summary: Add JavaPropertyConfiguration
Key: HTRACE-351
URL: https://issues.apache.org/jira/browse/HTRACE-351
Project: HTrace
Issue Type: New Feature
Components: core
Affects Versions: 4.0
Reporter: Colin Patrick McCabe
Assignee: Colin Patrick McCabe
Priority: Minor
Add {{JavaPropertyConfiguration}}. This class reads configuration properties
from the System configuration space. It can serve as an example of how to
write an {{HTraceConfiguration}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HTRACE-349) htrace-core4 implementation should use JDK7 try-with-resources
[ https://issues.apache.org/jira/browse/HTRACE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-349: Target Version/s: 4.2 (was: 4.1) Fix Version/s: (was: 4.1) 4.2 > htrace-core4 implementation should use JDK7 try-with-resources > -- > > Key: HTRACE-349 > URL: https://issues.apache.org/jira/browse/HTRACE-349 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 4.1 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Minor > Fix For: 4.2 > > Attachments: HTRACE-349.patch.txt > > > Absent excellent documentation, people will be looking at the internal code > for examples and guidance. We should use try-with-resources where possible to > keep code clean and concise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-350) Add a developer guide
[ https://issues.apache.org/jira/browse/HTRACE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-350: Attachment: HTRACE-350.001.patch > Add a developer guide > - > > Key: HTRACE-350 > URL: https://issues.apache.org/jira/browse/HTRACE-350 > Project: HTrace > Issue Type: Improvement > Components: docs >Affects Versions: 4.2 >Reporter: Colin Patrick McCabe >Assignee: Colin Patrick McCabe > Attachments: HTRACE-350.001.patch > > > We should add a developer guide to make it easier for people to integrate > HTrace into their applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HTRACE-350) Add a developer guide
Colin Patrick McCabe created HTRACE-350: --- Summary: Add a developer guide Key: HTRACE-350 URL: https://issues.apache.org/jira/browse/HTRACE-350 Project: HTrace Issue Type: Improvement Components: docs Affects Versions: 4.2 Reporter: Colin Patrick McCabe Assignee: Colin Patrick McCabe We should add a developer guide to make it easier for people to integrate HTrace into their applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-349) htrace-core4 implementation should use JDK7 try-with-resources
[ https://issues.apache.org/jira/browse/HTRACE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-349: Issue Type: Improvement (was: Bug) > htrace-core4 implementation should use JDK7 try-with-resources > -- > > Key: HTRACE-349 > URL: https://issues.apache.org/jira/browse/HTRACE-349 > Project: HTrace > Issue Type: Improvement > Components: core >Affects Versions: 4.1 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Minor > Fix For: 4.1 > > Attachments: HTRACE-349.patch.txt > > > Absent excellent documentation, people will be looking at the internal code > for examples and guidance. We should use try-with-resources where possible to > keep code clean and concise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-349) htrace-core4 implementation should use JDK7 try-with-resources
[ https://issues.apache.org/jira/browse/HTRACE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-349. - Resolution: Fixed Fix Version/s: 4.1 Target Version/s: 4.1 > htrace-core4 implementation should use JDK7 try-with-resources > -- > > Key: HTRACE-349 > URL: https://issues.apache.org/jira/browse/HTRACE-349 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.1 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Minor > Fix For: 4.1 > > Attachments: HTRACE-349.patch.txt > > > Absent excellent documentation, people will be looking at the internal code > for examples and guidance. We should use try-with-resources where possible to > keep code clean and concise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HTRACE-349) htrace-core4 implementation should use JDK7 try-with-resources
[ https://issues.apache.org/jira/browse/HTRACE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe updated HTRACE-349: Assignee: Mike Drob > htrace-core4 implementation should use JDK7 try-with-resources > -- > > Key: HTRACE-349 > URL: https://issues.apache.org/jira/browse/HTRACE-349 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.1 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Minor > Attachments: HTRACE-349.patch.txt > > > Absent excellent documentation, people will be looking at the internal code > for examples and guidance. We should use try-with-resources where possible to > keep code clean and concise. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HTRACE-348) loadSamplers error message cites SpanReceiver instead of Sampler
[ https://issues.apache.org/jira/browse/HTRACE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe resolved HTRACE-348. - Resolution: Fixed Fix Version/s: 4.2 Target Version/s: 4.2 Committed, thanks [~mdrob]. > loadSamplers error message cites SpanReceiver instead of Sampler > > > Key: HTRACE-348 > URL: https://issues.apache.org/jira/browse/HTRACE-348 > Project: HTrace > Issue Type: Bug > Components: core >Affects Versions: 4.1 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 4.2 > > > Tracer.java error message cites SpanReceiver instead of Sampler -- This message was sent by Atlassian JIRA (v6.3.4#6332)
