So a bug I've found is that

ApacheClient

will just stop querying large files (3Mb) and not close the connection. This leads to thread starvation and eventually an unresponsive app.

val client = ApacheClient(responseBodyMode = BodyMode.Stream, client = HttpClients.custom()
    .setDefaultRequestConfig(RequestConfig.custom()
        .setCookieSpec(CookieSpecs.IGNORE_COOKIES)
        .setConnectTimeout(3000)
        .setSocketTimeout(3000)
        .build())
    .setMaxConnTotal(10)
    .build())

I'm just piping the resulting stream directly into a response, and when I augmented the ReadCalls with some printlns, they just suddenly stop after a while - and then my app freezes. Edit: It can also happen on smaller files. What's important is that the connection doesn't appear to be closed.

hey. could you isolate this into a test case so.we can take a.oser look?

It appears that sometimes http4k isn't closing the streams that are passed to it in a Repsone. Any ideas what could cause this? Reproducers have not managed to reproduce the bug, were still working on it.

in a proxy scenario the only places which even have anything to do with streams (other than passing the reference) are the edges - ie the http client and the ServerConfig layer.

@Quy D X Nguyen if you don’t consume the response body from the server it may keep the client thread indefinitely, which would explain your issue. I’d look for any conditions (exception or business logic) that would cause you to not read the response body, even for a subset of your requests.

It turns out that the default max connections for apacheclient is 2, and long lasting downloads along with a large number of incoming connections causes Netty to deadlock.