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

SOLR-15955: Update Jetty dependency to 10 #585

Merged
merged 42 commits into from Nov 10, 2022
Merged

Conversation

markrmiller
Copy link
Member

@markrmiller markrmiller commented Feb 1, 2022

https://issues.apache.org/jira/browse/SOLR-15955

Summary:

  • Upgrades to Jetty 10.0.12
  • dropwizard metrics 4.2.12 for dropwizard-metrics9 -> dropwizard-metrics10
  • log4j 2.19.0 and slf4j 2.0.3
  • for s3mock specifically upgrade spring-boot 2.5.14 and spring 5.3.23 to handle Jetty 10

@markrmiller markrmiller force-pushed the SOLR-15955 branch 2 times, most recently from ba3c027 to 4a9e65c Compare February 9, 2022 23:18
@markrmiller markrmiller force-pushed the SOLR-15955 branch 3 times, most recently from 490bfe6 to 5a8744e Compare February 14, 2022 23:20
@markrmiller
Copy link
Member Author

Thanks for taking a look. I have a n update I'll push I'll push tomorrow.

@markrmiller
Copy link
Member Author

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.

@markrmiller
Copy link
Member Author

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/s3-repository/build.gradle Outdated Show resolved Hide resolved
versions.lock Outdated Show resolved Hide resolved
gradle/solr/force-versions.gradle Outdated Show resolved Hide resolved
@markrmiller markrmiller marked this pull request as ready for review March 4, 2022 03:45
@markrmiller markrmiller force-pushed the SOLR-15955 branch 2 times, most recently from 03986cd to 5863b10 Compare March 4, 2022 05:54
solr/core/build.gradle Outdated Show resolved Hide resolved
Comment on lines 72 to 73
// 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)
Copy link
Contributor

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.

Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Member Author

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.

@markrmiller
Copy link
Member Author

I don't think we need this - tried running tests locally without it and using S3_MOCK_RULE to build the client directly and things seemed fine.

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.

@markrmiller
Copy link
Member Author

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.

@risdenk
Copy link
Contributor

risdenk commented Oct 24, 2022

setDeflaterPoolCapacity addressed in 22cfe1d

Copy link
Contributor

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

@risdenk
Copy link
Contributor

risdenk commented Nov 3, 2022

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.

yup this also affects Jetty 9.4.x from what I gather from SOLR-16099

@risdenk
Copy link
Contributor

risdenk commented Nov 4, 2022

@markrmiller do you have any concerns on the current state of this PR? I'm hoping to merge it soon.

@risdenk
Copy link
Contributor

risdenk commented Nov 4, 2022

I haven't looked at these yet or see if they reproduce.

./gradlew check -Pvalidation.errorprone=true -Ptests.filter=@Nightly
...
ERROR: The following test(s) have failed:
  - org.apache.solr.hdfs.cloud.SharedFileSystemAutoReplicaFailoverTest.test (:solr:modules:hdfs)
    Test output: /Users/risdenk/repos/apache/solr/solr/modules/hdfs/build/test-results/test/outputs/OUTPUT-org.apache.solr.hdfs.cloud.SharedFileSystemAutoReplicaFailoverTest.txt
    Reproduce with: gradlew :solr:modules:hdfs:test --tests "org.apache.solr.hdfs.cloud.SharedFileSystemAutoReplicaFailoverTest.test" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=8633D060D495F1DF -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit2 (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit2" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=8633D060D495F1DF -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=8633D060D495F1DF -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=8633D060D495F1DF -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=8633D060D495F1DF -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

reran again and got this:

./gradlew check -Pvalidation.errorprone=true -Ptests.filter=@Nightly
...
ERROR: The following test(s) have failed:
  - org.apache.solr.hdfs.cloud.SharedFileSystemAutoReplicaFailoverTest.test (:solr:modules:hdfs)
    Test output: /Users/risdenk/repos/apache/solr/solr/modules/hdfs/build/test-results/test/outputs/OUTPUT-org.apache.solr.hdfs.cloud.SharedFileSystemAutoReplicaFailoverTest.txt
    Reproduce with: gradlew :solr:modules:hdfs:test --tests "org.apache.solr.hdfs.cloud.SharedFileSystemAutoReplicaFailoverTest.test" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=16377EC258C8C266 -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=16377EC258C8C266 -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit2 (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit2" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=16377EC258C8C266 -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=16377EC258C8C266 -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-1

  - org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod (:solr:core)
    Test output: /Users/risdenk/repos/apache/solr/solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.api.collections.ShardSplitTest.txt
    Reproduce with: gradlew :solr:core:test --tests "org.apache.solr.cloud.api.collections.ShardSplitTest.classMethod" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=16377EC258C8C266 -Ptests.filter=@Nightly -Ptests.file.encoding=ISO-8859-

working on checking on main to see if this is a problem there too.

@risdenk
Copy link
Contributor

risdenk commented Nov 4, 2022

The above failures also happen on main branch so at least it is nothing new added from this PR for nightly tests.

@risdenk risdenk merged commit 96ddf2c into apache:main Nov 10, 2022
risdenk added a commit to risdenk/solr that referenced this pull request Nov 22, 2022
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
8 participants