Re: [PR] Simplify BinaryResponseWriter.getParsedResponse [solr]
dsmiley commented on PR #3243: URL: https://github.com/apache/solr/pull/3243#issuecomment-2707315246 Will merge Monday if no further feedback. Pretty simple change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17694) LeaderElector not able to parse node ID correctly when it has a leading dash
[
https://issues.apache.org/jira/browse/SOLR-17694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933496#comment-17933496
]
David Smiley commented on SOLR-17694:
-
I'm inclined to think Solr should reject such node names instead of handle it
gracefully. The work-around of avoiding such high server IDs seems
straight-forward.
> LeaderElector not able to parse node ID correctly when it has a leading dash
>
>
> Key: SOLR-17694
> URL: https://issues.apache.org/jira/browse/SOLR-17694
> Project: Solr
> Issue Type: Bug
>Reporter: Patrick
>Priority: Trivial
>
> This issue was
> [reported|https://lists.apache.org/thread/0pwxw1rzdffmbxctdzv2rmplzgwt6lpl]
> on us...@solr.apache.org.
> There could be time (e.g.: ZOOKEEPER-4904) when the node ID contains a
> leading dash
> {noformat}
> -5188057493699159958-1.1.1.15:8983_solr-n_192189
> {noformat}
> instead of just
> {noformat}
> 5188057493699159958-1.1.1.15:8983_solr-n_192189
> {noformat}
> In such case, LeaderElector.getNodeName returns
> *5188057493699159958-1.1.1.15:8983_solr* instead of just
> {*}1.1.1.15:8983_solr{*}.
> The problem is that the regex LeaderElector.NODE_NAME was not designed to
> handle the leading dash. LeaderElector.LEADER_SEQ and
> LeaderElector.SESSION_ID seem to have the same problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17537: Manage ZK Compression through Curator [solr]
HoustonPutman commented on PR #2849: URL: https://github.com/apache/solr/pull/2849#issuecomment-2707275445 With the Curator Global Compression stuff merged, we should be good to go here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
kotman12 commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1985801827
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java:
##
@@ -53,8 +53,9 @@ public ModifiableSolrParams getParams() {
}
@Override
- public String getRequestType() {
-return SolrRequestType.ADMIN.toString();
+ /* This request is not processed as an ADMIN request. */
+ protected SolrRequestType getBaseRequestType() {
+return SolrRequestType.UNSPECIFIED;
Review Comment:
Sure, this comment was a gut reaction to explicitly overridingspecifying as
UNSPECIFIED, which felt a little off. If we rely on path to determine ADMINness
and go the property route (with overloaded constructors), we can at least avoid
specifying as UNSPECIFIED at such a low level (I think) because the
default/two-arg super constructor would set it. Idk
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
kotman12 commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1985801827
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java:
##
@@ -53,8 +53,9 @@ public ModifiableSolrParams getParams() {
}
@Override
- public String getRequestType() {
-return SolrRequestType.ADMIN.toString();
+ /* This request is not processed as an ADMIN request. */
+ protected SolrRequestType getBaseRequestType() {
+return SolrRequestType.UNSPECIFIED;
Review Comment:
Sure, this comment was a gut reaction to explicitly overriding or
"specifying" as UNSPECIFIED, which felt a little off. If we rely on path to
determine ADMINness and go the property route (with overloaded constructors),
we can at least avoid overiding with UNSPECIFIED at such a low level (I think)
because the default/two-arg super constructor would set it. Idk
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
kotman12 commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1985801827
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java:
##
@@ -53,8 +53,9 @@ public ModifiableSolrParams getParams() {
}
@Override
- public String getRequestType() {
-return SolrRequestType.ADMIN.toString();
+ /* This request is not processed as an ADMIN request. */
+ protected SolrRequestType getBaseRequestType() {
+return SolrRequestType.UNSPECIFIED;
Review Comment:
Sure, this comment was a gut reaction to explicitly specifying as
UNSPECIFIED, which felt a little off. If we rely on path to determine ADMINness
and go the property route (with overloaded constructors), we can at least avoid
specifying as UNSPECIFIED at such a low level (I think) because the
default/two-arg super constructor would set it. Idk
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17447 : Support to early terminate a search based on maxHits per collector. [solr]
sijuv commented on PR #2960: URL: https://github.com/apache/solr/pull/2960#issuecomment-2704572310 Updated the pr to ensure to not mess with the _terminatedEarly_ flag even though it is unused in the current implementation. I think this flag should be removed at some point in time. With this pr, there are only 2 ways a search can be terminated early ( apart from time/cpu/mem limits ) - because the _maxHits_ parameter is set or if it is a sortedIndex and the sort is based on the index sort order. @gus-asf @dsmiley pls help review this and merge. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17656) Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
[ https://issues.apache.org/jira/browse/SOLR-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933474#comment-17933474 ] ASF subversion and git services commented on SOLR-17656: Commit b81dc4b5f29441806235a51ee87970a93bddeac5 in solr's branch refs/heads/main from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=b81dc4b5f29 ] SOLR-17656: Fix TestPullReplica.testRealTimeGet() > Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING > --- > > Key: SOLR-17656 > URL: https://issues.apache.org/jira/browse/SOLR-17656 > Project: Solr > Issue Type: New Feature >Reporter: Chris M. Hostetter >Assignee: Chris M. Hostetter >Priority: Major > Fix For: main (10.0), 9.9 > > Attachments: SOLR-17656-1.patch, SOLR-17656.patch > > > In situations where a Solr cluster undergoes a rolling restart (or some other > "catastrophic" failure situations requiring/causing solr node restarts) there > can be a snowball effect of poor performance (or even solr node crashing) due > to fewer then normal replicas serving query requests while replicas on > restarting nodes are DOWN or RECOVERING – especially if shard leaders are > also affected, and (restarting) replicas first must wait for a leader > election before they can recover (or wait to finish recovery from an > over-worked leader). > For NRT type usecases, RECOVERING is really a necessary evil to ensure every > replicas is up to date before handling NRT requests – but in the case of PULL > replicas, which are expected to routinely "lag" behind their leader, I've > talked to a lot of Solr users w/usecases where they would be happy to have > PULL replicas back online serving "stale" data ASAP, and let normal > IndexFetching "catchup" with the leader later. > I propose we support a new "advanced" replica property that can be set on > PULL replicas by expert level users, to indicate: on (re)init, these replicas > may skip RECOVERING and go directly to ACTIVE. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17309: Enhance certificate based authentication plugin with flexible cert principal resolution [solr]
epugh commented on PR #3029: URL: https://github.com/apache/solr/pull/3029#issuecomment-2706209133 @laminelam thanks for the ping. I am going to take a look at the precommit error.. Can you check the tests as well? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17638 Some CLI errors not logged when starting prometheus exporter [solr]
epugh commented on PR #3236: URL: https://github.com/apache/solr/pull/3236#issuecomment-2706368232 Other than some precommit issues, this all looks good @stillalex, do you need anything from me to get this moved forward! I'm looking forward to getting through all the CLI issues ;-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] reproducer.. wt=phps incompatibility with /admin/luke still in doubts. .. [solr]
epugh commented on PR #2114: URL: https://github.com/apache/solr/pull/2114#issuecomment-2706377500 I think this can be closed since we no longer have a `wt=phps`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17691) Request for Patch for Solr 8.4 - Zookeeper Status Error ("For input string: 'null'")
[
https://issues.apache.org/jira/browse/SOLR-17691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933365#comment-17933365
]
Jan Høydahl commented on SOLR-17691:
I can say that when building a 8.x release it is very important what JDK
version you use (latest java 8), and also specific versions of ant (I believe
1.9) and Ivy (run ant ivy-bootstrap). Then run ant package to build. Also, you
should check out the source code from the apache/lucene-solr repository, not
the apache/solr repository.
> Request for Patch for Solr 8.4 - Zookeeper Status Error ("For input string:
> 'null'")
> -
>
> Key: SOLR-17691
> URL: https://issues.apache.org/jira/browse/SOLR-17691
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.4
> Environment: UAT/PROD
>Reporter: Aviral Sinha
>Priority: Critical
> Labels: patch
> Attachments: Solr8.4SourceCompilationError.txt, solrError.jpeg
>
>
> We are currently using {*}Sitecore 10 CMS{*}, which only supports {*}Solr
> 8.4{*}. Previously, we were using {*}ZooKeeper 3.4.14{*}, but since it has
> reached End of Life (EOL), we have upgraded to {*}ZooKeeper 3.8.4{*}.
> After upgrading and configuring Solr to point to the ZooKeeper host
> ({{{}zk_host{}}}), we are encountering an error on the {*}Solr Admin Page →
> ZooKeeper Status{*}:
> *"For input string: 'null'"*
> Please find the attached screenshot for reference.
> We noticed that this issue has already been addressed in later Solr versions,
> as referenced in the following JIRA cases:
> * SOLR-14463
> * SOLR-14669
> Since {*}our Sitecore application depends on Solr 8.4{*}, we are unable to
> upgrade to a higher Solr version. We kindly request you to provide a patch
> for Solr 8.4 to resolve this issue.
> Looking forward to your response.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17693) Upgrade to Apache Curator 5.8.0
[ https://issues.apache.org/jira/browse/SOLR-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-17693: -- Summary: Upgrade to Apache Curator 5.8.0 (was: Upgrade to Apache Curator 3.8.0) > Upgrade to Apache Curator 5.8.0 > --- > > Key: SOLR-17693 > URL: https://issues.apache.org/jira/browse/SOLR-17693 > Project: Solr > Issue Type: Sub-task >Reporter: Houston Putman >Priority: Major > > This Curator release includes the necessary things to be able to use Curator > Recipes in Apache Solr. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17693: Update apache.curator to v5.8.0 [solr]
HoustonPutman merged PR #3245: URL: https://github.com/apache/solr/pull/3245 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17693) Upgrade to Apache Curator 5.8.0
[ https://issues.apache.org/jira/browse/SOLR-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-17693. --- Fix Version/s: main (10.0) Assignee: Houston Putman Resolution: Done > Upgrade to Apache Curator 5.8.0 > --- > > Key: SOLR-17693 > URL: https://issues.apache.org/jira/browse/SOLR-17693 > Project: Solr > Issue Type: Sub-task >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Labels: pull-request-available > Fix For: main (10.0) > > Time Spent: 10m > Remaining Estimate: 0h > > This Curator release includes the necessary things to be able to use Curator > Recipes in Apache Solr. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17693) Upgrade to Apache Curator 5.8.0
[ https://issues.apache.org/jira/browse/SOLR-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17693: -- Labels: pull-request-available (was: ) > Upgrade to Apache Curator 5.8.0 > --- > > Key: SOLR-17693 > URL: https://issues.apache.org/jira/browse/SOLR-17693 > Project: Solr > Issue Type: Sub-task >Reporter: Houston Putman >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > This Curator release includes the necessary things to be able to use Curator > Recipes in Apache Solr. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17693) Upgrade to Apache Curator 5.8.0
[ https://issues.apache.org/jira/browse/SOLR-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933368#comment-17933368 ] ASF subversion and git services commented on SOLR-17693: Commit 89ad80e423e19ea3cf317e439499400d0d860d78 in solr's branch refs/heads/main from Solr Bot [ https://gitbox.apache.org/repos/asf?p=solr.git;h=89ad80e423e ] SOLR-17693: Update apache.curator to v5.8.0 (#3245) > Upgrade to Apache Curator 5.8.0 > --- > > Key: SOLR-17693 > URL: https://issues.apache.org/jira/browse/SOLR-17693 > Project: Solr > Issue Type: Sub-task >Reporter: Houston Putman >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > This Curator release includes the necessary things to be able to use Curator > Recipes in Apache Solr. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17438) releaseWizard: remove refs to people.apache.org/home.apache.org
[ https://issues.apache.org/jira/browse/SOLR-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933283#comment-17933283 ] ASF subversion and git services commented on SOLR-17438: Commit 4acc1dfc5364fd153e69cd1cda4c80c2bf26d7f8 in solr's branch refs/heads/main from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=solr.git;h=4acc1dfc536 ] SOLR-17438 ReleaseWizard to resolve committer GPG key from whimsy (#3145) > releaseWizard: remove refs to people.apache.org/home.apache.org > --- > > Key: SOLR-17438 > URL: https://issues.apache.org/jira/browse/SOLR-17438 > Project: Solr > Issue Type: Task > Components: release-scripts >Reporter: David Smiley >Assignee: Jan Høydahl >Priority: Blocker > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > The ASF is turning off home.apache.org on September 12th for good. Thus the > release wizard should stop using it to get your key in configure_pgp() -- > https://home.apache.org/keys/committer/%s.asc > FYI see the Lucene [issue|https://github.com/apache/lucene/issues/13647] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17438 Resolve committer GPG key from other source [solr]
janhoy merged PR #3145: URL: https://github.com/apache/solr/pull/3145 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17438) releaseWizard: remove refs to people.apache.org/home.apache.org
[ https://issues.apache.org/jira/browse/SOLR-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933288#comment-17933288 ] ASF subversion and git services commented on SOLR-17438: Commit 2b2855eafdcde936c16e92bcf1f18b66382f18d7 in solr's branch refs/heads/branch_9x from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=solr.git;h=2b2855eafdc ] SOLR-17438 ReleaseWizard to resolve committer GPG key from whimsy (#3145) (cherry picked from commit 4acc1dfc5364fd153e69cd1cda4c80c2bf26d7f8) > releaseWizard: remove refs to people.apache.org/home.apache.org > --- > > Key: SOLR-17438 > URL: https://issues.apache.org/jira/browse/SOLR-17438 > Project: Solr > Issue Type: Task > Components: release-scripts >Reporter: David Smiley >Assignee: Jan Høydahl >Priority: Blocker > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > The ASF is turning off home.apache.org on September 12th for good. Thus the > release wizard should stop using it to get your key in configure_pgp() -- > https://home.apache.org/keys/committer/%s.asc > FYI see the Lucene [issue|https://github.com/apache/lucene/issues/13647] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17638 Some CLI errors not logged when starting prometheus exporter [solr]
stillalex commented on PR #3236: URL: https://github.com/apache/solr/pull/3236#issuecomment-2706638595 keeping an eye on https://github.com/apache/solr/pull/3240/files to get some inspiration for this change. I added a similar `zkHost` lookup. unfortunately this module does not have access to solr-core (I think by design) so I am forced to copy methods over which is not ideal. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17438) releaseWizard: remove refs to people.apache.org/home.apache.org
[ https://issues.apache.org/jira/browse/SOLR-17438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-17438. Resolution: Fixed Done in main and branch_9x. If the json file moves away from whimsy later, we'll tackle it then > releaseWizard: remove refs to people.apache.org/home.apache.org > --- > > Key: SOLR-17438 > URL: https://issues.apache.org/jira/browse/SOLR-17438 > Project: Solr > Issue Type: Task > Components: release-scripts >Reporter: David Smiley >Assignee: Jan Høydahl >Priority: Blocker > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > The ASF is turning off home.apache.org on September 12th for good. Thus the > release wizard should stop using it to get your key in configure_pgp() -- > https://home.apache.org/keys/committer/%s.asc > FYI see the Lucene [issue|https://github.com/apache/lucene/issues/13647] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17309: Enhance certificate based authentication plugin with flexible cert principal resolution [solr]
epugh commented on PR #3029: URL: https://github.com/apache/solr/pull/3029#issuecomment-2706364784 @laminelam updating from main fixed things. Can you confirm the `security.hadoop` change? So in main we no longer have Hadoop, so I don't think it's needed. Is it required for backporting to 9x to make this work? If we don't need it, it would simplify things to not have it! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17693) Upgrade to Apache Curator 3.8.0
Houston Putman created SOLR-17693: - Summary: Upgrade to Apache Curator 3.8.0 Key: SOLR-17693 URL: https://issues.apache.org/jira/browse/SOLR-17693 Project: Solr Issue Type: Sub-task Reporter: Houston Putman This Curator release includes the necessary things to be able to use Curator Recipes in Apache Solr. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17547: Collect ZK Metrics via Curator [solr]
HoustonPutman commented on PR #2850: URL: https://github.com/apache/solr/pull/2850#issuecomment-2707096925 So watch firing events are still not able to be monitored by zookeeper or Curator, so we will have to manage that on our own still using our watcher wrapper. This is probably something we can add in the next Curator version and not something that should stop us from using recipes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1985660911
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -210,6 +236,16 @@ public boolean requiresCollection() {
return false;
}
+ /**
+ * Indicates if clients should make attempts to route this request to a
shard leader, overriding
+ * typical client routing preferences for requests. Defaults to true.
+ *
+ * @see CloudSolrClient#isUpdatesToLeaders
+ */
+ public boolean shouldSendToLeaders() {
Review Comment:
I question that we want this. Maybe this pre-dated
`org.apache.solr.common.params.ShardParams#SHARDS_PREFERENCE` where you can
accomplish the same thing. Ideally this method goes away (and goes away from
AbstractUpdateRequest).
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudSolrClient.java:
##
@@ -787,7 +786,7 @@ protected NamedList requestWithRetryOnStaleState(
if (request instanceof V2Request) {
isCollectionRequestOfV2 = ((V2Request) request).isPerCollectionRequest();
}
-boolean isAdmin = ADMIN_PATHS.contains(request.getPath());
+boolean isAdmin = request.getRequestType() == SolrRequestType.ADMIN;
Review Comment:
awesome
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -185,8 +188,31 @@ public void setQueryParams(Set queryParams) {
this.queryParams = queryParams;
}
- /** This method defines the type of this Solr request. */
- public abstract String getRequestType();
+ /**
+ * Defines the intended type of this Solr request.
+ *
+ * Subclasses should typically override this method instead of {@link
+ * SolrRequest#getRequestType}. Note that changing request type can
break/impact request routing
+ * within various clients (i.e. {@link CloudSolrClient}).
+ */
+ protected SolrRequestType getBaseRequestType() {
Review Comment:
`getBaseRequestType` seems sad to me; and I sympathize with Luke's musings.
I'd like to see this method go away. I like's Luke's suggestion on a field.
But going towards immutable is a bit much IMO.
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java:
##
@@ -53,8 +53,9 @@ public ModifiableSolrParams getParams() {
}
@Override
- public String getRequestType() {
-return SolrRequestType.ADMIN.toString();
+ /* This request is not processed as an ADMIN request. */
+ protected SolrRequestType getBaseRequestType() {
+return SolrRequestType.UNSPECIFIED;
Review Comment:
Can we make changes like this in a follow-up PR so that this PR is more
focused on the refactoring instead of the choice of classifications?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17694) LeaderElector not able to parse node ID correctly when it has a leading dash
Patrick created SOLR-17694:
--
Summary: LeaderElector not able to parse node ID correctly when it
has a leading dash
Key: SOLR-17694
URL: https://issues.apache.org/jira/browse/SOLR-17694
Project: Solr
Issue Type: Bug
Reporter: Patrick
This issue was
[reported|https://lists.apache.org/thread/0pwxw1rzdffmbxctdzv2rmplzgwt6lpl] on
us...@solr.apache.org.
There could be time (e.g.: ZOOKEEPER-4904) when the node ID contains a leading
dash
{noformat}
-5188057493699159958-1.1.1.15:8983_solr-n_192189
{noformat}
instead of just
{noformat}
5188057493699159958-1.1.1.15:8983_solr-n_192189
{noformat}
In such case, LeaderElector.getNodeName returns
*5188057493699159958-1.1.1.15:8983_solr* instead of just
{*}1.1.1.15:8983_solr{*}.
The problem is that the regex LeaderElector.NODE_NAME was not designed to
handle the leading dash. LeaderElector.LEADER_SEQ and LeaderElector.SESSION_ID
seem to have the same problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17656) Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
[
https://issues.apache.org/jira/browse/SOLR-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933472#comment-17933472
]
Houston Putman commented on SOLR-17656:
---
I think this inadvertently created a bug that when {{testRealTimeGet}} runs
after the new {{testSkipLeaderRecoveryProperty}} it can hit:
{quote}{{> org.apache.solr.client.solrj.SolrServerException: IOException
occurred when talking to server at: [https://127.0.0.1:42033/solr]}}
{{> at
__randomizedtesting.SeedInfo.seed([BBB06E01532385D3:E3DD9B02F1992B1A]:0)}}
{{> at
app//org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:736)}}
{{> at
app//org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:260)}}
{{> at
app//org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:239)}}
{{> at
app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:279)}}
{{> at app//org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:166)}}
{{> at app//org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:131)}}
{{> at app//org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:147)}}
{{> at
app//org.apache.solr.cloud.TestPullReplica.testRealTimeGet(TestPullReplica.java:497)}}
{quote}
{{I'll see if I can fix it quickly.}}
> Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
> ---
>
> Key: SOLR-17656
> URL: https://issues.apache.org/jira/browse/SOLR-17656
> Project: Solr
> Issue Type: New Feature
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: main (10.0), 9.9
>
> Attachments: SOLR-17656-1.patch, SOLR-17656.patch
>
>
> In situations where a Solr cluster undergoes a rolling restart (or some other
> "catastrophic" failure situations requiring/causing solr node restarts) there
> can be a snowball effect of poor performance (or even solr node crashing) due
> to fewer then normal replicas serving query requests while replicas on
> restarting nodes are DOWN or RECOVERING – especially if shard leaders are
> also affected, and (restarting) replicas first must wait for a leader
> election before they can recover (or wait to finish recovery from an
> over-worked leader).
> For NRT type usecases, RECOVERING is really a necessary evil to ensure every
> replicas is up to date before handling NRT requests – but in the case of PULL
> replicas, which are expected to routinely "lag" behind their leader, I've
> talked to a lot of Solr users w/usecases where they would be happy to have
> PULL replicas back online serving "stale" data ASAP, and let normal
> IndexFetching "catchup" with the leader later.
> I propose we support a new "advanced" replica property that can be set on
> PULL replicas by expert level users, to indicate: on (re)init, these replicas
> may skip RECOVERING and go directly to ACTIVE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17537: Manage ZK Compression through Curator [solr]
HoustonPutman commented on PR #2849: URL: https://github.com/apache/solr/pull/2849#issuecomment-2707394159 Yeah, I'm not changing how the configuration is done, just how it's handled in the backend. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17547: Collect ZK Metrics via Curator [solr]
HoustonPutman commented on PR #2850: URL: https://github.com/apache/solr/pull/2850#issuecomment-2706991788 With Curator 5.8 released and now used in Solr, the issues mentioned should be fixed and this should be good to go! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17309: Enhance certificate based authentication plugin with flexible cert principal resolution [solr]
laminelam commented on PR #3029: URL: https://github.com/apache/solr/pull/3029#issuecomment-2707040472 > @laminelam updating from main fixed things. Can you confirm the `security.hadoop` change? So in main we no longer have Hadoop, so I don't think it's needed. Is it required for backporting to 9x to make this work? If we don't need it, it would simplify things to not have it! Yes we don't need it. Removed it. No errors in the pre-commit. Thanks for the merge. :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17547) Collect ZK Metrics via Curator
[ https://issues.apache.org/jira/browse/SOLR-17547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933395#comment-17933395 ] Houston Putman commented on SOLR-17547: --- So watch firing events are still not able to be monitored by zookeeper or Curator, so we will have to manage that on our own still using our watcher wrapper. This is probably something we can add in the next Curator version and not something that should stop us from using recipes. (The async watch execution is still open currently, so we have to wrap the existing watches anyways) > Collect ZK Metrics via Curator > -- > > Key: SOLR-17547 > URL: https://issues.apache.org/jira/browse/SOLR-17547 > Project: Solr > Issue Type: Sub-task >Reporter: Houston Putman >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently metrics are collected via SolrZkClient, however we should be able > to push this down and create listeners for Curator that will collect the same > information. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SimpleOrderedMap MapWriter constructor [solr]
dsmiley commented on PR #3235: URL: https://github.com/apache/solr/pull/3235#issuecomment-2707429514 Planning to merge Monday, backporting to 9x. Commit message will be similar to PR description, which is the first commit's message. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17688: Http2SolrClient: use Request.Listener not HttpListenerFactory [solr]
dsmiley commented on PR #3233: URL: https://github.com/apache/solr/pull/3233#issuecomment-2707447434 Planning to merge Tuesday. Beforehand will look closer at the errors that I did see, which seemed intermittent and unrelated. CHANGES.txt comment proposal in Other: > SolrJ: replaced Http2SolrClient.Builder.withListenerFactory with withRequestListeners; using Jetty abstractions instead, and integrating directly with Jetty HttpClient. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17656) Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
[ https://issues.apache.org/jira/browse/SOLR-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933481#comment-17933481 ] ASF subversion and git services commented on SOLR-17656: Commit 00eaa995bb633d8604c6ace363a6e7841563f897 in solr's branch refs/heads/branch_9x from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=00eaa995bb6 ] SOLR-17656: Fix TestPullReplica.testRealTimeGet() (cherry picked from commit b81dc4b5f29441806235a51ee87970a93bddeac5) > Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING > --- > > Key: SOLR-17656 > URL: https://issues.apache.org/jira/browse/SOLR-17656 > Project: Solr > Issue Type: New Feature >Reporter: Chris M. Hostetter >Assignee: Chris M. Hostetter >Priority: Major > Fix For: main (10.0), 9.9 > > Attachments: SOLR-17656-1.patch, SOLR-17656.patch > > > In situations where a Solr cluster undergoes a rolling restart (or some other > "catastrophic" failure situations requiring/causing solr node restarts) there > can be a snowball effect of poor performance (or even solr node crashing) due > to fewer then normal replicas serving query requests while replicas on > restarting nodes are DOWN or RECOVERING – especially if shard leaders are > also affected, and (restarting) replicas first must wait for a leader > election before they can recover (or wait to finish recovery from an > over-worked leader). > For NRT type usecases, RECOVERING is really a necessary evil to ensure every > replicas is up to date before handling NRT requests – but in the case of PULL > replicas, which are expected to routinely "lag" behind their leader, I've > talked to a lot of Solr users w/usecases where they would be happy to have > PULL replicas back online serving "stale" data ASAP, and let normal > IndexFetching "catchup" with the leader later. > I propose we support a new "advanced" replica property that can be set on > PULL replicas by expert level users, to indicate: on (re)init, these replicas > may skip RECOVERING and go directly to ACTIVE. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
