Looks like my calculations were warped by this bug: https://bugs.openjdk.org/browse/JDK-8307488?force_isolation=true When I throw out of first sample of each thread, the results make a lot more sense. ... View more

Ok, I'm pretty sure my theory is right. Look at this stack trace: at org.apache.http.impl.BHttpConnectionBase.close(BHttpConnectionBase.java:317) at org.apache.http.impl.conn.LoggingManagedHttpClientConnection.close(LoggingManagedHttpClientConnection.java:81) at org.apache.http.impl.execchain.ConnectionHolder.releaseConnection(ConnectionHolder.java:103) at org.apache.http.impl.execchain.ConnectionHolder.close(ConnectionHolder.java:156) at org.apache.http.impl.execchain.HttpResponseProxy.close(HttpResponseProxy.java:62) at com.signalfx.signalflow.client.ServerSentEventsTransport$TransportChannel.close(ServerSentEventsTransport.java:385) at com.signalfx.signalflow.client.Computation.close(Computation.java:168) If you use a debugger to print the identity hashcode of the inBuffer variable that is being cleared on that line, you'll see that it is the same object that is later returning -1 bytes read at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:250), which causes the MalformedChunkCodingException. This is a bug in your SDK. Changing TransportChannel's close() method to be more like this seems to fix the problem: public void close() { super.close(); this.streamParser.close(); try { this.response.close(); } catch (IOException ex) { log.error("failed to close response", ex); } try { this.connection.close(); } catch (IOException ex) { log.error("failed to close connection", ex); } } In that case, the wire logger output shows the trailing chunk: 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "event: control-message[\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "data: {[\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "data: "event" : "END_OF_CHANNEL",[\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "data: "timestampMs" : 1751387752387[\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "data: }[\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "[\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "[\r][\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "0[\r][\n]" 2025-07-01 11:35:52.923 CDT | FINE | org.apache.http.wire | http-outgoing-2 << "[\r][\n]" thanks ... View more

I'm closing the computation in a finally block.  I tried adding up to a 10-second delay but it still fails. In Postman and curl, the stream looks complete.  However when I enable HttpClient wire logging, it looks wrong: 2025-06-30 17:28:40.599 CDT | FINE | org.apache.http.wire | http-outgoing-4 << "event: control-message[\n]" 2025-06-30 17:28:40.599 CDT | FINE | org.apache.http.wire | http-outgoing-4 << "data: {[\n]" 2025-06-30 17:28:40.599 CDT | FINE | org.apache.http.wire | http-outgoing-4 << "data: "event" : "END_OF_CHANNEL",[\n]" 2025-06-30 17:28:40.599 CDT | FINE | org.apache.http.wire | http-outgoing-4 << "data: "timestampMs" : 1751322520099[\n]" 2025-06-30 17:28:40.599 CDT | FINE | org.apache.http.wire | http-outgoing-4 << "data: }[\n]" 2025-06-30 17:28:40.599 CDT | FINE | org.apache.http.wire | http-outgoing-4 << "[\n]" There should be a crlf, followed by a 0 for the end of the chunked stream, followed by another crlf. I looked at your source code.  You have a lot of close() calls in there.  Is it possible the underlying stream is getting closed before HttpClient gets a chance to read the end of the stream?  The only close() I'm doing is on the computation. thanks   ... View more

Thanks.  I'm thinking it might have been a time sync issue.  If I set the start time slightly in the past, like even 1 second, it works. What I've settled on is setting the start time on the minute (no seconds) with the same value for the end time.  That seems to return the single record that I want. thanks ... View more

Thanks, I think you're on to something. In the UI, I set the resolution to low, which was 2 minutes for a 1-hour window.  I changed my query to set the start and end times to the same hour range and set the resolution to 2 minutes (I was using null before.) Now I get matching results. But before I set the resolution, which result was "correct?"  What I'm actually doing is recording metrics like GC counts, CPU usage, etc, during a performance test in LoadRunner so I can use LR's Analysis tool to combine the data LR produces with the data APM produces.  I plan to run the query once per minute as the test runs and grab the most recent minute of data.  Will I actually get the most recent minute?  I'm assuming that since the UI appeared to lag, then the query results are closer to being correct. thanks ... View more

Tried need-props=true.  All it added was Servlet URI, EUM Request GUID, and ProcessID.   thanks   ... View more

No, that's not it.  Thanks ... View more

Look at the JMX MBean browser to confirm the metrics exist.  If they do, look closely at the MBean name and compare with the JMX definition.  I know there are some complaints on StackOverflow about sometimes seeing the domain Tomcat and sometimes Catalina.  If the AppD config expects Catalina but it's actually Tomcat or vice versa, you won't see anything in the metric browser.  You would need to change or duplicate/change the JMX config. ... View more

I'm not aware of any detailed documentation on how the OOTB JMX metrics are defined.  There is some high-level documentation but it's wrong, too.  Regardless, I think I've fixed the JMX configuration but I can't select the new metrics for inclusion in a dashboard. ... View more