Skip to content
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

Merged
merged 2 commits into from Jun 10, 2022

Conversation

manusa
Copy link
Member

@manusa manusa commented May 30, 2022

Description

feat: Jetty HttpClient implementation

  • HttpClient Tests
    • Added HttpClient behavioral abstract tests that should be implemented for each of the HttpClient implementation modules (currently added implementations for OkHttp and Jetty).
  • Jetty HttpClient implementation
    • Java 11 optional module
    • Should provide full-support for all HttpClient features

Follow up tasks

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change
  • Chore (non-breaking change which doesn't affect codebase;
    test, version modification, documentation, etc.)

Checklist

  • Code contributed by me aligns with current project license: Apache 2.0
  • I Added CHANGELOG entry regarding this change
  • I have implemented unit tests to cover my changes
  • I have added/updated the javadocs and other documentation accordingly
  • No new bugs, code smells, etc. in SonarCloud report
  • I tested my code in Kubernetes
  • I tested my code in OpenShift

@manusa manusa added the wip label May 30, 2022
@manusa manusa self-assigned this May 30, 2022
@manusa manusa requested a review from shawkins May 30, 2022 17:04
@manusa manusa force-pushed the feat/httpclient-jetty branch 6 times, most recently from e394b18 to 5b82ae8 Compare May 31, 2022 11:18
@manusa manusa force-pushed the feat/httpclient-jetty branch 7 times, most recently from a8c50e1 to 14c5f06 Compare June 2, 2022 17:00
@manusa manusa removed the wip label Jun 2, 2022
@manusa manusa marked this pull request as ready for review June 2, 2022 17:02
@manusa manusa added this to the 6.0.0 milestone Jun 2, 2022
@manusa manusa requested a review from rohanKanojia June 2, 2022 17:19
Copy link
Contributor

@shawkins shawkins left a 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.

@Override
public void onContent(Response response, ByteBuffer content) {
try {
consumeLock.await();
Copy link
Contributor

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?

Copy link
Member Author

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 {
Copy link
Contributor

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.

Copy link
Member Author

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.

@manusa
Copy link
Member Author

manusa commented Jun 3, 2022

I'm facing issues with the Exec streamIDs, for some reason they are not OK, and the ExecListener behaves erratically.

@manusa manusa force-pushed the feat/httpclient-jetty branch 5 times, most recently from 9b2863d to 99fe926 Compare June 6, 2022 07:57
@manusa manusa force-pushed the feat/httpclient-jetty branch 6 times, most recently from 3cb5494 to 9f2ff3c Compare June 7, 2022 11:08
// 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()?
Copy link
Contributor

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.

Copy link
Member Author

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 and consumeLines/consumeBytes since they seem redundant. I guess aligned with your thoughts. An issue for this sounds good.

Copy link
Member Author

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
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@manusa manusa force-pushed the feat/httpclient-jetty branch 2 times, most recently from 9754ce3 to 65b7900 Compare June 9, 2022 16:19
kubernetes-itests/pom.xml Outdated Show resolved Hide resolved
Signed-off-by: Marc Nuri <marc@marcnuri.com>
also making jetty consume apply to each message, and removing the okhttp
requirement for a newline
@sonarcloud
Copy link

sonarcloud bot commented Jun 10, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 3 Code Smells

88.5% 88.5% Coverage
0.0% 0.0% Duplication

@manusa manusa merged commit 1ce8e20 into fabric8io:master Jun 10, 2022
@manusa manusa deleted the feat/httpclient-jetty branch June 10, 2022 06:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants