[
https://issues.apache.org/jira/browse/HTRACE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349893#comment-14349893
]
Colin Patrick McCabe commented on HTRACE-133:
---------------------------------------------
I added a unit test for this.
I also verified that with this patch, the spans from "hadoop fs -ls /" are
captured by htraced, whereas without them, only the NameNode-side spans are
captured.
Miscellanea:
* Reduce the close log from INFO to DEBUG (we don't want to spam command-line
programs like the hadoop shell)
* Split {{client.rest.timeout.ms}} into {{client.connect.timeout.ms}} and
{{client.idle.timeout.ms}}... I hate timeout configurations that control
multiple separate things, and we should do this now before we get the
compatibility albatross around our necks.
> HTracedRESTReceiver drops spans when close() is called
> ------------------------------------------------------
>
> Key: HTRACE-133
> URL: https://issues.apache.org/jira/browse/HTRACE-133
> Project: HTrace
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments:
> 0001-HTRACE-133.-HTracedRESTReceiver-drops-spans-when-clo.patch
>
>
> HTracedRESTReceiver drops spans when close() is called. The close()
> operation should trigger buffered spans to be sent, and block for a bit to
> give them a chance to be sent. This way we will capture output from
> short-lived command-line programs like Hadoop's FsShell.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
