You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@htrace.apache.org by "Colin Patrick McCabe (JIRA)" <ji...@apache.org> on 2015/03/06 04:25:41 UTC
[jira] [Commented] (HTRACE-133) HTracedRESTReceiver drops spans
when close() is called
[ 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)