Thanks Gary.

On Fri, Feb 3, 2017 at 1:54 AM, Gary Brown <gbrown@redhat.com> wrote:

> (1) Is using a "sampling.priority" of 1 merely advisory? It would explain
> everything if those traces are meant to be dropped.

If using the default constructor for APMTracer, then the default behaviour should be to trace all - and setting the sampling.priority to 1 should not override that. Could you try not setting this tag to see if there is any difference?

I see. Well, I am using the default constructor, and I have tried with and without sampling.priority=1 and it's the same situation either way.

> (2) Is there any convenient way I can see, with increased logging or
> something, which traces are actually being sent from the client, and which
> are actually received by the server?

You could initially check the traces stored in Elasticsearch using something like: curl http://localhost:9200/apm-hawkular/trace/_search | python -m json.tool

Right now I have a repl launched with HAWKULAR_APM_LOG_LEVEL set to FINEST. I'm creating spans in the repl as described earlier. Each time I create a trace I see a log entry from the client like this:

FINEST: [TracePublisherRESTClient] [Thread[pool-2-thread-1,5,main]] Status code is: 204

and that 204 would suggest the trace info was successfully sent. But inside the docker container I can curl Elasticsearch and those new traces are not to be found.

Incidentally, I started the repl last night, did a few successful tests, and then closed the lid of my laptop for the night with the Hawkular container still running and the repl still running. I've also had this issue occur immediately on launch of the repl, so I don't think it's specifically about long running repls and/or sleeping, but for completeness I thought I would clarify how I am running this.

> Do you have a pure Java example that reproduces the same issue? Might be worth creating a jira in https://issues.jboss.org/projects/HWKAPM to track the issue.

No, not yet...