title: Jersey Client closing InputStream response - does it really work?
body: <p>I am using Jersey Client v2.16 (a transitive dependency of Dropwizard 0.8.0, which I am using, too).</p>
  
  <p>I am somehow puzzled by the closing mechanism of a response when the entity is read as an <code>InputStream</code>. The <a href="https://jersey.java.net/documentation/latest/client.html#d0e5069" rel="noreferrer">documentation</a> states: </p>
  
  <blockquote>
    <p>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. </p>
  </blockquote>
  
  <p>However, when I get the response entity using <code>Response.readEntity(InputStream.class)</code>, what I end up with is an instance of <code>org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream</code> which, as the name suggest, does not release anything beneath it when the <code>close()</code> method is being called (breaking the <code>InputStream</code> contract, I might say). This is the <code>close()</code> method:</p>
  
  <pre><code>@Override
  public void close() throws IOException {
      if (LOGGER.isLoggable(Level.FINE)) {
          LOGGER.log(Level.FINE, LocalizationMessages.MBR_TRYING_TO_CLOSE_STREAM(reader.getClass()));
      }
  } 
  </code></pre>
  
  <p>As a consequence, I end up with HTTP connections in my pool being unreleased and slowly filling the pool.</p>
  
  <p>Given that it might not be very easy to get hold of a reference to the response, and that the official docs state <code>the InputStream **or** the Response should be closed manually</code>, how do I manage to actually release the physical resource?</p>