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)