[
https://issues.apache.org/jira/browse/HTRACE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056767#comment-15056767
]
stack commented on HTRACE-329:
------------------------------
bq. I can see how it would be frustrating to have to figure out the
one-character labels the first time around.
Yes, and then every subsequent time you put htrace aside and then come back to
it after some time has passed ("What was what again?").
bq. We do use multi-character labels in every other place in our JSON and RPC
system, since efficiency is not such a big deal in those other places.
Sorry. What does this refer too?
bq. Just to be clear, msgpack doesn't do any kind of compression on strings. If
you store "foobar" as a string in msgpack, it's just those ASCII bytes, same as
in JSON.
You are right. I misread its encoding scheme.
bq. The Backbone objects wrapping the span JSON are implemented, check span.js.
Thanks. Doesn't help w/ JSON handling in all other places outside UI.
bq. Maybe what we really need is a pretty-printer for spans?
Nah. Not unless every place you can pass a one-byte label, you also can pass
the pretty-print (unlikely to be done consistently across all modules).
bq. There are a lot of other things that would tend to "confound" casual
readers...
Two wrongs...
bq. ....like the fact that our date format is UTC milliseconds since the
epoch...
This is not that unusual....and besides, another issue altogether.
bq. We could have an option for the LocalFileSpanReceiver to output the pretty
format as well, for debug purposes.
Nah. I'd have to turn it on. And if I'm debugging another receiver altogether,
it doesn't help...: i.e. local file span receiver works but why doesn't my
trace show up in the remote htraced instance's UI?
Your reluctance to change [~cmccabe] is some notion of possible performance
lost (if noticeable at all, it'd be in the low single digits and one day we'll
encode and compress this away anyways?) or stored size of traces (10-15% more
at the most in an era of big disk and again, we'll encode and/or compress the
difference away)?
This is not a dev-only tool. It is for operators and supporters. Make it easier
on such casual users, especially for the case where they are getting started or
their interaction is intermittent.
I can put up a patch if you relax your objection.
> JSON labels are opaque and so confound
> --------------------------------------
>
> Key: HTRACE-329
> URL: https://issues.apache.org/jira/browse/HTRACE-329
> Project: HTrace
> Issue Type: Improvement
> Reporter: stack
>
> Debugging, I get this in the log:
> {code}
> 2015-12-09 21:56:21,293 ERROR [localhost:61345.activeMasterManager]
> core.Tracer: Can't close TraceScope for
> {"a":"b45638d30b8c6e1dbdc001c6e7f1dd8f","b":1449726980426,"d":"get","r":"hconnection-0x6a38397","p":["b45638d30b8c6e1dbd33cf6dc5ce5206"]}
> because it is not the current TraceScope in thread
> localhost:61345.activeMasterManager
> {code}
> I could go consult a dictionary if such a thing existed on the htrace website
> (currently it does not) or go read up on some source code... but this is JSON
> so a.) perf is not a consideration so why bother shortening the labels in the
> name of 'perf' benefits and b.) JSON is ".. easy for humans to read and
> write." (second sentence on the website) yet here were are frustrating the
> first half of this sentence.
> Suggest more readable labels.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
