-
Notifications
You must be signed in to change notification settings - Fork 14k
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
KAFKA-16437 - Upgrade to Jakarta and Jetty 12 (KIP-1032) #16754
Conversation
@gharris1727 and @C0urante - If either (or both) of you could take a look at some point and see what you think. There's no rush but I wanted to get this PR going now that trunk has been bumped to 4.0.0-SNAPSHOT. I am going to be out of town the rest of the week but I'll be back online middle of next week. |
The checks on Java 8 and Java 11 fail because this PR requires JDK 17+ |
This commit implements KIP-1032 and upgrades to Jakarta, JavaEE 10 and also Jetty 12. Jetty 12 requires JDK 17 so the connect and MM2 runtimes have been bumped to JDK 17. See KIP-1032
@chia7712 - I merged the latest trunk and fixed the conflicts so this PR is now up to date |
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.
Thanks for the patch @cshannon. Overall, I think this change looks good. A few small things inline.
For big PRs like this, we rely heavily on our tests to ensure we didn't break anything. Can you run the test suite on this PR a few times just to see if anything shakes out? You can trigger a new build by pushing an empty commit (git commit --allow-empty
)
connect/runtime/src/main/java/org/apache/kafka/connect/runtime/Worker.java
Outdated
Show resolved
Hide resolved
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 re-ran the tests three times, looks good. I'm approving this now, but will wait a few days before merging to see if @gharris1727 or @C0urante (or @chia7712) have anything to add.
@mumrah - Sounds good, thanks for the review. I forgot to mention that I looked more into what to do about having to change the If we wanted to restore the previous behavior to allow it, we could set the UriComplianceMode to be LEGACY. See this comment: jetty/jetty.project#11890 (comment) However, I would say it's better to not allow it as the spec now says it's a violation so I think the current change I made is fine, but I guess it depends if there's use cases to allow it. Edit: Here is the relevant part of the spec https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0.html#uri-path-canonicalization |
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.
@cshannon thanks for this patch. a couple of comments are left. PTAL
@@ -113,6 +113,7 @@ public <T, U> T completeOrForwardRequest(FutureCallback<T> cb, | |||
} | |||
String forwardUrl = uriBuilder.build().toString(); | |||
log.debug("Forwarding request {} {} {}", forwardUrl, method, body); | |||
// TODO, we may need to set the reqest timeout as Idle timeout on the HttpClient |
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.
typo: reqest
-> request
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.
This comment is valid to me, as the default idle timeout for HttpClient is 30 seconds, and the default request timeout is 90 seconds.
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.
If we want to configure the idle timeout I guess the question is the best way to do so. I think we'd either need to pass it as an argument to the request() methods or add it to the AbstractConfig for RestClient so it has access to it when constructing the HttpClient. I guess there's also the question if it should always match the request timeout or it could be configured as a separate config. Maybe this could be done as a follow on task after this is merged.
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.
Thanks @cshannon for this change, thanks so much for getting this completed and working through the merge conflicts with all of the rest of the activity on trunk!
My comments are non-blocking, i'm happy to merge this as-is, but i'll let you address any other comments and merge tomorrow before feature freeze.
// TODO: Jetty 12 throws a 400 amiguous error with the previous test string here | ||
// It seems like at least some encoded characters are not allowed anymore based on | ||
// https://github.com/jetty/jetty.project/issues/11890#issuecomment-2156442947 | ||
// See https://github.com/jetty/jetty.project/issues/11890 | ||
//final String b = "B- ._~:/?#[]@!$&'()*+;=\"<>%{}|\\^`618"; | ||
final String b = "B"; |
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.
Could you keep most of these suspicious characters, and just remove the ones which are ambiguous?
From reading the linked issue, it might just be the /
character, and the remainder are still valid.
It looks like this test was sensitive enough to find the underlying change in the library, so I'd like to keep it sensitive in case something like this happens again.
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.
So there's actually a few characters that are not allowed, control characters, backslash, etc. I went ahead and removed a few problem characters so it works now. I also updated the comments for the section. You can see the exact rules in the Rejecting Suspicious Sequences
section as part of https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0#uri-path-canonicalization
connect/runtime/src/test/java/org/apache/kafka/connect/runtime/rest/util/SSLUtilsTest.java
Outdated
Show resolved
Hide resolved
@gharris1727 and @chia7712 - I think I addressed all the comments so this can be merged. The only outstanding one was if we wanted to set the idle timeout on the HttpClient to match the same thing as the request timeout (or even make it configurable separately) but I am still not quite sure if we should and I think that might be better as a follow on discussion and don't think it's a blocker. I can work on a PR for that depending on what we wanted to do (if anything) |
It seems the JDK 23 build is timing out but I'm not sure why, the issue could be unrelated to the tests themselves. The build is currently running again (and appears hung but I can't see why until it finishes it says). I pulled the logs from yesterday to figure out why it was hung and it shows:
That output shows it finishes tests and just does nothing for 37 minutes when trying to copy the XML files and then times out |
This commit implements the changes for KIP-1032. This updates Kafka to Jakarta specs, JavaEE 10 and Jetty 12. The changes here primarily effect Kafka Connect and MM2.
Todo/Notes:
ConnectWorkerIntegrationTest#testPollTimeoutExpiry()
testTesting is being done by just using the existing tests for Connect and MM2 which should be sufficient.
Committer Checklist (excluded from commit message)