Klient sieci Jersey zamykający odpowiedź InputStream - czy to naprawdę działa?

Question

Korzystam z klienta usługi Jersey Client v2.16 (przejściowa zależność od Dropwizard 0.8.0, której również używam).

Jestem w pewien sposób zaintrygowany mechanizmem zamykającym odpowiedź, gdy jednostka jest odczytywana jako InputStream. W documentation stany:

także wtedy, gdy jednostka jest odczytywany w InputStream (przez response.readEntity (InputStream.class)), połączenie pozostaje otwarty aż do zakończenia czytania od InputStream. W takim przypadku InputStream lub Response powinny zostać zamknięte ręcznie na końcu odczytu z InputStream.

Jednak kiedy się podmiot odpowiedzi korzystając Response.readEntity(InputStream.class), co mam skończyć z jest instancją org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream które, jak sama nazwa wskazuje, nie ma nic pod nim zwolnić gdy metoda close() jest nazywany (łamiąc InputStream kontrakt, mogę powiedzieć). Jest to metoda close():

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

W konsekwencji, kończę z połączeń HTTP w moim basenie jest niepublikowany i powoli napełniania basenu.

Biorąc pod uwagę, że uzyskanie referencji do odpowiedzi może nie być łatwe, a oficjalny dokument mówi: the InputStream **or** the Response should be closed manually, w jaki sposób mogę faktycznie uwolnić zasoby fizyczne?

Answer 1

Wygląda na to, że jest to znany błąd z Jersey Klienta, wydaje się być ustalona w 2,21 według https://java.net/jira/browse/JERSEY-2878 i https://github.com/jersey/jersey/releases/tag/2.21