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
