> Can anyone advise? We're currently trying to workaround (by not calling "close"!).
What do you mean by this?
The recommendation for Servlets is to never call flush before returning from your dispatch.
That allows the Servlet Container itself to threadlessly handle flush and not have to keep a thread open to the Servlet waiting for the connection to flush completely.
The only semi-valid case for using Close on the streams from a Request or Response is an extreme error condition.
And even so, using close is not the correct way to do that, as it doesn't address the buffers properly.
Jetty has a non-spec feature where you can call
HttpServletRespons.sendError(-1) to trigger a low level harsh abort of the connection/channel, and allow the buffers and everything else to cleanup properly.
If you want the connection to close after the response, it's the Servlet's responsibility to add `response.setHeader("Connection", "close")` before the response is committed.
This allows the Servlet Container to continue the flush (hopefully its threadless because you returned from dispatch without a flush call), and when the final flush is complete begin the closure of the connection (which is different in HTTP/1.1 vs HTTP/2 vs HTTP/3)
Otherwise you never want to close, as that's HTTP/1.0 only behavior and is absolutely horrible for your users, your apache frontend, your OS resources, your JVM resources, etc.
When HTTP/1.1 came out, it was persistent by default. Even the old school `Connection: keep-alive` was deprecated and has no meaning when using HTTP/1.1 (the 'keep-alive' token is intentionally undefined in HTTP/1.1).
With HTTP/2+ things get even more subtle, as starting with HTTP/2 the `Connection: close` header now has no meaning (the 'close' token is intentionally undefined in HTTP/2), there's other ways to abort a connection in HTTP/2 (and HTTP/3).
In short, If you are using .flush() or .close() on any Servlet stream/reader/writer, stop doing that, you are doing far more harm than good.