jdk-connector treats read timeout as a response timeout

[nicobrevin]

The jdk-connector respects the client config option for read timeout, but it doesn't treat is as a socket read timeout (which the default connector does ¹, it applies it to reading the response as a whole. I can see if applying the read timeout to a response timeout field, which is set² once the response has been parsed and the response body starts being processed.

I hit the issue when trying to GET a large entity using the jdk-connector ( See also #5470 )

I guess the bug is two things:

• The read timeout needs to be applied closer to the original semantics of a synchronous read timeout. I guess the response as a whole would fail if someone is blocking on the request and there's no activity on the socket for a certain amount of time?
• The response timeout should be set via a clearly marked setting, e.g. RESPONSE_TIMEOUT :)

Footnotes

1. See org.glassfish.jersey.client.internal.HttpUrlConnector.class#_apply:L379 ↩

2. Happens in org.glassfish.jersey.jdk.connector.internal.HttpConnection.class#handleHeaderSent:L145 ↩