[
https://issues.apache.org/jira/browse/AVRO-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890424#action_12890424
]
Patrick Wendell commented on AVRO-595:
--------------------------------------
>> * why is the result of getSpanBlock a byte array rather than an array of
>> spans?
We discussed off-line - going to change this, but may change back if there are
performance benefits.
>> * i don't understand the need for the query handles, and they don't
>> appear to be used for anything yet.
This is just a thought on how we might deal with queries that may persist over
multiple calls. I'll settle this interface as we continue to work on this.
>> * do we want to serve traces on a separate port, or simply on a different
>> url? this seems perhaps outside the scope of the plugin, which should just
>> record the stats, and how they're published might be configured elsewhere?
I think our idea is to have some basic aggregation/viewing of stats included in
the plugin, but also keep things extensible if people want to run their own
analyses.
>> * how bad would a trace ID collision be? RANDOM.nextLong() isn't ideal, but
>> is fast and might be good enough if collisions aren't too terrible. if
>> collisions are to be avoided then it might use something like
>> SecureRandom.nextBytes(new byte[16]).
Collisions won't break the app, but (sampling is only probabilistic, so we
could just toss out traces where collisions happen) - however maybe will just
do this anyways.
> Add Dapper-Style Tracing Plugin to Avro
> ---------------------------------------
>
> Key: AVRO-595
> URL: https://issues.apache.org/jira/browse/AVRO-595
> Project: Avro
> Issue Type: Sub-task
> Reporter: Patrick Wendell
> Assignee: Patrick Wendell
> Attachments: AVRO-595.patch.v1.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
