I have an ApacheClient in some of my integration t...
# http4k
I have an ApacheClient in some of my integration tests for a streaming server. The server will never close the stream autonomously unless there is an error, so in the tests I wait for a number of messages and then close the response. However the call to close of the response body hangs on reading the socket. It would appear that some handshake is not working.
Copy code
val client: HttpHandler = ApacheClient(responseBodyMode = BodyMode.Stream)
        client(invoke(Method.GET, url)).use { response ->
            assertEquals(Status.OK, response.status)
            validateReadings(response, 1, instant(from), instant(to))
@Sandyzwin6 are you consuming the response body in your test? In our experience one doesn’t need to explicitly close connections to get both streaming and resource management to work correctly
Yes the validateReadings function reads from the resource,
It just seems strange that using
on a Closeable, which is the normal pattern and AFAIK the contract of a Closeable, does not close the resource but hangs. I can simply ignore this because it is only a test and what I actually want to test works fine, but to be honest this doesn't seem right.
In this case it’d help to see an example of the server code that reproduces the behaviour you’re seeing
There shouldn’t be a need for the “use” because the underlying apache client will manage the resources for you
Another thing you can try is replacing client/server implementations to see if the behaviour remains the same.
That's not the point is it? A response is a closeable I should be able to close it surely?
I can't change the server implementation.
Ah! If the server is not http4k, then I suggest trying with another underlying client (okhttp is what we’ve been using the most recently)
The server is a SpringBoot Application using some
Copy code
So looking for the reason in that stuff will be like looking for a needle in a haystack. Why use Spring? Why Indeed... Not my choice :-(
😞 1
3 things you can try: 1. Like I said, check if the same happens with a different http4k client 2. Temporary disable streaming 3. Remove the “use” (as it may be trying to close an already closed stream and that case may not be handled correctly somewhere)