[jira] [Commented] (SOLR-14892) shards.info with shards.tolerant can yield an empty key
[ https://issues.apache.org/jira/browse/SOLR-14892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17821040#comment-17821040 ] Mathieu Marie commented on SOLR-14892: -- I updated my (years old) PR > shards.info with shards.tolerant can yield an empty key > --- > > Key: SOLR-14892 > URL: https://issues.apache.org/jira/browse/SOLR-14892 > Project: Solr > Issue Type: Bug > Components: search >Reporter: David Smiley >Priority: Minor > Attachments: solr14892.png > > Time Spent: 40m > Remaining Estimate: 0h > > When using shards.tolerant=true and shards.info=true when a shard isn't > available (and maybe other circumstances), the shards.info section of the > response may have an empty-string key child with a value that is ambiguous as > to which shard(s) couldn't be reached. > This problem can be revealed by modifying > org.apache.solr.cloud.TestDownShardTolerantSearch#searchingShouldFailWithoutTolerantSearchSetToTrue > to add shards.info and then examine the response in a debugger. -- 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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
gus-asf commented on PR #2301: URL: https://github.com/apache/solr/pull/2301#issuecomment-1965858456 > > We just got rid of commons-io, https://issues.apache.org/jira/browse/SOLR-15784 > > Can you find an alternative that is already a dependency, or copy just the code we need into one of Solr's util classes? > > Updated this to just reuse the applicable code from commons-io without the dependency. I'd like to use that code since we know it will perform the same as previous Solr versions. Hmm, problem with copying code out of other libraries is we won't get any bug-fixes with new versions or be aware of relevant CVE's in the copied code. Might be better to just have the dependency? -- 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-14607: LTR Query, the TimeAllowed parameter causes a timeout exception after no results [solr]
github-actions[bot] commented on PR #8: URL: https://github.com/apache/solr/pull/8#issuecomment-1965543158 This PR had no visible activity in the past 60 days, labeling it as stale. Any new activity will remove the stale label. To attract more reviewers, please tag someone or notify the d...@solr.apache.org mailing list. Thank you for your contribution! -- 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-14690: QueryResultKey.[nc_]minExactCount [solr]
github-actions[bot] commented on PR #13: URL: https://github.com/apache/solr/pull/13#issuecomment-1965543126 This PR had no visible activity in the past 60 days, labeling it as stale. Any new activity will remove the stale label. To attract more reviewers, please tag someone or notify the d...@solr.apache.org mailing list. Thank you for your contribution! -- 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-15152: Export Tool should export nested docs cleanly in .json, .jsonl, and javabin [solr]
github-actions[bot] commented on PR #33: URL: https://github.com/apache/solr/pull/33#issuecomment-1965543103 This PR had no visible activity in the past 60 days, labeling it as stale. Any new activity will remove the stale label. To attract more reviewers, please tag someone or notify the d...@solr.apache.org mailing list. Thank you for your contribution! -- 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] Remove ingress and node-services during reconcile [solr-operator]
janhoy commented on code in PR #674:
URL: https://github.com/apache/solr-operator/pull/674#discussion_r1503423348
##
controllers/solrcloud_controller.go:
##
@@ -167,6 +167,21 @@ func (r *SolrCloudReconciler) Reconcile(ctx
context.Context, req ctrl.Request) (
}
}
}
+ } else {
+ // Need no individual services per onde, delete if found
+ for _, nodeName := range solrNodeNames {
+ serviceName := nodeName
+ foundService := &corev1.Service{}
+ err = r.Get(ctx, types.NamespacedName{Name:
serviceName, Namespace: instance.Namespace}, foundService)
+ if err == nil {
+ err = r.Delete(ctx, foundService)
Review Comment:
Added logging both for service deletion and ingress deletion
--
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: [I] Ability to set custom hostname for SolrCloud [solr-operator]
HoustonPutman commented on issue #667: URL: https://github.com/apache/solr-operator/issues/667#issuecomment-1965472963 Yeah, I agree that could be cool! -- 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: [I] Authentication not woking with solr-cloud. Pods are getting restarted. [solr-operator]
HoustonPutman closed issue #681: Authentication not woking with solr-cloud. Pods are getting restarted. URL: https://github.com/apache/solr-operator/issues/681 -- 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: [I] User helm chart 0.8.0 with default values thorw the error in ValidationError(SolrCloud.spec): unknown field "scaling" in org.apache.solr.v1beta1.SolrCloud.spec [solr-operator]
HoustonPutman commented on issue #683: URL: https://github.com/apache/solr-operator/issues/683#issuecomment-1965468246 You first have to update the CRDs in your cluster, before updating the Solr Operator helm chart or you Solr cluster helm charts. Docs - https://apache.github.io/solr-operator/docs/upgrade-notes.html#installing-the-solr-operator-vs-solr-crds -- 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: [I] User helm chart 0.8.0 with default values thorw the error in ValidationError(SolrCloud.spec): unknown field "scaling" in org.apache.solr.v1beta1.SolrCloud.spec [solr-operator]
HoustonPutman closed issue #683: User helm chart 0.8.0 with default values thorw the error in ValidationError(SolrCloud.spec): unknown field "scaling" in org.apache.solr.v1beta1.SolrCloud.spec URL: https://github.com/apache/solr-operator/issues/683 -- 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: [I] Getting unauthorized requests for cluster/replicas/balance in v0.8.0 [solr-operator]
HoustonPutman commented on issue #653: URL: https://github.com/apache/solr-operator/issues/653#issuecomment-1965464594 @mmoscher , that is expected. After the completion of an ephemeral rolling restart, the Solr Operator now tries to balance the cluster. If Solr doesn't support that command (and 9.0 does not), it just completes the operation. But the only way that the Solr Operator can know if it's supported is to try running it. @ozlerhakan I think that is something that we missed. I'll try to add a PR for that soon. -- 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: [I] The SolrPrometheusExporter should detect whether to use a basicAuth secret [solr-operator]
HoustonPutman commented on issue #654: URL: https://github.com/apache/solr-operator/issues/654#issuecomment-1965458362 Sorry, I missed this. But yes, you are on the right path! -- 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] Remove ingress and node-services during reconcile [solr-operator]
HoustonPutman commented on code in PR #674:
URL: https://github.com/apache/solr-operator/pull/674#discussion_r1503398995
##
controllers/solrcloud_controller.go:
##
@@ -167,6 +167,21 @@ func (r *SolrCloudReconciler) Reconcile(ctx
context.Context, req ctrl.Request) (
}
}
}
+ } else {
Review Comment:
This looks pretty straightforward to me. I'd say we should do it for the
headless service as well, but honestly we might want to just always make a
headless service for simplicity...
##
controllers/solrcloud_controller.go:
##
@@ -167,6 +167,21 @@ func (r *SolrCloudReconciler) Reconcile(ctx
context.Context, req ctrl.Request) (
}
}
}
+ } else {
+ // Need no individual services per onde, delete if found
+ for _, nodeName := range solrNodeNames {
+ serviceName := nodeName
+ foundService := &corev1.Service{}
+ err = r.Get(ctx, types.NamespacedName{Name:
serviceName, Namespace: instance.Namespace}, foundService)
+ if err == nil {
+ err = r.Delete(ctx, foundService)
Review Comment:
We would likely want to log here that we are deleting the service.
--
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-17181) Performance degradation matching glob patterns for fields
[ https://issues.apache.org/jira/browse/SOLR-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820893#comment-17820893 ] ASF subversion and git services commented on SOLR-17181: Commit 78187de26b1bdfcb0ae340645d175abc46aa457c in solr's branch refs/heads/branch_9x from Justin Sweeney [ https://gitbox.apache.org/repos/asf?p=solr.git;h=78187de26b1 ] SOLR-17181: Using apache commons implementation for wildcard matching for glob patterns (#2301) * Using apache commons implementation for wildcard matching for glob patterns * Removing commons io dependency and instead reusing applicable code from that library * Fixing comments with Javadoc links * Actually fixing comments with Javadoc links * Fixing javadoc comments > Performance degradation matching glob patterns for fields > - > > Key: SOLR-17181 > URL: https://issues.apache.org/jira/browse/SOLR-17181 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query, search >Affects Versions: 9.5.0 >Reporter: Justin Sweeney >Assignee: Justin Sweeney >Priority: Major > Labels: fl, performance > Time Spent: 1.5h > Remaining Estimate: 0h > > This ticket: https://issues.apache.org/jira/browse/SOLR-17022 seems to have > cause some performance degradation when matching glob patterns to fields as > noted in this thread: > https://lists.apache.org/thread/vbwnjxprl6s1qy0t1jzfcw8hprg1gvzh. -- 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-17181) Performance degradation matching glob patterns for fields
[ https://issues.apache.org/jira/browse/SOLR-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820892#comment-17820892 ] ASF subversion and git services commented on SOLR-17181: Commit d3a5908517ba65e4ad7c116d07fe2012a490184c in solr's branch refs/heads/main from Justin Sweeney [ https://gitbox.apache.org/repos/asf?p=solr.git;h=d3a5908517b ] SOLR-17181: Using apache commons implementation for wildcard matching for glob patterns (#2301) * Using apache commons implementation for wildcard matching for glob patterns * Removing commons io dependency and instead reusing applicable code from that library * Fixing comments with Javadoc links * Actually fixing comments with Javadoc links * Fixing javadoc comments > Performance degradation matching glob patterns for fields > - > > Key: SOLR-17181 > URL: https://issues.apache.org/jira/browse/SOLR-17181 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query, search >Affects Versions: 9.5.0 >Reporter: Justin Sweeney >Assignee: Justin Sweeney >Priority: Major > Labels: fl, performance > Time Spent: 1.5h > Remaining Estimate: 0h > > This ticket: https://issues.apache.org/jira/browse/SOLR-17022 seems to have > cause some performance degradation when matching glob patterns to fields as > noted in this thread: > https://lists.apache.org/thread/vbwnjxprl6s1qy0t1jzfcw8hprg1gvzh. -- 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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
justinrsweeney merged PR #2301: URL: https://github.com/apache/solr/pull/2301 -- 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-17160: Time based tracking of core admin requests [solr]
psalagnac commented on PR #2271: URL: https://github.com/apache/solr/pull/2271#issuecomment-1965436549 > Instead of the manual cache management, can't we use CaffeineCache as is used elsewhere in Solr? CC @bruno-roustant Thanks for the suggestion. I filled #2304 that achieves the same, with a Caffeine cache. -- 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
[PR] SOLR-17160: Time based tracking of core admin requests with Caffeine cache [solr]
psalagnac opened a new pull request, #2304: URL: https://github.com/apache/solr/pull/2304 https://issues.apache.org/jira/browse/SOLR-17160 This is a simpler version of #2271, that now uses Caffeine cache instead of manually dropping old requests. # Description Core admin completed/failed requests are tracked in-memory, but we only track a maximum of 100 requests by dropping the oldest ones. If for any reason we drop a request before the client (an other Solr node) fetched the status, we will get unexpected errors at the top level command. # Solution Instead of the hard limit of 100 tracked requests, we track all requests in a Caffeine cache, configured to drop old requests. This is a trade-off to not keep memory forever and to be sure we won't lose status in the case of many incoming requests. The change adds two different timeouts: - an hour for every requests (overridable with property `"solr.admin.requests.running.timeout.minutes"`) - 5 minutes for completed/failed requests once the status is already retrieved by client (overridable with property `"solr.admin.requests.completed.timeout.minutes"`) # Tests Added a unit test in `CoreAdminHandlerTest` to check expired requests are not tracked in-memory anymore. Also checks we don't have any issue for collection backup with very high numbers of shards. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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-16989: Optimize and consolidate reuse of DocValues iterators for value retrieval [solr]
magibney commented on PR #1938: URL: https://github.com/apache/solr/pull/1938#issuecomment-1965303844 I would have loved the review, sorry this didn't get on your radar at the time. Please lmk if you have any concerns about what was committed, or what could/should have been committed alongside; I certainly don't mind revisiting. -- 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-17176: Log history V2 API doesn't serialize properly [solr]
magibney commented on PR #2293: URL: https://github.com/apache/solr/pull/2293#issuecomment-1965252700 I guess just because the results are +/- analogous to SolrDocuments results, in terms of serialized output. numFound, etc. For the purpose of this PR I was trying to leave that unchanged. I think the baggage with serialization is less from the "SolrDocuments" approach _per se_, and more around the exact way in which the initial PR went about constructing the SolrDocuments to be immutable (since they are reused across multiple requests). The biggest problem with the initial PR really was its use of `doc.getFieldValueMap()`, which afaict (I belatedly realize) seems not designed to be used outside of a test context. -- 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-17174) commit to mixedCase cli options or dashed-case cli options
[ https://issues.apache.org/jira/browse/SOLR-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820862#comment-17820862 ] Eric Pugh commented on SOLR-17174: -- Started a thread on [https://lists.apache.org/thread/gt6x9y29twrhvnovg98d7pmpxpsp9zyx] on this topic. > commit to mixedCase cli options or dashed-case cli options > -- > > Key: SOLR-17174 > URL: https://issues.apache.org/jira/browse/SOLR-17174 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Priority: Minor > -- 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] [Resolved] (SOLR-16780) Resolve the bin/solr zk cp and bin/solr cp conundrum
[ https://issues.apache.org/jira/browse/SOLR-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-16780. -- Fix Version/s: 9.6.0 Assignee: Eric Pugh Resolution: Fixed > Resolve the bin/solr zk cp and bin/solr cp conundrum > > > Key: SOLR-16780 > URL: https://issues.apache.org/jira/browse/SOLR-16780 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: main (10.0), 9.2.1 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.6.0 > > Time Spent: 40m > Remaining Estimate: 0h > > We have two commands, bin/solr zk cp and bin/solr cp that appear to be very > similar, but not the same... Maybe one is deprecated over the other? -- 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-16780) Resolve the bin/solr zk cp and bin/solr cp conundrum
[ https://issues.apache.org/jira/browse/SOLR-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820859#comment-17820859 ] ASF subversion and git services commented on SOLR-16780: Commit f03f3281148c46c5ee9a9f9f632acbc6ff91c8a2 in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=f03f3281148 ] SOLR-16780: Prevent ZK subcommands from being run without the bin/solr zk prefix (#2297) * Prevent zk subcommands to being run without the zk prefix! > Resolve the bin/solr zk cp and bin/solr cp conundrum > > > Key: SOLR-16780 > URL: https://issues.apache.org/jira/browse/SOLR-16780 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: main (10.0), 9.2.1 >Reporter: Eric Pugh >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > We have two commands, bin/solr zk cp and bin/solr cp that appear to be very > similar, but not the same... Maybe one is deprecated over the other? -- 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-16780) Resolve the bin/solr zk cp and bin/solr cp conundrum
[ https://issues.apache.org/jira/browse/SOLR-16780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820858#comment-17820858 ] ASF subversion and git services commented on SOLR-16780: Commit f63b937ec3571c7e7e8ca3a811fea754852e321e in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=f63b937ec35 ] SOLR-16780: Prevent ZK subcommands from being run without the bin/solr zk prefix (#2297) * Prevent zk subcommands to being run without the zk prefix! > Resolve the bin/solr zk cp and bin/solr cp conundrum > > > Key: SOLR-16780 > URL: https://issues.apache.org/jira/browse/SOLR-16780 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: main (10.0), 9.2.1 >Reporter: Eric Pugh >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > We have two commands, bin/solr zk cp and bin/solr cp that appear to be very > similar, but not the same... Maybe one is deprecated over the other? -- 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-16780: Prevent ZK subcommands from being run without the bin/solr zk prefix [solr]
epugh merged PR #2297: URL: https://github.com/apache/solr/pull/2297 -- 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-17058) Request param to disable distributed stats request at query time
[
https://issues.apache.org/jira/browse/SOLR-17058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved SOLR-17058.
-
Resolution: Fixed
> Request param to disable distributed stats request at query time
>
>
> Key: SOLR-17058
> URL: https://issues.apache.org/jira/browse/SOLR-17058
> Project: Solr
> Issue Type: New Feature
> Components: query
>Reporter: wei wang
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 9.6.0
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> When distributed IDF is enabled in solr cloud by adding one of the cache
> implementations in solrconfig.xml
> [https://solr.apache.org/guide/solr/latest/deployment-guide/solrcloud-distributed-requests.html#distributedidf],
> each solr query will incur a distributed shard request to get term
> statistics
> "debug": {
> "track": {
> "rid": "-54",
> "PARSE_QUERY": {
> "http://192.168.0.34:8987/solr/shard2_replica_n1/":
> { "QTime": “2”,
>
> "ElapsedTime": "13",
>
> "RequestPurpose": "GET_TERM_STATS",
> …
>
> For queries that does not use distributed IDF information for scoring
> such as terms filter by id, the stats request is not necessary. Hence I
> propose to add a {{distrib.statsCache}} request param so that the distributed
> stats request can be disabled at query time.
> # {{distrib.statsCache}} defaults to {{{}true{}}}. When the param is not
> present, there is no change to current distributed IDF behavior.
> # When explicitly set {{{}distrib.statsCache{}}}{{{}=false{}}}, distributed
> stats call is disabled for the current query.
--
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-16505: Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2 [solr]
dsmiley commented on code in PR #2276:
URL: https://github.com/apache/solr/pull/2276#discussion_r1498431204
##
solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java:
##
@@ -946,7 +939,6 @@ public void onFailure(Throwable throwable) {
}
});
} finally {
- recoveryExec.shutdown();
Review Comment:
By removing this, I see nothing here that will wait for this request to
complete. But that was the semantics before, with the `future.get()` call. It
kinda makes me wonder why we're even bothering with "async" request in the
first place; couldn't we do a standard synchronous HTTP request? One little
thing I did see was the "abort" call. But that could be done via using a
FutureTask and calling `cancel(true)` on it. Basically, the field
`prevSendPreRecoveryHttpUriRequest` because a FutureTask. Set it and call
run() in `sendPrepRecoveryCmd`. I think it's sloppy/ugly to catch NPE in some
places in this file, yuck; we could use a dummy initial FutureTask value.
I think this might end up deferring any "executor" matters in this PR since
we then wouldn't need an executor; right? It'd be a separate PR to improve
Http2SolrClient executor initialization.
##
solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java:
##
@@ -911,18 +911,39 @@ private final void sendPrepRecoveryCmd(String
leaderBaseUrl, String leaderCoreNa
int readTimeout =
conflictWaitMs
+
Integer.parseInt(System.getProperty("prepRecoveryReadTimeoutExtraWait",
"8000"));
-try (HttpSolrClient client =
+var recoveryExec =
+ExecutorUtil.newMDCAwareFixedThreadPool(
+1, new SolrNamedThreadFactory("sendPrepRecoveryCmd"));
+try (Http2SolrClient client =
recoverySolrClientBuilder(
leaderBaseUrl,
null) // leader core omitted since client only used for
'admin' request
-.withSocketTimeout(readTimeout, TimeUnit.MILLISECONDS)
+.withIdleTimeout(readTimeout, TimeUnit.MILLISECONDS)
+.withExecutor(recoveryExec)
.build()) {
- HttpUriRequestResponse mrr = client.httpUriRequest(prepCmd);
- prevSendPreRecoveryHttpUriRequest = mrr.httpUriRequest;
-
log.info("Sending prep recovery command to [{}]; [{}]", leaderBaseUrl,
prepCmd);
-
- mrr.future.get();
+ MDC.put("HttpSolrClient.url", baseUrl);
Review Comment:
Aaaah, you are imitating
`org.apache.solr.client.solrj.impl.HttpSolrClient#httpUriRequest(org.apache.solr.client.solrj.SolrRequest,
org.apache.solr.client.solrj.ResponseParser)`. But there's no need because
the Http2Solrclient natively supports an async method, which should be the
place where any MDC/logging is specified.
Note that below I question if we even need async logic in the first place!
--
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-17172: Add QueryLimits termination to existing heavy SearchComponent-s [solr]
dsmiley commented on code in PR #2290:
URL: https://github.com/apache/solr/pull/2290#discussion_r1503209868
##
solr/core/src/java/org/apache/solr/handler/component/HighlightComponent.java:
##
@@ -164,6 +165,8 @@ public void process(ResponseBuilder rb) throws IOException {
// TODO add this directly to the response?
rb.rsp.add(highlightingResponseField(), convertHighlights(sumData));
}
+QueryLimits queryLimits = QueryLimits.getCurrentLimits();
+queryLimits.maybeExitWithPartialResults("Highlighting process");
Review Comment:
Don't we only want to do these checks in expensive loops, basically?
There's no loop here.
I suggest considering adding to SearchHandler where it loops the components
to call process() and potentially somoe other methods. This would broadly
cover components in a course sense; I think it would alleviate your desire to
put the check where you did here in highlighting (and maybe some other
components).
##
solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc:
##
@@ -284,6 +284,17 @@ The query above allows you to examine the scoring explain
info of the top matchi
The default value of this parameter is blank, which causes no extra "explain
info" to be returned.
+== partialResults Parameter
+
+This parameter controls Solr's behavior when a query execution limit is
reached (e.g. `timeAllowed` or `cpuAllowed`).
+
+When this parameter is set to `true` (default) then even though reaching a
limit terminates further query processing
+Solr will still attempt to return partial results collected so far. These
results may be incomplete in
Review Comment:
In our ascii-doc files, generally start new sentences on new lines. Easier
to read diffs in the future.
Also this sentence is missing an "a" before "non-deterministic"
##
solr/core/src/java/org/apache/solr/search/QueryLimits.java:
##
@@ -73,27 +136,32 @@ public boolean shouldExit() {
* @return A string describing the state pass/fail state of each limit
specified for this request.
*/
public String limitStatusMessage() {
-StringBuilder sb = new StringBuilder();
-boolean first = true;
+if (limits.isEmpty()) {
+ return "This request is unlimited.";
+}
+StringBuilder sb = new StringBuilder("Query limits: ");
for (QueryTimeout limit : limits) {
- if (first) {
-first = false;
-sb.append("Query limits:");
- }
sb.append("[");
sb.append(limit.getClass().getSimpleName());
sb.append(":");
sb.append(limit.shouldExit() ? "LIMIT EXCEEDED" : "within limit");
sb.append("]");
}
-if (sb.length() == 0) {
- return "This request is unlimited.";
-} else {
- return sb.toString();
-}
+return sb.toString();
}
- public boolean isTimeoutEnabled() {
+ /** Return true if there are any limits enabled for the current request. */
+ public boolean isLimitsEnabled() {
return !limits.isEmpty();
}
+
+ /**
+ * Helper method to retrieve the current QueryLimits from {@link
SolrRequestInfo#getRequestInfo()}
+ * if it exists, otherwise it returns {@link #NONE}.
+ */
+ public static QueryLimits getCurrentLimits() {
+return SolrRequestInfo.getRequestInfo() != null
Review Comment:
Can you store this into a variable and then do the null check? Super minor
I know but let's not do a redundant ThreadLocal lookup.
##
solr/core/src/java/org/apache/solr/handler/component/ExpandComponent.java:
##
Review Comment:
ExpandComponent doesn't do heavy work; I don't see the point
##
solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java:
##
@@ -204,10 +204,7 @@ private static DirectoryReader wrapReader(SolrCore core,
DirectoryReader reader)
assert reader != null;
reader = UninvertingReader.wrap(reader,
core.getLatestSchema().getUninversionMapper());
if (useExitableDirectoryReader) { // SOLR-16693 legacy; may be removed.
Probably inefficient.
- SolrRequestInfo requestInfo = SolrRequestInfo.getRequestInfo();
- assert requestInfo != null;
- QueryLimits limits = requestInfo.getLimits();
- reader = ExitableDirectoryReader.wrap(reader, limits);
+ reader = ExitableDirectoryReader.wrap(reader,
QueryLimits.getCurrentLimits());
Review Comment:
Way better; thank you.
##
solr/core/src/java/org/apache/solr/handler/component/MoreLikeThisComponent.java:
##
@@ -127,6 +128,8 @@ public void process(ResponseBuilder rb) throws IOException {
getMoreLikeThese(rb, rb.req.getSearcher(),
rb.getResults().docList, flags);
rb.rsp.add("moreLikeThis", sim);
}
+ QueryLimits queryLimits = QueryLimits.getCurrentLimits();
+ queryLimits.maybeExitWithPartialResults("MoreLikeThis process");
Review Comment:
hard to tell but is this in the per-doc loop?
Re: [PR] SOLR-17176: Log history V2 API doesn't serialize properly [solr]
HoustonPutman commented on PR #2293: URL: https://github.com/apache/solr/pull/2293#issuecomment-1965153406 Why are we converting events to docs? Just so that the result could look something like a query result? I guess this is somewhat unrelated to the PR, but if we skipped the SolrDocument stuff, we wouldn't have to worry about all of the baggage that it comes with around serialization. -- 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-17176: Log history V2 API doesn't serialize properly [solr]
magibney commented on code in PR #2293:
URL: https://github.com/apache/solr/pull/2293#discussion_r1503209269
##
solr/core/src/test/org/apache/solr/logging/TestLogWatcher.java:
##
@@ -104,4 +121,56 @@ public void testLog4jWatcher() throws InterruptedException
{
oldMessages.add(msg);
}
}
+
+ /**
+ * Here we validate that serialization works as expected for several
different methods. Ideally we
+ * would use actual serialization from Jersey/Jackson, since this is what
really happens in V2
+ * APIs. But this is simpler, and should give us roughly equivalent
assurances.
+ */
Review Comment:
Does this seem reasonable? Am I missing a straightforward and/or better way
to directly validate Jersey/Jackson serialization? cc @gerlowskija
--
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
[PR] [SOLR-10059] Handle appended fq params with macros in distributed requests [solr]
tboeghk opened a new pull request, #2303:
URL: https://github.com/apache/solr/pull/2303
https://issues.apache.org/jira/browse/SOLR-10059
# Description
In distributed requests, the appends section of a `RequestHandler` is
evaluated not only on the coordinator but also on the shard nodes of the
distributed request. This leads to parameters being attached multiple times.
This is usually not a problem but if a `fq` parameter that contains a macro is
appended on the shard, the request will crash. This is due to the fact that
macros are not evaluated during shard requests.
```xml
{!collapse tag=collapsing field=bee_sI
sort="${collapseSort}"}
```
# Solution
This fix will remove all `fq` parameters in shard requests that contain
unexpanded macros. Macros should have been expanded on the coordinator. If
macros are present in an `fq` parameter they must have been injected in an
`appends` block.
# Tests
This fix contains a Cloud Test that will fail without the proposed fix and
unit tests for the `MacroSanitizer`.
# Checklist
- [x] I have reviewed the guidelines for [How to
Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my
code conforms to the standards described there to the best of my ability.
- [x] I have created a Jira issue and added the issue ID to my pull request
title.
- [ ] I have given Solr maintainers
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
to contribute to my PR branch. (optional but recommended)
- [x] I have developed this patch against the `main` branch.
- [x] I have run `./gradlew check`.
- [x] I have added tests for my changes.
- [ ] I have added documentation for the [Reference
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
--
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-10059] Handle appends params in distributed requests [solr]
tboeghk commented on PR #159: URL: https://github.com/apache/solr/pull/159#issuecomment-1964928138 I created a new PR https://github.com/apache/solr/pull/2303 that superseeds this PR. -- 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-10059] Handle appends params in distributed requests [solr]
tboeghk commented on PR #159: URL: https://github.com/apache/solr/pull/159#issuecomment-1964868136 I'll file a new PR 👍 -- 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-10059] Handle appends params in distributed requests [solr]
tboeghk closed pull request #159: [SOLR-10059] Handle appends params in distributed requests URL: https://github.com/apache/solr/pull/159 -- 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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
janhoy commented on code in PR #2301:
URL: https://github.com/apache/solr/pull/2301#discussion_r1503012710
##
solr/solrj/src/java/org/apache/solr/common/util/GlobPatternUtil.java:
##
@@ -27,11 +28,161 @@ public class GlobPatternUtil {
* PathMatcher to match glob patterns in the same way to how glob patterns
are matches for file
* paths, rather than implementing our own glob pattern matching.
Review Comment:
Update the javadoc to reflect the 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
Re: [PR] Link Solr Operator for learning on Solr in Kubernetes, and better exp… [solr]
HoustonPutman commented on PR #1114: URL: https://github.com/apache/solr/pull/1114#issuecomment-1964805248 Sorry, I was out on vacation. Thanks for finishing this up and seeing it through! -- 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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
risdenk commented on PR #2301: URL: https://github.com/apache/solr/pull/2301#issuecomment-1964747664 @justinrsweeney would probably open a separate MR to fix that -- 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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
justinrsweeney commented on PR #2301: URL: https://github.com/apache/solr/pull/2301#issuecomment-1964733771 @risdenk I noticed that for the one test failing that seems to be unrelated to changes here, but more of a random occurence. Looking at the code, I think https://github.com/apache/solr/blob/e82f479056a50f3f2d0474254de7389df6bf3ec6/solr/core/src/test/org/apache/solr/update/PeerSyncTest.java#L416 should be changed to sort by ID since the failure here is just an issue with ordering of the documents in the responses. What do you think? -- 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] [Updated] (SOLR-17182) Eliminate the need for 'solr.useExitableDirectoryReader' sysprop
[
https://issues.apache.org/jira/browse/SOLR-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-17182:
--
Description: As the {{QueryLimit}} functionality in Solr gets beefed up,
and supports multiple types of limits, it would be nice if we could find a way
to eliminate the need for the {{solr.useExitableDirectoryReader}} sysprop, and
instead just have codepaths that use the underlying IndexReader (like
faceting, spellcheck, etc...) automatically get a reader that enforces the
limits if/when limits are in use. (was: As the {{QueryLimit}} functionality in
Solr gets beefed up, and supports multiple types of limits, it would be nice if
we could find a way to eliminate the need for the
{{solr.useExitableDirectoryReader}} sysprop, and instead just have codepaths
that use the underlying IndexReader automatically get a reader that enforces
the limits if/when limits are in use.)
> Eliminate the need for 'solr.useExitableDirectoryReader' sysprop
>
>
> Key: SOLR-17182
> URL: https://issues.apache.org/jira/browse/SOLR-17182
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Priority: Major
>
> As the {{QueryLimit}} functionality in Solr gets beefed up, and supports
> multiple types of limits, it would be nice if we could find a way to
> eliminate the need for the {{solr.useExitableDirectoryReader}} sysprop, and
> instead just have codepaths that use the underlying IndexReader (like
> faceting, spellcheck, etc...) automatically get a reader that enforces the
> limits if/when limits are in use.
--
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] [Created] (SOLR-17182) Eliminate the need for 'solr.useExitableDirectoryReader' sysprop
Chris M. Hostetter created SOLR-17182:
-
Summary: Eliminate the need for 'solr.useExitableDirectoryReader'
sysprop
Key: SOLR-17182
URL: https://issues.apache.org/jira/browse/SOLR-17182
Project: Solr
Issue Type: Sub-task
Reporter: Chris M. Hostetter
As the {{QueryLimit}} functionality in Solr gets beefed up, and supports
multiple types of limits, it would be nice if we could find a way to eliminate
the need for the {{solr.useExitableDirectoryReader}} sysprop, and instead just
have codepaths that use the underlying IndexReader automatically get a reader
that enforces the limits if/when limits are in use.
--
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-17158) Terminate distributed processing quickly when query limit is reached
[
https://issues.apache.org/jira/browse/SOLR-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820781#comment-17820781
]
Andrzej Bialecki commented on SOLR-17158:
-
I'm not convinced we need a sysprop here... why shouldn't we use request
handler's {{defaults}} and {{invariants}} sections in {{solrconfig.xml}} ?
Using a sysprop effectively enforces the same default behavior for all replicas
of all collections managed by this Solr node.
> Terminate distributed processing quickly when query limit is reached
>
>
> Key: SOLR-17158
> URL: https://issues.apache.org/jira/browse/SOLR-17158
> Project: Solr
> Issue Type: Sub-task
> Components: Query Limits
>Reporter: Andrzej Bialecki
>Assignee: Gus Heck
>Priority: Major
>
> Solr should make sure that when query limits are reached and partial results
> are not needed (and not wanted) then both the processing in shards and in the
> query coordinator should be terminated as quickly as possible, and Solr
> should minimize wasted resources spent on eg. returning data from the
> remaining shards, merging responses in the coordinator, or returning any data
> back to the user.
--
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-17156: introducing RandomNoReverseMergePolicyFactory [solr]
dsmiley commented on PR #2289: URL: https://github.com/apache/solr/pull/2289#issuecomment-1964559036 > if this bi-arg constructor works, should I use RuleChain or just @Rule RuleChain is for more compactly listing many rules and/or if the ordering is important and should be clear. Here, I think simply @ClassRule for an entire test source file (aka test suite). > Then if I use this rule, I need to copy-paste prop name from systemSetPropertySolrTestsMergePolicyFactory that doesn't seem good for me. Could define the Map.of(...,...) constant in SolrTestCase. This rule accepts a Map constructor. I personally don't care; string literals don't bother me. Some people seem religious about avoiding them. 🤷 -- 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-14115) Deprecate zkcli.sh
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820763#comment-17820763 ] Eric Pugh commented on SOLR-14115: -- i am going to do the minium to get Cluster command done. However, it appears the bin/solr cluster could mimic the pattern of bin/solr config, and implement these apis.. https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterprop > Deprecate zkcli.sh > -- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- 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-17181) Performance degradation matching glob patterns for fields
[ https://issues.apache.org/jira/browse/SOLR-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Sweeney updated SOLR-17181: -- Component/s: query search > Performance degradation matching glob patterns for fields > - > > Key: SOLR-17181 > URL: https://issues.apache.org/jira/browse/SOLR-17181 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query, search >Affects Versions: 9.5.0 >Reporter: Justin Sweeney >Assignee: Justin Sweeney >Priority: Major > Labels: fl, performance > Time Spent: 50m > Remaining Estimate: 0h > > This ticket: https://issues.apache.org/jira/browse/SOLR-17022 seems to have > cause some performance degradation when matching glob patterns to fields as > noted in this thread: > https://lists.apache.org/thread/vbwnjxprl6s1qy0t1jzfcw8hprg1gvzh. -- 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-17181) Performance degradation matching glob patterns for fields
[ https://issues.apache.org/jira/browse/SOLR-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Sweeney updated SOLR-17181: -- Labels: fl performance (was: ) > Performance degradation matching glob patterns for fields > - > > Key: SOLR-17181 > URL: https://issues.apache.org/jira/browse/SOLR-17181 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.5.0 >Reporter: Justin Sweeney >Assignee: Justin Sweeney >Priority: Major > Labels: fl, performance > Time Spent: 50m > Remaining Estimate: 0h > > This ticket: https://issues.apache.org/jira/browse/SOLR-17022 seems to have > cause some performance degradation when matching glob patterns to fields as > noted in this thread: > https://lists.apache.org/thread/vbwnjxprl6s1qy0t1jzfcw8hprg1gvzh. -- 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] [Resolved] (SOLR-17179) Performance degradation with fl=abc_* in 9.5.0
[
https://issues.apache.org/jira/browse/SOLR-17179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Sweeney resolved SOLR-17179.
---
Resolution: Duplicate
> Performance degradation with fl=abc_* in 9.5.0
> --
>
> Key: SOLR-17179
> URL: https://issues.apache.org/jira/browse/SOLR-17179
> Project: Solr
> Issue Type: Bug
> Components: query, search
>Affects Versions: 9.5.0
>Reporter: Alex Tkachuk
>Assignee: Justin Sweeney
>Priority: Major
> Labels: fl, performance
> Attachments: 9.4.1_trace.png, 9.5.0_trace.png
>
>
> Huge (3+x!) performance degradation with "fl=abc_*" occurs with version 9.5.0
> due to the use of
> {code:java}
> org.apache.solr.common.util.GlobPatternUtil.matches
> {code}
> instead of (in <=9.4.1)
> {code:java}
> org.apache.commons.io.FilenameUtils.wildcardMatch
> {code}
> , which is very inefficient and was introduced with [Github pull
> request|https://github.com/apache/solr/pull/1996/files#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> | issue SOLR-17022
> Call tree 9.4.1 vs 9.5.0 attached
--
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-17179) Performance degradation with fl=abc_* in 9.5.0
[
https://issues.apache.org/jira/browse/SOLR-17179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820758#comment-17820758
]
Justin Sweeney commented on SOLR-17179:
---
I created a different Jira (linked) and have a PR open to resolve this, so I'm
going to close this one to track with the Jira that has the PR attached.
> Performance degradation with fl=abc_* in 9.5.0
> --
>
> Key: SOLR-17179
> URL: https://issues.apache.org/jira/browse/SOLR-17179
> Project: Solr
> Issue Type: Bug
> Components: query, search
>Affects Versions: 9.5.0
>Reporter: Alex Tkachuk
>Assignee: Justin Sweeney
>Priority: Major
> Labels: fl, performance
> Attachments: 9.4.1_trace.png, 9.5.0_trace.png
>
>
> Huge (3+x!) performance degradation with "fl=abc_*" occurs with version 9.5.0
> due to the use of
> {code:java}
> org.apache.solr.common.util.GlobPatternUtil.matches
> {code}
> instead of (in <=9.4.1)
> {code:java}
> org.apache.commons.io.FilenameUtils.wildcardMatch
> {code}
> , which is very inefficient and was introduced with [Github pull
> request|https://github.com/apache/solr/pull/1996/files#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> | issue SOLR-17022
> Call tree 9.4.1 vs 9.5.0 attached
--
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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
justinrsweeney commented on PR #2301: URL: https://github.com/apache/solr/pull/2301#issuecomment-1964513916 > Do we have a test case here that includes Unicode in the file name? For example https://docs.modular.com/mojo/faq.html#why-does-mojo-have-the-file-extension > > Edit: that might not apply, I skimmed the change without realising we're talking about field names here Not including a unicode test here since field names should be alphanumeric and that is what current use cases are checking. -- 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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
justinrsweeney commented on PR #2301: URL: https://github.com/apache/solr/pull/2301#issuecomment-1964509548 > We just got rid of commons-io, https://issues.apache.org/jira/browse/SOLR-15784 > > Can you find an alternative that is already a dependency, or copy just the code we need into one of Solr's util classes? Updated this to just reuse the applicable code from commons-io without the dependency. I'd like to use that code since we know it will perform the same as previous Solr versions. -- 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-17066) Deprecate and remove core URLs in HttpSolrClient and friends
[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820750#comment-17820750
]
ASF subversion and git services commented on SOLR-17066:
Commit c5709bd4135538fffba3b2c4947dd91ff28d5750 in solr's branch
refs/heads/main from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=c5709bd4135 ]
SOLR-17066: Switch "LB" clients away from core URLs (#2283)
Providing a core URL String as a SolrClient's "base URL" prevents
it from communicating with other cores or making core-agnostic API
requests (e.g. node healthcheck, list cores, etc.)
This commit migrates usage of both "LB" clients away from using
raw core-URL Strings, in favor of using a new structured 'Endpoint'
class, which allows access to both the "root URL" and "collection"
separately.
This commit also updates various ref-guides and Javadoc snippets to
reflect the fact that clients now only accept "root URLs" (with a small
exception for LB clients which may use the Endpoint class, as mentioned
above).
> Deprecate and remove core URLs in HttpSolrClient and friends
>
>
> Key: SOLR-17066
> URL: https://issues.apache.org/jira/browse/SOLR-17066
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Major
> Time Spent: 12.5h
> Remaining Estimate: 0h
>
> Currently, URL-driven SolrClients can consume a base URL that either ends in
> an API-version specific path ("/solr" for v1 APIs, "/api" for v2), or in the
> full path to a specific core or collection ("/solr/techproducts").
> The latter option causes a number of problems in practice. It prevents the
> client from being used for any "admin" requests or for requests to other
> cores or collections. (Short of running a regex on
> {{SolrClient.getBaseURL}}, it's hard to even tell which of these restrictions
> a given client might have.) And lastly, specifying such core/collection URL
> makes it tough mix and match v1 and v2 API requests within the same client
> (see SOLR-17044).
> We should give SolrJ users some similar way to default collection/cores
> without any of these downsides. One approach would be to extend the
> {{withDefaultCollection}} pattern currently established in
> {{CloudHttp2SolrClient.Builder}}.
> (IMO we should also revisit the division of responsibilities between
> SolrClient and SolrRequest implementations - maybe clients shouldn't,
> directly at least, be holding on to request-specific settings like the
> core/collection at all. But that's a much larger concern that we might not
> want to wade into here. See SOLR-10466 for more on this topic.)
--
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-17066: Switch "LB" clients away from core URLs [solr]
gerlowskija merged PR #2283: URL: https://github.com/apache/solr/pull/2283 -- 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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
madrob commented on PR #2301: URL: https://github.com/apache/solr/pull/2301#issuecomment-1964447694 Do we have a test case here that includes Unicode in the file name? For example https://docs.modular.com/mojo/faq.html#why-does-mojo-have-the-file-extension -- 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] [Assigned] (SOLR-17179) Performance degradation with fl=abc_* in 9.5.0
[
https://issues.apache.org/jira/browse/SOLR-17179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Sweeney reassigned SOLR-17179:
-
Assignee: Justin Sweeney
> Performance degradation with fl=abc_* in 9.5.0
> --
>
> Key: SOLR-17179
> URL: https://issues.apache.org/jira/browse/SOLR-17179
> Project: Solr
> Issue Type: Bug
> Components: query, search
>Affects Versions: 9.5.0
>Reporter: Alex Tkachuk
>Assignee: Justin Sweeney
>Priority: Major
> Labels: fl, performance
> Attachments: 9.4.1_trace.png, 9.5.0_trace.png
>
>
> Huge (3+x!) performance degradation with "fl=abc_*" occurs with version 9.5.0
> due to the use of
> {code:java}
> org.apache.solr.common.util.GlobPatternUtil.matches
> {code}
> instead of (in <=9.4.1)
> {code:java}
> org.apache.commons.io.FilenameUtils.wildcardMatch
> {code}
> , which is very inefficient and was introduced with [Github pull
> request|https://github.com/apache/solr/pull/1996/files#diff-e72c1360a9b0097bcc01e269a94045ce5af1fdc93ae3021ca7e8d1b26d46bdcb]
> | issue SOLR-17022
> Call tree 9.4.1 vs 9.5.0 attached
--
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-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
janhoy commented on PR #2301: URL: https://github.com/apache/solr/pull/2301#issuecomment-1964312811 We just got rid of commons-io, https://issues.apache.org/jira/browse/SOLR-15784 Can you find an alternative that is already a dependency, or copy just the code we need into one of Solr's util classes? -- 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
[PR] SOLR-17066: Add deprecation warnings to 9x methods [solr]
gerlowskija opened a new pull request, #2302: URL: https://github.com/apache/solr/pull/2302 https://issues.apache.org/jira/browse/SOLR-17066 # Description In PR #2283, SOLR-17066 introduced the `LBSolrClient.Endpoint` class, and modified several "LB" client methods to use it on "main". Users who take advantage of these methods in Solr 9 should be given proper notice that they'll be changing (or going away entirely) in Solr 10. # Solution This commit adds the corresponding deprecation notices to branch_9x, so that users can be notified of these changes and start to upgrade their apps where appropriate/required. # Tests N/A - doc change only. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] **I have developed this patch against `branch_9x` branch.** - [ ] I have run `./gradlew check`. - [x] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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-17158) Terminate distributed processing quickly when query limit is reached
[
https://issues.apache.org/jira/browse/SOLR-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820719#comment-17820719
]
Gus Heck commented on SOLR-17158:
-
{quote}FYI, it was necessary to add this parameter in SOLR-17172, I used
{{partialResults=true}} to mean that we should stop processing and return
partial results with "success" code and "partialResults" flag in the response,
and {{partialResults=false}} to mean that we should throw an exception and
discard any partial results.
{quote}
I agree that the request should have a parameter to control this behavior as
well as providing a syprop to determine the result. I am setting it up such
that the parameter takes precedence over the syprop which only determines
default behavior if the parameter is not supplied. May be a complicated merge.
I've got things like this
{code:java}
if (thereArePartialResults && !rb.req.shouldDiscardPartials()) { {code}
That method will want to be use everywhere because it encapsulates logic for
both syprop and params.
> Terminate distributed processing quickly when query limit is reached
>
>
> Key: SOLR-17158
> URL: https://issues.apache.org/jira/browse/SOLR-17158
> Project: Solr
> Issue Type: Sub-task
> Components: Query Limits
>Reporter: Andrzej Bialecki
>Assignee: Gus Heck
>Priority: Major
>
> Solr should make sure that when query limits are reached and partial results
> are not needed (and not wanted) then both the processing in shards and in the
> query coordinator should be terminated as quickly as possible, and Solr
> should minimize wasted resources spent on eg. returning data from the
> remaining shards, merging responses in the coordinator, or returning any data
> back to the user.
--
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
[PR] SOLR-17181: Using apache commons implementation for wildcard matching for glob patterns [solr]
justinrsweeney opened a new pull request, #2301: URL: https://github.com/apache/solr/pull/2301 https://issues.apache.org/jira/browse/SOLR-17181 # Description This is intended to fix a bug raised where glob pattern matching suffered a performance degradation after https://github.com/apache/solr/pull/1996. # Solution This reverts back to using the Apache Commons IO FilenameUtils.wildcardMatch method to do glob pattern matching. This is the original implementation used prior to 9.5 and thus should match performance. This does introduce commons-io as a new library for solrj since glob pattern matching is needed in solrj as well to be available for all use cases. # Tests Using existing tests to validate functionality. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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-17181) Performance degradation matching glob patterns for fields
Justin Sweeney created SOLR-17181: - Summary: Performance degradation matching glob patterns for fields Key: SOLR-17181 URL: https://issues.apache.org/jira/browse/SOLR-17181 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 9.5.0 Reporter: Justin Sweeney This ticket: https://issues.apache.org/jira/browse/SOLR-17022 seems to have cause some performance degradation when matching glob patterns to fields as noted in this thread: https://lists.apache.org/thread/vbwnjxprl6s1qy0t1jzfcw8hprg1gvzh. -- 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] [Assigned] (SOLR-17181) Performance degradation matching glob patterns for fields
[ https://issues.apache.org/jira/browse/SOLR-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Sweeney reassigned SOLR-17181: - Assignee: Justin Sweeney > Performance degradation matching glob patterns for fields > - > > Key: SOLR-17181 > URL: https://issues.apache.org/jira/browse/SOLR-17181 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.5.0 >Reporter: Justin Sweeney >Assignee: Justin Sweeney >Priority: Major > > This ticket: https://issues.apache.org/jira/browse/SOLR-17022 seems to have > cause some performance degradation when matching glob patterns to fields as > noted in this thread: > https://lists.apache.org/thread/vbwnjxprl6s1qy0t1jzfcw8hprg1gvzh. -- 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-15582: Remove deprecated APIs in solrj Tuple class. [solr]
epugh commented on PR #257: URL: https://github.com/apache/solr/pull/257#issuecomment-1964182192 @cpoerschke if you want to update this PR I'll review 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
Re: [PR] SOLR-15469: start/stop script fails on multiple instances [solr]
epugh commented on PR #170: URL: https://github.com/apache/solr/pull/170#issuecomment-1964164331 @piuma I would be interested in picking this back up if you could contribute a BATS test demonstrating the error first. That would make verifying the fix a lot easier ;-). Take a look at https://github.com/apache/solr/blob/main/solr/packaging/test/test_start_solr.bats. -- 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-10059] Handle appends params in distributed requests [solr]
janhoy commented on PR #159: URL: https://github.com/apache/solr/pull/159#issuecomment-1964082304 > I reviewed the fix recently and came up with a smaller fix that isolates the issue better: [otto-de@a82b500](https://github.com/otto-de/solr/commit/a82b500d3c633621b0062698f540c2974a920fbb) > > The fix contains a test that breaks without the fix applied (macros in fq parameter) Ok, translate for me what that means. Can this PR or the JIRA be closed? Will there be a new PR? -- 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-10059] Handle appends params in distributed requests [solr]
tboeghk commented on PR #159: URL: https://github.com/apache/solr/pull/159#issuecomment-1964063238 I reviewed the fix recently and came up with a smaller fix that isolates the issue better: https://github.com/otto-de/solr/commit/a82b500d3c633621b0062698f540c2974a920fbb The fix contains a test that breaks without the fix applied (macros in fq parameter) -- 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-10059] Handle appends params in distributed requests [solr]
janhoy commented on PR #159: URL: https://github.com/apache/solr/pull/159#issuecomment-1963889086 This looks like a good improvement, simple contained fix. -- 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
