-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Jetty HttpClient implementation #4180
Conversation
e394b18
to
5b82ae8
Compare
a8c50e1
to
14c5f06
Compare
14c5f06
to
7ef6d3a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good Marc, just a couple comments.
httpclient-jdk/src/main/java/io/fabric8/kubernetes/client/jdkhttp/JdkHttpRequestImpl.java
Outdated
Show resolved
Hide resolved
@Override | ||
public void onContent(Response response, ByteBuffer content) { | ||
try { | ||
consumeLock.await(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the threading model for Jetty? Is it like okhttp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More info is here: https://www.eclipse.org/jetty/documentation/jetty-11/programming-guide/index.html#pg-client-io-arch-network
We can fine-tune pools and so on in our ClientConnector instance.
For me it's unclear what the consume lock does. I expect some timeouts to happen depending on the HttpClient implementation if the lock is kept for too long.
A timeout can be something easy to be added here based on the inherent client timeouts. Also better cancellation support.
|
||
import static io.fabric8.kubernetes.client.utils.HttpClientUtils.applyCommonConfiguration; | ||
|
||
public class JettyHttpClientFactory implements HttpClient.Factory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other factories provide several hooks. Do you prefer something simpler? We could minimize the methods on those factories as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot about this one. Yup, need to add some hook too. Also maybe create an interface to keep things consistent.
httpclient-jetty/src/main/java/io/fabric8/kubernetes/client/jetty/JettyHttpClient.java
Show resolved
Hide resolved
httpclient-jetty/src/main/java/io/fabric8/kubernetes/client/jetty/JettyHttpClient.java
Show resolved
Hide resolved
7ef6d3a
to
9e8ef20
Compare
I'm facing issues with the Exec streamIDs, for some reason they are not OK, and the ExecListener behaves erratically. |
9b2863d
to
99fe926
Compare
3cb5494
to
9f2ff3c
Compare
...es-client-api/src/test/java/io/fabric8/kubernetes/client/http/AbstractWebSocketSendTest.java
Outdated
Show resolved
Hide resolved
// Find a way to stream the response body without completing the future | ||
// We need two signals, one when the response is received, and one when the body is completely | ||
// read. | ||
// Should this method be completely replaced by consumeXxx()? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we'll just need to capture an issue for that. We can provide something like a utility to convert the consumeBytes into a ReadableByteChannel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's two thing here:
- First one is addressing the in-memory load of the response, which I'll fix in a subsequent PR.
- Second is about "merging" the
sendAsync
andconsumeLines
/consumeBytes
since they seem redundant. I guess aligned with your thoughts. An issue for this sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private Origin.Address proxyAddress; | ||
private String proxyAuthorization; | ||
private TlsVersion[] tlsVersions; | ||
// TODO: HTTP2 disabled, MockWebServer support is limited and requires changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't recall if there's anything captured on the expect continue behavior of the mock server - it requires more logic to respond with continue and at least the jdk client won't progress if it doesn't see that response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The handshake is not correctly implemented in the MockServer for non https responses (and probably for https too).
It works for OkHttp, but I'm not sure why (I guess it's more lenient).
I'll create a new issue for this once we merge. I already have some changes on the MockServer, but didn't want to spend more time on it, hence the TODO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...rnetes-client-api/src/test/java/io/fabric8/kubernetes/client/http/AbstractAsyncBodyTest.java
Outdated
Show resolved
Hide resolved
...lient-jdk/src/test/java/io/fabric8/kubernetes/client/jdkhttp/JdkHttpClientAsyncBodyTest.java
Outdated
Show resolved
Hide resolved
9754ce3
to
65b7900
Compare
kubernetes-itests/src/test/java/io/fabric8/kubernetes/PodIT.java
Outdated
Show resolved
Hide resolved
kubernetes-client/src/main/java/io/fabric8/kubernetes/client/BaseClient.java
Show resolved
Hide resolved
65b7900
to
ed7de60
Compare
Signed-off-by: Marc Nuri <[email protected]>
ed7de60
to
8632d4b
Compare
also making jetty consume apply to each message, and removing the okhttp requirement for a newline
8632d4b
to
052ca50
Compare
Kudos, SonarCloud Quality Gate passed! |
Description
feat: Jetty HttpClient implementation
Follow up tasks
MockWebServer HTTP/2 full support #4193
[refactor] Change JettyHttpClient#sendAsync method to not read full response in memory #4201
OkHttp & Jdk HttpClient failed response interceptors don't seem to work withconsumeLines
orconsumeBytes
afterHttpFailureReplacesResponseInConsumeLines();
afterHttpFailureReplacesResponseInConsumeBytes();
SeeOkHttpInterceptorTest
&JdkHttpClientInterceptorTest
AsyncBody.consume
has a confusing and inconsistent behaviorfeat: Jetty HttpClient implementation #4180 (comment)JdkHttpClientAsyncBodyTest
completely disabled due to non-compliance with prepared test casesType of change
test, version modification, documentation, etc.)
Checklist