-
Notifications
You must be signed in to change notification settings - Fork 685
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
SOLR-15955: Update Jetty dependency to 10 #585
Conversation
406d43f
to
9dc830d
Compare
ba3c027
to
4a9e65c
Compare
solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java
Outdated
Show resolved
Hide resolved
solr/modules/hdfs/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java
Outdated
Show resolved
Hide resolved
490bfe6
to
5a8744e
Compare
solr/modules/s3-repository/src/test/org/apache/solr/s3/S3BackupRepositoryTest.java
Show resolved
Hide resolved
solr/modules/s3-repository/src/test/org/apache/solr/s3/S3ReadWriteTest.java
Outdated
Show resolved
Hide resolved
solr/core/src/java/org/apache/solr/request/json/RequestUtil.java
Outdated
Show resolved
Hide resolved
solr/modules/s3-repository/src/test/org/apache/solr/s3/S3BackupRepositoryTest.java
Outdated
Show resolved
Hide resolved
solr/modules/s3-repository/src/test/org/apache/solr/s3/S3BackupRepositoryTest.java
Outdated
Show resolved
Hide resolved
solr/solrj/src/java/org/apache/solr/client/solrj/util/SolrBasicAuthentication.java
Outdated
Show resolved
Hide resolved
...t-framework/src/java/org/apache/solr/cloud/api/collections/AbstractBackupRepositoryTest.java
Outdated
Show resolved
Hide resolved
Thanks for taking a look. I have a n update I'll push I'll push tomorrow. |
solr/modules/hdfs/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java
Outdated
Show resolved
Hide resolved
A couple of those are extra lines that came in when I merged to a clean repo (test policy and s3 build.gradle I believe). I'll get the follow up pushed tomorrow - I rebased yesterday and after resolving new conflicts, tests were flakier (a handful failed first run) and one test failed consistently (managed storage test I believe). So I held back to look into that a bit, but in the in end, it seems I see the same behavior on a clean checkout, so should not be related this work. |
26c26c8
to
69a9803
Compare
That was a bit more effort than expected, but updated jetty from 10.0.7 to 10.0.8. That removes the need for the security policy read permission for "/". Rebased to latest main, let's see if these build checks pass, did a couple test runs without issue. |
solr/modules/hadoop-auth/src/test/org/apache/solr/client/solrj/impl/Krb5HttpClientUtils.java
Show resolved
Hide resolved
03986cd
to
5863b10
Compare
// if BinaryResponseParser.BINARY_CONTENT_TYPE, let the following fail below - we may have adjusted the content without updating the content type | ||
// problem in this case happens in a few tests, one seems to happen with kerberos and remote node query (HttpSolrCall's request proxy) |
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.
It took a bit of digging, but I finally figured it out. When Jetty receives a request with no body content, it creates a placeholder zero-length application/octet-stream content object. Then when it gets a redirect (like an explicit redirect handler, or some authentication plugins cause), it copies that body to the new request. When the new request gets to our search handlers, we see the body and save it as a stream. So I think that we could check for that in SolrRequestParsers.parseParamsAndFillStreams
- the combination of a GET request with a zero length octet-stream body seems like a safe instance to drop the stream. Maybe we could drop all the stream bodies for all get requests, I'm not sure. This could be a bug in Jetty, but I haven't figured out a simple repro case for them yet.
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.
Good find, and that does jive with what was happening when I found the fail I saw here pop up on the mailing list in the past.
So I think the diagnosis makes sense, and the change sounds reasonable high level, but I am concerned that it requires that you can inspect the stream or count on the content-size header to properly describe the stream. You cannot generally do that though. The size is not required, usually not given in Solr, and you can't reasonable inspect a stream in a webapp/servlet unless you buffer it, which is also problematic. Given we are talking about a steram on a GET request, maybe somehow you can get away with this, but it seems pretty fragile?
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.
RawRequestParser.parseParamsAndFillStreams will proactively save the stream if there is a content length >= 0
- that should probably be strictly > 0
. Because then in the else block, if it's not a GET we try to buffer the first byte - if it exists, save the stream again and if not then we don't need it. I think we need to fix RawRequestParser with this PR to accommodate the change that Jetty made - it's likely a regression but I couldn't find an existing bug report or an easy reproducer for them.
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.
Hmmm, it shouldn't save the steam content I hope, that would prevent actual streaming. But in either case, that does remind me: I think there is a tiny little buffer that is used for content type auto detect in RequestParsers...we would know if a stream is empty or not there.
solr/modules/s3-repository/src/test/org/apache/solr/s3/S3BackupRepositoryTest.java
Outdated
Show resolved
Hide resolved
I actually took things out one by one from this class on the last update, and I left this because the tests passed as I removed up to this point and then failed when I removed this. But I tried again, and it seems to have passed, so perhaps some stale result issue I saw. Looks like it can come out if we go by your result and my latest. |
Okay, I had missed in the patch you passed me how you proposed dealing with the toolchain dep issue - just using that instead of servlet-api - that seems fine to me. I spent a bit of time on the 0 byte inputstream issue, but in the end, I think your approach is likely fine to start with - given that it works in the case that we currently know causes an issue, and if it stopped working for that case, tests would fail, I've come to think this solution is fine until we find it not to be. This cleanup push that just went up includes a couple required changes to jetty config that I had forgotten are required and introduce the biggest upgrade issues a user would face - the existing config will not work. There is a fix required in the main jetty xml config where the rewrite handler is referenced by id instead of refid - that fails on jetty 10. And there is gzip config that references methods that are now removed and for the most part without replacement. They have to be changed. |
|
solr/core/src/java/org/apache/solr/util/StartupLoggingUtils.java
Outdated
Show resolved
Hide resolved
Co-authored-by: David Smiley <dsmiley@apache.org>
Co-authored-by: David Smiley <dsmiley@apache.org>
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.
One question, one formatting thing.
Otherwise this looks good to go.
Btw we need to upgrade, as we are seeing jetty/jetty.project#8558 in our failing tests, and need an upgrade path when Jetty 10.0.13 is released.
solr/core/src/java/org/apache/solr/request/json/RequestUtil.java
Outdated
Show resolved
Hide resolved
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java
Show resolved
Hide resolved
yup this also affects Jetty 9.4.x from what I gather from SOLR-16099 |
This reverts commit 3ad2030.
@markrmiller do you have any concerns on the current state of this PR? I'm hoping to merge it soon. |
I haven't looked at these yet or see if they reproduce.
reran again and got this:
working on checking on main to see if this is a problem there too. |
The above failures also happen on |
* Upgrades to Jetty 10.0.12 * Upgrades dropwizard metrics 4.2.12 for `dropwizard-metrics9` -> `dropwizard-metrics10` * Upgrades log4j 2.19.0 and slf4j 2.0.3 for Jetty 10 * For s3mock specifically, upgrade spring-boot 2.5.14 and spring 5.3.23 to handle Jetty 10 Co-authored-by: Kevin Risden <krisden@apache.org> Co-authored-by: David Smiley <dsmiley@apache.org>
https://issues.apache.org/jira/browse/SOLR-15955
Summary:
dropwizard-metrics9
->dropwizard-metrics10