[
https://issues.apache.org/jira/browse/HTRACE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283492#comment-14283492
]
Colin Patrick McCabe edited comment on HTRACE-51 at 1/20/15 6:39 AM:
---------------------------------------------------------------------
Nice
OK, bikeshed time :)
Conf key names: it would be nice to include "htraced" in these somewhere.
Also, I don't think we need "htrace" in them since Hadoop and HBase will be
namespacing them anyway... i.e. Hadoop sends htrace.hadoop.foo -> foo. So we
don't really want users to enter htrace.hadoop.htrace.client.rest.timeout.ms,
etc.
I would suggest: {{htrace.client.rest.timeout.ms}} -> {{rest.rpc.timeout.ms}}
Then Hadoop gets {{htrace.hadoop.rest.rpc.timeout.ms}}
{{htrace.client.rest.htraced.port}}: I would suggest not having this, but
instead just having something like {{htraced.address}} which is hostname:port,
and gives both the address and the port in one.
{{htrace.client.rest.q.capacity}} -> {{htraced.queue.capacity}} ?
{{htrace.client.reset.period.seconds}}: should this be in ms? Also, maybe this
should have a name with "maximum" in it somewhere since we may send earlier if
we fill up (see below)
{{htrace.client.rest.max.spans.at.a.time}} -> {{rest.rpc.max.spans}} ?
{code}
+ // TODO: Make this configurable.
+ private final int maxToSendAtATime;
{code}
TODO is TODONE
One thing that would be nice is if we fill up the queue, we should wake the
PostSpans thread early rather than waiting for it to wake up on its own. If
you want to do this in a follow-on, that's fine too. You could probably do
this with BlockingArrayQueue by just leaving the PostSpans thread running all
the time, and having its decision to send a message be based on either enough
time going by, or enough spans being received. You need to use the
GetWithTimeout or whatever it's called.
was (Author: cmccabe):
Nice
OK, bikeshed time :)
Conf key names: it would be nice to include "htraced" in these somewhere.
Also, I don't think we need "htrace" in them since Hadoop and HBase will be
namespacing them anyway... i.e. Hadoop sends htrace.hadoop.foo -> foo. So we
don't really want users to enter htrace.hadoop.htrace.client.rest.timeout.ms,
etc.
I would suggest: {{htrace.client.rest.timeout.ms}} -> {{rest.rpc.timeout.ms}}
Then Hadoop gets {{htrace.hadoop.rest.rpc.timeout.ms}}
{{htrace.client.rest.htraced.port}}: I would suggest not having this, but
instead just having something like {{htraced.address}} which is hostname:port,
and gives both the address and the port in one.
{{htrace.client.rest.q.capacity}} -> {{htraced.queue.capacity}} ?
{{htrace.client.reset.period.seconds}}: should this be in ms? Also, maybe this
should have a name with "maximum" in it somewhere since we may
{{htrace.client.rest.max.spans.at.a.time}} -> {{rest.rpc.max.spans}} ?
{code}
+ // TODO: Make this configurable.
+ private final int maxToSendAtATime;
{code}
TODO is TODONE
One thing that would be nice is if we fill up the queue, we should wake the
PostSpans thread early rather than waiting for it to wake up on its own. If
you want to do this in a follow-on, that's fine too. You could probably do
this with BlockingArrayQueue by just leaving the PostSpans thread running all
the time, and having its decision to send a message be based on either enough
time going by, or enough spans being received. You need to use the
GetWithTimeout or whatever it's called.
> htraced java REST client (a.k.a java SpanReceiver for htraced)
> --------------------------------------------------------------
>
> Key: HTRACE-51
> URL: https://issues.apache.org/jira/browse/HTRACE-51
> Project: HTrace
> Issue Type: New Feature
> Reporter: stack
> Assignee: stack
> Attachments: 51.txt, 51.txt, 52v2.txt
>
>
> Add a java REST client for htraced so we can build a receiver that writes
> htraced via REST from a java process.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
