Splunk Observability Cloud

SignalFlow "CRLF expected at end of chunk"

JohnGregg
Path Finder

My SignalFlow queries consistently end with "org.apache.http.MalformedChunkCodingException: CRLF expected at end of chunk."

My code is similar to the example here: https://github.com/signalfx/signalflow-client-java

I create the transport and client, then go in a loop an execute the same query once per iteration with an updated start time each time.  I read all the messages in the iterator, though I ignore some types.  I close the computation at the end of each iteration.

The query seems to work fine.  I get the data I expect.

The stack trace looks like this:

Jun 27, 2025 4:33:16 PM com.signalfx.signalflow.client.ServerSentEventsTransport$TransportEventStreamParser close
SEVERE: failed to close event stream
org.apache.http.MalformedChunkCodingException: CRLF expected at end of chunk
at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:250)
at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:222)
at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:183)
at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:210)
at org.apache.http.impl.io.ChunkedInputStream.close(ChunkedInputStream.java:312)
at org.apache.http.impl.execchain.ResponseEntityProxy.streamClosed(ResponseEntityProxy.java:142)
at org.apache.http.conn.EofSensorInputStream.checkClose(EofSensorInputStream.java:228)
at org.apache.http.conn.EofSensorInputStream.close(EofSensorInputStream.java:172)
at java.base/sun.nio.cs.StreamDecoder.implClose(StreamDecoder.java:377)
at java.base/sun.nio.cs.StreamDecoder.close(StreamDecoder.java:205)
at java.base/java.io.InputStreamReader.close(InputStreamReader.java:192)
at java.base/java.io.BufferedReader.close(BufferedReader.java:525)
at com.signalfx.signalflow.client.ServerSentEventsTransport$TransportEventStreamParser.close(ServerSentEventsTransport.java:476)
at com.signalfx.signalflow.client.ServerSentEventsTransport$TransportChannel.close(ServerSentEventsTransport.java:396)
at com.signalfx.signalflow.client.Computation.close(Computation.java:168)
my code here

 Should I be doing something different?

thanks

Labels (1)
0 Karma

bishida
Splunk Employee
Splunk Employee

Hi,

This is a bit of a guess—but maybe it will spark some ideas to try. I wonder if closing the computation inside of the loop is not giving the server enough time to send it’s final response. It might be worth trying introducing some delay before closing or maybe try using a “try/catch” approach when closing the computation.

0 Karma

JohnGregg
Path Finder

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

0 Karma

JohnGregg
Path Finder

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

 

0 Karma
Get Updates on the Splunk Community!

What’s New & Next in Splunk SOAR

Security teams today are dealing with more alerts, more tools, and more pressure than ever.  Join us on ...

Your Voice Matters! Help Us Shape the New Splunk Lantern Experience

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...

September Community Champions: A Shoutout to Our Contributors!

As we close the books on another fantastic month, we want to take a moment to celebrate the people who are the ...