Re: [VOTE] End support for 8.x at 8.11.4
+1 (binding). — Andrzej Białecki > On 15 Oct 2024, at 23:42, Houston Putman wrote: > > Hey everyone, > > A little while back, I made a thread asking opinions on cutting the 8.x > Solr support after 8.11.4 was released. Since there was no pushback, I am > here to start a vote. > > As it stands, Lucene 10 is out, so Lucene will not be happy to do any > lucene 8 releases (and we do not have the capability to do an 8.11.x > release without lucene). In addition to that, we have extremely limited > support given to Solr 8 because of the outdated build system. Since Solr 9 > has been out for over 3 years, I think it's safe to cut support officially > and only support 9.x until Solr 10 is released. > > Here is my vote: > +1 (binding) > > - Houston
solr cloud forward overlay requests via http2 possible bug?
Hello,
I am currently setting up a Solr cluster using version 9.7. Everything is
working quite well, except for one issue. I’ve created a simple example to
reproduce the problem. I have a docker-compose.yml file with the following
content:
docker-compose.yml
version: '3'
services:
solr:
image: solr:9.7
ports:
- "8983:8983"
- "5005:5005"
environment:
ZK_HOST: "zoo:2181"
depends_on: [zoo]
solr2:
image: solr:9.7
ports:
- "8984:8983"
environment:
ZK_HOST: "zoo:2181"
depends_on: [zoo]
zoo:
image: zookeeper:3.9
ports:
- "2181:2181"
environment:
ZOO_4LW_COMMANDS_WHITELIST: "mntr,conf,ruok"
I start the server, and the web interface is accessible at
http://localhost:8983/solr/.
Then I create two collections:
curl
"http://localhost:8983/solr/admin/collections?&action=CREATE&collection.configName=_default&name=Test&numShards=1&replicationFactor=1&router.name=compositeId&wt=json";
curl
"http://localhost:8983/solr/admin/collections?&action=CREATE&collection.configName=_default&name=Test2&numShards=1&replicationFactor=1&router.name=compositeId&wt=json";
This works, and I can send the following requests:
curl "http://localhost:8983/solr/Test/config/overlay";
{
"responseHeader":{
"status":0,
"QTime":28
},
"overlay":{
"znodeVersion":-1
}
}%
curl "http://localhost:8983/solr/Test2/config/overlay";
{
"responseHeader":{
"status":0,
"QTime":25
},
"overlay":{
"znodeVersion":-1
}
}%
This works as well. Collection Test is on one node, and Test2 is on the other.
One of the requests gets forwarded from 172.20.0.4:8983 to 172.20.0.3:8983
However, when I use HTTP/2, the forwarded request hangs for 30 seconds and then
fails:
curl --http2 "http://localhost:8983/solr/Test2/config/overlay";
curl: (92) HTTP/2 stream 1 was not closed cleanly: CANCEL (err 8)
curl --http2 "http://localhost:8983/solr/Test/config/overlay";
{
"responseHeader":{
"status":0,
"QTime":2
},
"overlay":{
"znodeVersion":-1
}
In the logs, I find the following exception:
2024-10-17 10:26:05.536 ERROR (qtp1677458155-20-null-79) [c: s: r: x:
t:null-79] o.a.s.s.HttpSolrCall 500 Exception =>
org.apache.solr.common.SolrException: Error trying to proxy request for url:
http://172.20.0.3:8983/solr/Test2/config/overlay with _forwardCount: 1
solr-1 | at
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:817)
solr-1 | org.apache.solr.common.SolrException: Error trying to proxy request
for url: http://172.20.0.3:8983/solr/Test2/config/overlay with _forwardCount: 1
solr-1 | at
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:817) ~[?:?]
solr-1 | at
org.apache.solr.servlet.HttpSolrCall.sendRemoteQuery(HttpSolrCall.java:504)
~[?:?]
solr-1 | at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:559) ~[?:?]
solr-1 | at
org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
~[?:?]
solr-1 | at
org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
~[?:?]
solr-1 | at
org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
~[?:?]
solr-1 | at
org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213)
~[?:?]
solr-1 | at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
~[?:?]
solr-1 | at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
~[?:?]
solr-1 | at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
~[jetty-servlet-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
~[jetty-servlet-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
~[jetty-server-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
~[jetty-security-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
~[jetty-server-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
~[jetty-server-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1580)
~[jetty-server-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
~[jetty-server-10.0.22.jar:10.0.22]
solr-1 | at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)
~[jetty-server-10.0.22.jar:10.0.22]
solr-1 | at
org.e
Re: HELP wanted: Dependency upgrades
I'm happy to just track the progress in each PR without additional JIRAs for each dependency. Perhaps an umbrella JIRA can be helpful though. Also, no need for CHANGES entries for these, they get added to CHANGES during next release by a script, as long as SolrBot is the committer. You can add yourself as "Co-authored-by: ". Some major-version-upgrades of dependencies require some more work or may be blocked by us lagging in Jetty version of other dependencies. Then we can convert the PR to draft with a comment. But feel free to arrange it however you wish. Appreciate any help. It is also a nice way to get aquainted with focused parts of the code and the build systme. Jan > 17. okt. 2024 kl. 16:07 skrev Christos Malliaridis : > > The main blocker based on the PR comments seems to be the JDK version in > Solr that is too low to upgrade some of the dependencies. If Solr will use > JDK 21 in v10.0, it shouldn't be a problem updating these dependencies > before v10. > > I could create a JIRA ticket with subtasks for each dependency update + PR > that is available, so that we track the progress and document whether they > can and should be backported or not. Would that be helpful to get things > started? > > Best, > Christos > > On Wed, Oct 16, 2024 at 12:06 PM Jan Høydahl wrote: > >> Hi, >> >> There are now 36 open SolrBot PRs, some of which are several months old: >> >> https://github.com/apache/solr/pulls/solrbot >> >> Let's do a round of dependency upgrade merging to main + 9x prior to a 9.8 >> release. >> >> Not a committer? You can still help e.g. by triaging the PRs that failed >> tests and making a comment in the PR on what you believe is the next >> action. Sometimes a rebase is required, and there's a checkbox in the >> description that can be checked to trigger a rebase on the next solrbot run >> (every 4 hours). Sometimes tests fail unrelated to the upgrade, then that >> one test can be re-run to get to a green state. Sometimes new transitive >> libraries are added by an upgrade, consider whether they are needed (and >> must be added to licenses/ folder), or if they can be excluded. >> >> Here are some useful pointers: >> * >> https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc >> * https://github.com/apache/solr/blob/main/dev-tools/scripts/cherrypick.sh >> can be useful for backporting (always run precommit before pushing though) >> >> Jan - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: HELP wanted: Dependency upgrades
Indeed, please no JIRAs for these unless it's a bigger non-trivial upgrade for some reason. Like for Lucene. On Thu, Oct 17, 2024 at 5:46 PM Jan Høydahl wrote: > I'm happy to just track the progress in each PR without additional JIRAs > for each dependency. Perhaps an umbrella JIRA can be helpful though. Also, > no need for CHANGES entries for these, they get added to CHANGES during > next release by a script, as long as SolrBot is the committer. You can add > yourself as "Co-authored-by: ". > > Some major-version-upgrades of dependencies require some more work or may > be blocked by us lagging in Jetty version of other dependencies. Then we > can convert the PR to draft with a comment. > > But feel free to arrange it however you wish. Appreciate any help. It is > also a nice way to get aquainted with focused parts of the code and the > build systme. > > Jan > > > 17. okt. 2024 kl. 16:07 skrev Christos Malliaridis < > c.malliari...@gmail.com>: > > > > The main blocker based on the PR comments seems to be the JDK version in > > Solr that is too low to upgrade some of the dependencies. If Solr will > use > > JDK 21 in v10.0, it shouldn't be a problem updating these dependencies > > before v10. > > > > I could create a JIRA ticket with subtasks for each dependency update + > PR > > that is available, so that we track the progress and document whether > they > > can and should be backported or not. Would that be helpful to get things > > started? > > > > Best, > > Christos > > > > On Wed, Oct 16, 2024 at 12:06 PM Jan Høydahl > wrote: > > > >> Hi, > >> > >> There are now 36 open SolrBot PRs, some of which are several months old: > >> > >> https://github.com/apache/solr/pulls/solrbot > >> > >> Let's do a round of dependency upgrade merging to main + 9x prior to a > 9.8 > >> release. > >> > >> Not a committer? You can still help e.g. by triaging the PRs that failed > >> tests and making a comment in the PR on what you believe is the next > >> action. Sometimes a rebase is required, and there's a checkbox in the > >> description that can be checked to trigger a rebase on the next solrbot > run > >> (every 4 hours). Sometimes tests fail unrelated to the upgrade, then > that > >> one test can be re-run to get to a green state. Sometimes new transitive > >> libraries are added by an upgrade, consider whether they are needed (and > >> must be added to licenses/ folder), or if they can be excluded. > >> > >> Here are some useful pointers: > >> * > >> > https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc > >> * > https://github.com/apache/solr/blob/main/dev-tools/scripts/cherrypick.sh > >> can be useful for backporting (always run precommit before pushing > though) > >> > >> Jan > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
Re: HELP wanted: Dependency upgrades
Lucene or jetty, or anything else that touches the jakarta vs javax package switch mess any of those should be Jiras I think. On the Jakarta/Javax topic: This is a MAJOR pain for one org I know, because they have solr code in their repo, and use our test framework, including the mini-cluster so, they can't move to anything with jakarta packages... and since they use dropwizard and hibernate validator among other things, that's a big deal. We need to get onto jakarta packages by 10.x (the tickets for jetty 11/12 will probably force this). -Gus On Thu, Oct 17, 2024 at 5:55 PM David Smiley wrote: > Indeed, please no JIRAs for these unless it's a bigger non-trivial upgrade > for some reason. Like for Lucene. > > On Thu, Oct 17, 2024 at 5:46 PM Jan Høydahl wrote: > > > I'm happy to just track the progress in each PR without additional JIRAs > > for each dependency. Perhaps an umbrella JIRA can be helpful though. > Also, > > no need for CHANGES entries for these, they get added to CHANGES during > > next release by a script, as long as SolrBot is the committer. You can > add > > yourself as "Co-authored-by: ". > > > > Some major-version-upgrades of dependencies require some more work or may > > be blocked by us lagging in Jetty version of other dependencies. Then we > > can convert the PR to draft with a comment. > > > > But feel free to arrange it however you wish. Appreciate any help. It is > > also a nice way to get aquainted with focused parts of the code and the > > build systme. > > > > Jan > > > > > 17. okt. 2024 kl. 16:07 skrev Christos Malliaridis < > > c.malliari...@gmail.com>: > > > > > > The main blocker based on the PR comments seems to be the JDK version > in > > > Solr that is too low to upgrade some of the dependencies. If Solr will > > use > > > JDK 21 in v10.0, it shouldn't be a problem updating these dependencies > > > before v10. > > > > > > I could create a JIRA ticket with subtasks for each dependency update + > > PR > > > that is available, so that we track the progress and document whether > > they > > > can and should be backported or not. Would that be helpful to get > things > > > started? > > > > > > Best, > > > Christos > > > > > > On Wed, Oct 16, 2024 at 12:06 PM Jan Høydahl > > wrote: > > > > > >> Hi, > > >> > > >> There are now 36 open SolrBot PRs, some of which are several months > old: > > >> > > >> https://github.com/apache/solr/pulls/solrbot > > >> > > >> Let's do a round of dependency upgrade merging to main + 9x prior to a > > 9.8 > > >> release. > > >> > > >> Not a committer? You can still help e.g. by triaging the PRs that > failed > > >> tests and making a comment in the PR on what you believe is the next > > >> action. Sometimes a rebase is required, and there's a checkbox in the > > >> description that can be checked to trigger a rebase on the next > solrbot > > run > > >> (every 4 hours). Sometimes tests fail unrelated to the upgrade, then > > that > > >> one test can be re-run to get to a green state. Sometimes new > transitive > > >> libraries are added by an upgrade, consider whether they are needed > (and > > >> must be added to licenses/ folder), or if they can be excluded. > > >> > > >> Here are some useful pointers: > > >> * > > >> > > > https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc > > >> * > > https://github.com/apache/solr/blob/main/dev-tools/scripts/cherrypick.sh > > >> can be useful for backporting (always run precommit before pushing > > though) > > >> > > >> Jan > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
Re: HELP wanted: Dependency upgrades
The main blocker based on the PR comments seems to be the JDK version in Solr that is too low to upgrade some of the dependencies. If Solr will use JDK 21 in v10.0, it shouldn't be a problem updating these dependencies before v10. I could create a JIRA ticket with subtasks for each dependency update + PR that is available, so that we track the progress and document whether they can and should be backported or not. Would that be helpful to get things started? Best, Christos On Wed, Oct 16, 2024 at 12:06 PM Jan Høydahl wrote: > Hi, > > There are now 36 open SolrBot PRs, some of which are several months old: > > https://github.com/apache/solr/pulls/solrbot > > Let's do a round of dependency upgrade merging to main + 9x prior to a 9.8 > release. > > Not a committer? You can still help e.g. by triaging the PRs that failed > tests and making a comment in the PR on what you believe is the next > action. Sometimes a rebase is required, and there's a checkbox in the > description that can be checked to trigger a rebase on the next solrbot run > (every 4 hours). Sometimes tests fail unrelated to the upgrade, then that > one test can be re-run to get to a green state. Sometimes new transitive > libraries are added by an upgrade, consider whether they are needed (and > must be added to licenses/ folder), or if they can be excluded. > > Here are some useful pointers: > * > https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc > * https://github.com/apache/solr/blob/main/dev-tools/scripts/cherrypick.sh > can be useful for backporting (always run precommit before pushing though) > > Jan
CVE-2024-45216, Solr 9.7 and Windows
Hello, Given that the fix for the two recent CVEs on Solr 9 is provided in Solr 9.7.0, and Solr 9.7.0 doesn't work on Windows https://issues.apache.org/jira/browse/SOLR-17457 - I was just wondering what the likely ETA for a 9.7.1 or 9.8.0 release is? Cheers Colvin
Re: solr cloud forward overlay requests via http2 possible bug?
Hi Sebastian,
This does sound like a "bug" - would you be willing to file a JIRA
ticket with this information please? ("Bonus points" if you can tweak
your reproduction steps to use "bin/solr start -e cloud" instead of
docker-compose, as that's probably more approachable for some folks!
But no worries if not.)
Thanks for raising this!
Best,
Jason
On Thu, Oct 17, 2024 at 7:45 AM Sebastian Hofmann
wrote:
>
> Hello,
>
> I am currently setting up a Solr cluster using version 9.7. Everything is
> working quite well, except for one issue. I’ve created a simple example to
> reproduce the problem. I have a docker-compose.yml file with the following
> content:
>
> docker-compose.yml
> version: '3'
> services:
> solr:
> image: solr:9.7
> ports:
> - "8983:8983"
> - "5005:5005"
> environment:
> ZK_HOST: "zoo:2181"
> depends_on: [zoo]
> solr2:
> image: solr:9.7
> ports:
> - "8984:8983"
> environment:
> ZK_HOST: "zoo:2181"
> depends_on: [zoo]
> zoo:
> image: zookeeper:3.9
> ports:
> - "2181:2181"
> environment:
> ZOO_4LW_COMMANDS_WHITELIST: "mntr,conf,ruok"
>
> I start the server, and the web interface is accessible at
> http://localhost:8983/solr/.
>
> Then I create two collections:
>
> curl
> "http://localhost:8983/solr/admin/collections?&action=CREATE&collection.configName=_default&name=Test&numShards=1&replicationFactor=1&router.name=compositeId&wt=json";
>
> curl
> "http://localhost:8983/solr/admin/collections?&action=CREATE&collection.configName=_default&name=Test2&numShards=1&replicationFactor=1&router.name=compositeId&wt=json";
>
> This works, and I can send the following requests:
>
> curl "http://localhost:8983/solr/Test/config/overlay";
>
> {
> "responseHeader":{
> "status":0,
> "QTime":28
> },
> "overlay":{
> "znodeVersion":-1
> }
> }%
>
>
> curl "http://localhost:8983/solr/Test2/config/overlay";
>
> {
> "responseHeader":{
> "status":0,
> "QTime":25
> },
> "overlay":{
> "znodeVersion":-1
> }
> }%
>
> This works as well. Collection Test is on one node, and Test2 is on the
> other. One of the requests gets forwarded from 172.20.0.4:8983 to
> 172.20.0.3:8983
>
> However, when I use HTTP/2, the forwarded request hangs for 30 seconds and
> then fails:
>
> curl --http2 "http://localhost:8983/solr/Test2/config/overlay";
> curl: (92) HTTP/2 stream 1 was not closed cleanly: CANCEL (err 8)
>
> curl --http2 "http://localhost:8983/solr/Test/config/overlay";
> {
> "responseHeader":{
> "status":0,
> "QTime":2
> },
> "overlay":{
> "znodeVersion":-1
> }
>
> In the logs, I find the following exception:
> 2024-10-17 10:26:05.536 ERROR (qtp1677458155-20-null-79) [c: s: r: x:
> t:null-79] o.a.s.s.HttpSolrCall 500 Exception =>
> org.apache.solr.common.SolrException: Error trying to proxy request for url:
> http://172.20.0.3:8983/solr/Test2/config/overlay with _forwardCount: 1
> solr-1 | at
> org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:817)
> solr-1 | org.apache.solr.common.SolrException: Error trying to proxy
> request for url: http://172.20.0.3:8983/solr/Test2/config/overlay with
> _forwardCount: 1
> solr-1 | at
> org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:817) ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.HttpSolrCall.sendRemoteQuery(HttpSolrCall.java:504)
> ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:559) ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
> ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
> ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
> ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213)
> ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
> ~[?:?]
> solr-1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> ~[?:?]
> solr-1 | at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> solr-1 | at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> solr-1 | at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> solr-1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> solr-1 | at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> solr-1 | at
> org.eclipse.jetty.server
Re: [VOTE] End support for 8.x at 8.11.4
+1 (binding) On Thu, Oct 17, 2024 at 4:23 AM Andrzej Białecki wrote: > > +1 (binding). > > — > > Andrzej Białecki > > > > On 15 Oct 2024, at 23:42, Houston Putman wrote: > > > > Hey everyone, > > > > A little while back, I made a thread asking opinions on cutting the 8.x > > Solr support after 8.11.4 was released. Since there was no pushback, I am > > here to start a vote. > > > > As it stands, Lucene 10 is out, so Lucene will not be happy to do any > > lucene 8 releases (and we do not have the capability to do an 8.11.x > > release without lucene). In addition to that, we have extremely limited > > support given to Solr 8 because of the outdated build system. Since Solr 9 > > has been out for over 3 years, I think it's safe to cut support officially > > and only support 9.x until Solr 10 is released. > > > > Here is my vote: > > +1 (binding) > > > > - Houston > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
