HttpClient API usage feedback/questions

[Jaikiran Pai]

Hi Chris,

On 06/06/18 5:04 PM, Chris Hegarty wrote:
> Jaikiran,
>
>
>> 3. Is the latest API javadoc this one[2]? Based on what I read and experimented so far, I don't see a way to set a value for User-Agent at the HttpClient level. Unless of course, I'm expected to keep setting it on each request that I build in the application? Given that typically, the user agent doesn't change across requests for a particular client, would it be feasible to introduce a way to set this up for each HttpClient?
> The following issue tracks a request to be able to set the User-Agent.
>    https://bugs.openjdk.java.net/browse/JDK-8203771
>
> Since this is not likely a common operation then setting it through a
> specific request header should be sufficient. If experience shows it to
> be a pain point then an HttpClient-level configuration could be added in
> the future.
I'll keep a watch on that JIRA and try it out once it's fixed. I would 
have liked it to be a client instance level configuration, but given 
that it can still be made to functionally work by setting at per request 
(once that issue is fixed), I think it's fine for now as you say.

>
>> How long are these (internal) resources maintained?
> It is implementation specific. Depends on the protocol, HTTP/1.1 or
> HTTP/2. The HTTP/1.1 keep-alive timeout can be set through the
> JDK-specific system property, `jdk.httpclient.keepalive.timeout`. The
> default timeout is 1200 seconds, and can be large(ish) since the
> underlying channel remains registered with the selector and therefore
> observes closures.
Thanks for those details.

>
>> The reason I ask is, I don't see a "close()" kind of API on the HttpClient. Does it mean that the internal resource management isn't expected to be tied to the usage of the HttpClient instance?
> Having an explicit close on such an asynchronous API is problematic; how
> does one know when to call close? As such there is no explicit way to
> close an HttpClient, instead all resources associated with a client
> instance are automatically cleaned up, through a java.lang.ref.Cleaner,
> when the HttpClient is eligible for Cleaning.
I was imagining creating and using a single instance of an HttpClient 
across an "logical application context" given that it is thread-safe. 
That way any resources (like connections) get shared. At least in the 
case I had in mind, the application context has a proper lifecycle where 
it gets stopped/closed when it's done without relying on GC to finalize 
it. So I was wondering if I could pro-actively close the HttpClient 
instance too, in that lifecyle. But if GC is when these resources get 
released, that's fine too, I guess. I don't really think it is a 
problem, I just wanted to be aware a bit about the resource management 
expectations (if any) as a user of the API.

> We continue to develop the latest HTTP Client code in the sandbox [1],
> and expect to bring a number of changes into the mainline, jdk/jdk repo,
> soon.
>
>
> [1] http://openjdk.java.net/groups/net/httpclient/

Thank you. If time permits, I might try some of my integration work with 
this latest code before it comes in as part of the EA release of JDK.

-Jaikiran