[
https://issues.apache.org/jira/browse/HTRACE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326661#comment-14326661
]
Colin Patrick McCabe commented on HTRACE-109:
---------------------------------------------
A more detailed description:
So one problem we've had is that we didn't have any way to start htraced on a
random (i.e. ephemeral) port. This resulted in a lot of "port in use" errors
during tests, since our tests were using fixed ports. So you couldn't run
tests concurrently. Another related problem we had was that the tests were not
waiting until HTraced's REST interface was up before sending data to it. So
there was a race condition depending on how fast the REST interface started up.
This patch adds a new "startup notification" system to htraced that solves both
these problems. Basically, you can optionally pass a parameter to htraced
{{\-Dstartup.notification.address}} which contains a TCP host:port pair where
htraced will send some JSON data once it starts up. The unit tests now open a
port and tell the htraced child process to send its startup data there. The
JSON data is in the StartupNotification struct. It currently contains the HTTP
(i.e. REST) address, and the process ID.
This solves the "startup race" problem because htraced doesn't send this
information until the REST server is started. It obviously solves the fixed
ports issue as well... since we now just use ephemeral ports all the time.
I added some more debug logging to {{rest.go}} to help diagnose any future
issues. Mainly, it's debug logging on certain requests. I also added a
handler that logs POST requests to an unknown URL.
In MilliSpan.java, I made MilliSpan#Builder default the parents array to an
empty array, to address stack's TODO. :)
I added a {{TestUtil#waitFor}} function which is similar to the one in Hadoop.
It it used to loop until a condition is true, essentially.
TestHTracedProcess.java: we need to use {{Process#waitFor}} rather than
{{Process#exitValue}}. {{exitValue}} doesn't wait for the process to finish...
and if you call {{exitValue}} before the process is finished, you get an error.
HTracedRESTReceiver: I had to make some fixes here too. We want to send spans
if they get "too old"... i.e., we don't want spans hanging around in the buffer
for hours, even if we don't have enough to send the maximum amount. I changed
this from relying on a {{BlockingQueue}} to using a {{Condition}} variable and
a {{ReentrantLock}}. This will give us more control over when the thread runs.
> fix TestHTracedRESTReceiver unit test failures
> ----------------------------------------------
>
> Key: HTRACE-109
> URL: https://issues.apache.org/jira/browse/HTRACE-109
> Project: HTrace
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Priority: Critical
> Attachments: HTRACE-109.001.patch
>
>
> Fix some issues with HTracedRESTReceiver that are resulting in unit test
> failures.
> So there were two main issues:
> better way to launch htraced
> fixes to the HTracedRESTReceiver logic
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
