We observed a connection leak in our dropwizard service, using jersey-client 2.41 to call an endpoint with chunked encoding. The code receives a ChunkedInput, processes it, then closes it. We expected this would be sufficient to close the underlying input stream and release the connection, but open connections just increase until the pool is exhausted.
I reproduced the issue here and raised a dropwizard issue. Steffen's reply clearly laid out the reasons for the behaviour (I won't add noise here). This situation seems to be by design in Jersey, specifically jersey-common 2.41.
We can release the resources by returning both a ChunkedInput and a Response object, and closing both. But this seems inconsistent with other parts of the API and the spec where closing an underlying input will have the same effect. I'm not necessarily asking you to change anything, but would be interested in your thoughts on what Steffen said.
Hi folks,
We observed a connection leak in our dropwizard service, using
jersey-client 2.41to call an endpoint with chunked encoding. The code receives aChunkedInput, processes it, then closes it. We expected this would be sufficient to close the underlying input stream and release the connection, but open connections just increase until the pool is exhausted.I reproduced the issue here and raised a dropwizard issue. Steffen's reply clearly laid out the reasons for the behaviour (I won't add noise here). This situation seems to be by design in Jersey, specifically
jersey-common2.41.We can release the resources by returning both a
ChunkedInputand aResponseobject, and closing both. But this seems inconsistent with other parts of the API and the spec where closing an underlying input will have the same effect. I'm not necessarily asking you to change anything, but would be interested in your thoughts on what Steffen said.Thanks!