I run a Java web service at my workplace which uses JerseyClient to make HTTP requests. A few weeks ago we switched the default connector implementation with ApacheConnector and our server stopped handling requests after some time due to threads getting stuck. The issue was exactly same as described here - https://github.com/eclipse-ee4j/jersey/issues/3772. We were running a pretty outdated version of Jersey - 2.19. We fixed the issue by using a higher version of Jersey where this bug was fixed. However, I am still curious as to why things broke and want to understand them better.
According to the conversation on the GitHub issue, the problem is due to a bug in Jersey code wherein response.close() is not called.
This comment on the commit which fixes the issue says -
2 years down the line and because of a missing
response.close()in previous versions of Jersey in a finally block, the pooled http connection was never released. Our leased http connections never were returned to the pool because response wasn't being explicitly read into entities in some cases.
I don't understand what this means. I want to understand how does this bug work. Why do threads get stuck? Why is it important to call response.close(). What does response.close() do? What scenarios does the bug surface in? (because my server did not die outright, it was fine for a few days then broke).
I was able to reproduce this issue when I artificially injected high latency in the calls made by Jersey (we have a tool at work which can intercept packets and hold them for a set amount of time, so the application perceives that as latency in the response of the call). Which led to a javax.ws.rs.ProcessingException with "Read timed out". Why did this experiment reproduce the issue?
Thanks!