Jersey Client closing InputStream response - does it really work?

Question

I am using Jersey Client v2.16 (a transitive dependency of Dropwizard 0.8.0, which I am using, too).

I am somehow puzzled by the closing mechanism of a response when the entity is read as an InputStream. The documentation states:

Also if the entity is read into an InputStream (by response.readEntity(InputStream.class)), the connection stays open until you finish reading from the InputStream. In that case, the InputStream or the Response should be closed manually at the end of reading from InputStream.

However, when I get the response entity using Response.readEntity(InputStream.class), what I end up with is an instance of org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream which, as the name suggest, does not release anything beneath it when the close() method is being called (breaking the InputStream contract, I might say). This is the close() method:

@Override
public void close() throws IOException {
    if (LOGGER.isLoggable(Level.FINE)) {
        LOGGER.log(Level.FINE, LocalizationMessages.MBR_TRYING_TO_CLOSE_STREAM(reader.getClass()));
    }
} 

As a consequence, I end up with HTTP connections in my pool being unreleased and slowly filling the pool.

Given that it might not be very easy to get hold of a reference to the response, and that the official docs state the InputStream **or** the Response should be closed manually, how do I manage to actually release the physical resource?

Answer 1

Looks like this is a known bug with Jersey Client, it appears to be fixed in 2.21 according to https://java.net/jira/browse/JERSEY-2878 and https://github.com/jersey/jersey/releases/tag/2.21