[ 
https://issues.apache.org/jira/browse/HTRACE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056641#comment-15056641
 ] 

Colin Patrick McCabe commented on HTRACE-329:
---------------------------------------------

I can see how it would be frustrating to have to figure out the one-character 
labels the first time around.  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.

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.  The only difference is that JSON will have the quotes around the 
string, whereas msgpack uses (essentially) a length prefix.

The Backbone objects wrapping the span JSON are implemented, check {{span.js}}.

Maybe what we really need is a pretty-printer for spans?  There are a lot of 
other things that would tend to "confound" casual readers, like the fact that 
our date format is UTC milliseconds since the epoch (not exactly friendly to 
newbies).  We could have an option for the LocalFileSpanReceiver to output the 
pretty format as well, for debug purposes.

> 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)

Reply via email to