4

I want to use so called "new HttpClient since Java 11" java.net.http.HttpClient.

To me, it is very important to make sure that the TCP connection gets closed after an HTTP roundtrip completes, so that corresponding port gets released and resources - deallocated.

There is no .close() or .disconnect() or something like that available on the API.

It is very weird not to have a possibility to close the connection, and it is also weird why the expected behaviour (what is happening? is the connection getting closed automatically? when? how?) is never documented anywhere, including Introduction to the Java HTTP Client and Examples and Recipes .

Any tips?

Giorgi Tsiklauri
  • 9,715
  • 8
  • 45
  • 66
  • https://stackoverflow.com/questions/53617574/how-to-keep-connection-alive-in-java-11-http-client may help – tgdavies Jun 13 '23 at 11:07
  • 2
    But why do you think this is important? – tgdavies Jun 13 '23 at 11:08
  • 1. Provided link doesn't help as it answers different question (although I still got some information from that post.. so, thanks); 2. Because, as I said, I want to make sure previously allocated ports/resources get released.. leaving connection, in the connection pool, by default for 20 minutes and having no way to close connection is beyond crazy. – Giorgi Tsiklauri Jun 13 '23 at 11:12
  • [HttpResponse.BodySubscriber](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpResponse.BodySubscriber.html) talks about closing underlying connections, but there doesn't seem to be any way of explicitly doing so for now, as stated with the Holger's answer. – M. Prokhorov Jun 13 '23 at 11:24

1 Answers1

6

This is indeed a missing feature and you’ll have to wait for Java 21 to be able to close HttpClient explicitly.

See bug report JDK-8304165, “Support closing the HttpClient by making it auto-closable”:

Make the java.net.http.HttpClient implement AutoCloseable in order to make it possible to reclaim its resources early (selector, idle connections sitting in pools, etc...) rather than having to wait for GC to garbage collect it.

It has the status “Approved” and Fix Version 21. You can also verify with the early access documentation of HttpClient which shows that it now implements AutoCloseable and therefore has a close method which also says “Since: 21”.

Holger
  • 285,553
  • 42
  • 434
  • 765
  • Yes, I found that link, but still decided to ask, because 1) I really couldn't imagine any (especially - new) HTTP client being implemented without `.close()`, and 2) Bug page's summary mentions "in order to make it possible to reclaim its resources early" - so, I thought it was reclaiming resources in some "later" way.. but not as later as [after 20 minutes](https://stackoverflow.com/a/53620696/1553537). Great.. introducing a lot of unnecessary and decorative JEPs, while having "new and cool" HTTP client without basic and super important `.close()` ability.. and that's since Java 11, 2018. – Giorgi Tsiklauri Jun 13 '23 at 13:23
  • 2
    I know exactly how you feel. I’m waiting for a possibility to close a `MappedByteBuffer` for twenty years now. There will be an indirect solution through JEP 434, which is still in preview… – Holger Jun 13 '23 at 13:32