[
https://issues.apache.org/jira/browse/HTRACE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329920#comment-14329920
]
Colin Patrick McCabe commented on HTRACE-112:
---------------------------------------------
This patch gets rid of the background thread. So now we just buffer a bunch
of spans, and then when we have enough, we do a write to the OS. Most of the
time, this write will be to memory rather than disk (OS buffer cache) so it
should be relatively fast.
The rationale for getting rid of the background thread is that since
LocalFileSpanReceiver is intended to be a simple span receiver used mostly for
debugging, the complexity of having a background thread and the associated rate
control does not seem worth it. What do we do if the bg thread falls behind,
etc. etc. seems too complex for this span receiver.
I also used {{writev}}, an OS interface that lets us pass multiple buffers to
the OS in one system call. This allows us to avoid a copy in memory-- rather
than copying the span byte buffers into a bigger byte buffer and calling write
on that, we can call writev on the individual buffers. This should speed up the
flushing process somewhat.
> Fix LocalFileSpanReceiver to avoid BG thread and problems around close()
> ------------------------------------------------------------------------
>
> Key: HTRACE-112
> URL: https://issues.apache.org/jira/browse/HTRACE-112
> Project: HTrace
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
>
> When testing the HDFS client with htrace, LocalFileSpanReceiver was giving me
> "Channel closed" exceptions. I think this is because of a race between
> closing the span receiver and flushing the spans from that receiver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)