Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
dsmiley commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1578800441
##
solr/core/src/java/org/apache/solr/response/transform/SubQueryAugmenterFactory.java:
##
@@ -340,7 +346,9 @@ public void transform(SolrDocument doc, int docid) {
final SolrParams docWithDeprefixed =
SolrParams.wrapDefaults(new DocRowParams(doc, prefix, separator),
baseSubParams);
try {
- QueryResponse rsp = server.query(coreName, docWithDeprefixed);
+ QueryRequest req = new QueryRequest(docWithDeprefixed);
+ req.setUserPrincipal(principal);
+ QueryResponse rsp = req.process(server, coreName);
Review Comment:
I'm kind of concerned this is merely one spot of potentially many other
cases. Could/should we depend on SolrRequestInfo to make this automatic?
##
solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java:
##
@@ -252,7 +260,11 @@ private SolrQueryRequest buildRequestFrom(
new SolrQueryRequestBase(core, params, requestTimer) {
@Override
public Principal getUserPrincipal() {
-return req == null ? null : req.getUserPrincipal();
+if (principal != null) {
+ return principal;
+} else {
+ return req == null ? null : req.getUserPrincipal();
+}
}
Review Comment:
An idea; not totally sure if it'll work until you try: Instead of passing
in a Principal to buildRequestFrom, I think the line you are changing here
could instead see that *if* HttpServletRequest is null, then see if we can use
`org.apache.solr.request.SolrRequestInfo#getUserPrincipal` which works off a
ThreadLocal internally. There may be no SolrRequestInfo either; so ultimately
may have null.
--
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-12813) SolrCloud + 2 shards + subquery + auth = 401 Exception
[
https://issues.apache.org/jira/browse/SOLR-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840607#comment-17840607
]
Rudi Seitz commented on SOLR-12813:
---
Yes, this issue is about BasicAuthPlugin, configured similarly to what is
described in the reference guide
[here|https://solr.apache.org/guide/solr/latest/deployment-guide/basic-authentication-plugin.html#enable-basic-authentication]
This ticket is basically saying that the transparent instrumentation of
AuthenticationPlugin can break in some cases – specifically in the scenario of
a subquery executed in a multi-shard environment.
So why does it break in this particular scenario and not elsewhere? I'll try to
provide more detail later, but the basic idea is that the
SubQueryAgumenterFactory generates _new_ queries that do not share all the
state of the incoming request. And these queries are processed using an
EmbeddedSolrServer that doesn't respect the way BasicAuthPlugin is trying to be
transparently instrumented. My [PR|https://github.com/apache/solr/pull/2404]
shows the specific places where these problems arise and how they can be fixed.
To quickly reproduce the issue described in this issue, one can apply the
changes I made to TestSubQueryTransformerDistrib so that basic auth is enabled.
The modified test should fail against main, without also applying the other
changes in the PR that fix the underlying issue.
https://github.com/apache/solr/commit/d2503ffd9a7cd58c4449c83ff940b63541fce251
> SolrCloud + 2 shards + subquery + auth = 401 Exception
> --
>
> Key: SOLR-12813
> URL: https://issues.apache.org/jira/browse/SOLR-12813
> Project: Solr
> Issue Type: Bug
> Components: security, SolrCloud
>Affects Versions: 6.4.1, 7.5, 8.11
>Reporter: Igor Fedoryn
>Priority: Major
> Attachments: screen1.png, screen2.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Environment: * Solr 6.4.1
> * Zookeeper 3.4.6
> * Java 1.8
> Run Zookeeper
> Upload simple configuration wherein the Solr schema has fields for a
> relationship between parent/child
> Run two Solr instance (2 nodes)
> Create the collection with 1 shard on each Solr nodes
>
> Add parent document to one shard and child document to another shard.
> The response for: *
> /select?q=ChildIdField:VALUE=*,parents:[subqery]=\{!term f=id
> v=$row.ParentIdsField}
> correct.
>
> After that add Basic Authentication with some user for collection.
> Restart Solr or reload Solr collection.
> If the simple request /select?q=*:* with authorization on Solr server is a
> success then run previously request
> with authorization on Solr server and you get the exception: "Solr HTTP
> error: Unauthorized (401) "
>
> Screens in the attachment.
--
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-17255) ClientUtils.encodeLocalParamVal doesn't work with param refs, breaks SolrParams.toLocalParamsString
[
https://issues.apache.org/jira/browse/SOLR-17255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840584#comment-17840584
]
Chris M. Hostetter commented on SOLR-17255:
---
Thinking about it more: {{SolrParams.toLocalParamsString}} also probably has a
bug if/when the value is the empty string? ...
Pretty sure a use case like this will break because it will produce something
like {{... bq= v=foo ...}} which will cause solr to try to use {{v=foo}} as
the value for the {{bq}} local param. Empty strings in local params need to be
quoted.
{code}
final ModifiableSolrParams params = new ModifiableSolrParams();
params.set("type", "edismax");
params.set("bq","");
params.set("v","foo");
System.out.println(params.toLocalParamString())
{code}
> ClientUtils.encodeLocalParamVal doesn't work with param refs, breaks
> SolrParams.toLocalParamsString
> ---
>
> Key: SOLR-17255
> URL: https://issues.apache.org/jira/browse/SOLR-17255
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Chris M. Hostetter
>Priority: Major
>
> If you try to use {{SolrParams.toLocalParamsString}} where some of your param
> values are {{$other_param}} style param references, those refs will wind up
> wrapped in single quotes, preventing the param de-referencing from working.
> Example...
> {code:java}
> final ModifiableSolrParams params = new ModifiableSolrParams();
> params.set("type", "edismax");
> params.set("v","$other_param");
> System.out.println(params.toLocalParamString())
> // Output: {! type=edismax v='$other_param'}
> {code}
> Ironically: {{ClientUtils.encodeLocalParamVal}} actually has a check to see
> if the string starts with {{"$"}} which causes it to bypass a loop that
> checks to see if the string needs to be quoted – but bypassing that loop
> doesn't leave the method variables ({{{}i{}}} and {{{}len{}}}) in a state
> that allow the subsequent short-circut check (which returns the original
> value) to kick in – so the value is always falls through to the {{// We need
> to enclose in quotes... but now we need to escape}} logic
> (It looks like this bug has always existed in every version of these methods)
--
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-17255) ClientUtils.encodeLocalParamVal doesn't work with param refs, breaks SolrParams.toLocalParamsString
[
https://issues.apache.org/jira/browse/SOLR-17255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840583#comment-17840583
]
Chris M. Hostetter commented on SOLR-17255:
---
I think you added {{SolrParams.toLocalParamsString}} but the logic for
handling in {{ClientUtils.encodeLocalParamVal}} dates back much older – it
looks like it was intentionally added by SOLR-2110 ? I haven't really dug
into the history but it looks like that jira (and the tests it add) are trying
to ensure that values starting with {{"$"}} are *intentionally* quoted ...
evidently because of how some facet refinement logic (that calls
{{encodeLocalParamVal}} directly) duplicates {{"key"}} local params and it
must have been trying to derefrence the values when it shouldn't have been?
I suspect the "correct" fix (w/o breaking faceting) is that
{{SolrParams.toLocalParamsString}} should special case check for param refs,
and not delegate to {{ClientUtils.encodeLocalParamVal}} in that case? (and of
course: a lot more tests and javadocs about what callers can/should expect)
> ClientUtils.encodeLocalParamVal doesn't work with param refs, breaks
> SolrParams.toLocalParamsString
> ---
>
> Key: SOLR-17255
> URL: https://issues.apache.org/jira/browse/SOLR-17255
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Chris M. Hostetter
>Priority: Major
>
> If you try to use {{SolrParams.toLocalParamsString}} where some of your param
> values are {{$other_param}} style param references, those refs will wind up
> wrapped in single quotes, preventing the param de-referencing from working.
> Example...
> {code:java}
> final ModifiableSolrParams params = new ModifiableSolrParams();
> params.set("type", "edismax");
> params.set("v","$other_param");
> System.out.println(params.toLocalParamString())
> // Output: {! type=edismax v='$other_param'}
> {code}
> Ironically: {{ClientUtils.encodeLocalParamVal}} actually has a check to see
> if the string starts with {{"$"}} which causes it to bypass a loop that
> checks to see if the string needs to be quoted – but bypassing that loop
> doesn't leave the method variables ({{{}i{}}} and {{{}len{}}}) in a state
> that allow the subsequent short-circut check (which returns the original
> value) to kick in – so the value is always falls through to the {{// We need
> to enclose in quotes... but now we need to escape}} logic
> (It looks like this bug has always existed in every version of these methods)
--
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] Improving array list and map init [solr]
dsmiley commented on code in PR #2197:
URL: https://github.com/apache/solr/pull/2197#discussion_r1578530904
##
solr/core/src/java/org/apache/solr/handler/component/SearchComponent.java:
##
@@ -111,21 +109,16 @@ public void initializeMetrics(SolrMetricsContext
parentContext, String scope) {
this.solrMetricsContext = parentContext.getChildContext(this);
}
- public static final Map>
standard_components;
-
- static {
-HashMap> map = new HashMap<>();
-map.put(HighlightComponent.COMPONENT_NAME, HighlightComponent.class);
-map.put(QueryComponent.COMPONENT_NAME, QueryComponent.class);
-map.put(FacetComponent.COMPONENT_NAME, FacetComponent.class);
-map.put(FacetModule.COMPONENT_NAME, FacetModule.class);
-map.put(MoreLikeThisComponent.COMPONENT_NAME, MoreLikeThisComponent.class);
-map.put(StatsComponent.COMPONENT_NAME, StatsComponent.class);
-map.put(DebugComponent.COMPONENT_NAME, DebugComponent.class);
-map.put(RealTimeGetComponent.COMPONENT_NAME, RealTimeGetComponent.class);
-map.put(ExpandComponent.COMPONENT_NAME, ExpandComponent.class);
-map.put(TermsComponent.COMPONENT_NAME, TermsComponent.class);
-
-standard_components = Collections.unmodifiableMap(map);
- }
+ public static final Map>
standard_components =
+ Map.of(
Review Comment:
agreed
--
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-16505: Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2 [solr]
dsmiley commented on code in PR #2276:
URL: https://github.com/apache/solr/pull/2276#discussion_r1578527066
##
solr/core/src/java/org/apache/solr/handler/IndexFetcher.java:
##
@@ -1878,7 +1870,6 @@ private int fetchPackets(FastInputStream fis) throws
Exception {
log.debug("Fetched and wrote {} bytes of file: {}", bytesDownloaded,
fileName);
// errorCount is always set to zero after a successful packet
errorCount = 0;
- if (bytesDownloaded >= size) return 0;
Review Comment:
That issue merely moved this code slightly; it didn't introduce it. Anyway,
I suppose this code potentially prematurely exited before reading the whole
stream, and that's why you removed 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
Re: [PR] SOLR-17099: snitch does not return spurious tags [solr]
dsmiley commented on code in PR #2278: URL: https://github.com/apache/solr/pull/2278#discussion_r1578520404 ## solr/CHANGES.txt: ## @@ -103,6 +103,7 @@ Optimizations * GITHUB#2217: Scale to 10K+ collections better in ZkStateReader.refreshCollectionsList (David Smiley) +* SOLR-17099: snitch does not return spurious tags (Pierre Salagnac) Review Comment: Speaking of which, please make no reference of "snitch"; it's no longer a user concept but is some internal dubious naming choice. -- 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-17255) ClientUtils.encodeLocalParamVal doesn't work with param refs, breaks SolrParams.toLocalParamsString
[
https://issues.apache.org/jira/browse/SOLR-17255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840578#comment-17840578
]
David Smiley commented on SOLR-17255:
-
Ouch; good catch! I recall writing that a long time ago.
> ClientUtils.encodeLocalParamVal doesn't work with param refs, breaks
> SolrParams.toLocalParamsString
> ---
>
> Key: SOLR-17255
> URL: https://issues.apache.org/jira/browse/SOLR-17255
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: Chris M. Hostetter
>Priority: Major
>
> If you try to use {{SolrParams.toLocalParamsString}} where some of your param
> values are {{$other_param}} style param references, those refs will wind up
> wrapped in single quotes, preventing the param de-referencing from working.
> Example...
> {code:java}
> final ModifiableSolrParams params = new ModifiableSolrParams();
> params.set("type", "edismax");
> params.set("v","$other_param");
> System.out.println(params.toLocalParamString())
> // Output: {! type=edismax v='$other_param'}
> {code}
> Ironically: {{ClientUtils.encodeLocalParamVal}} actually has a check to see
> if the string starts with {{"$"}} which causes it to bypass a loop that
> checks to see if the string needs to be quoted – but bypassing that loop
> doesn't leave the method variables ({{{}i{}}} and {{{}len{}}}) in a state
> that allow the subsequent short-circut check (which returns the original
> value) to kick in – so the value is always falls through to the {{// We need
> to enclose in quotes... but now we need to escape}} logic
> (It looks like this bug has always existed in every version of these methods)
--
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-17243: CloudSolrClient support for req.getBasePath [solr]
dsmiley commented on PR #2414: URL: https://github.com/apache/solr/pull/2414#issuecomment-2075826049 I think as long as QueryRequest continues to have a getBasePath, there is probably a fundamental conceptual issue with some clients supporting it and some not; it doesn't feel well placed on this abstraction. Furthermore it sucks that LBSolrClient mutates this path during processing. I would prefer to see it removed, and instead only HttpSolrClient should support a special request method overloaded that accepts a URL to the node to where the request should be sent. LBSolrClient would use this method instead of mutating setBasePath, and furthermore all the other callers of setBasePath out there would instead use this pattern. I just scanned over all of them outside tests and nearly every one submits the request with a client immediately following calling setBasePath. Again, this suggests that Http2SolrClient should have such an overload. -- 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] [Comment Edited] (SOLR-12813) SolrCloud + 2 shards + subquery + auth = 401 Exception
[
https://issues.apache.org/jira/browse/SOLR-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840566#comment-17840566
]
David Smiley edited comment on SOLR-12813 at 4/24/24 8:23 PM:
--
When using basic auth, is this a reference to BasicAuthPlugin, subclass of
AuthenticationPlugin?
AFAIK, AuthenticationPlugin (of whatever type) is instrumented transparently
within Solr so that Solr code usually just-works correctly.
was (Author: dsmiley):
When using basic auth, is this a reference to BasicAuthPlugin, subclass of
AuthenticationPlugin?
Secondly, does anyone know why only PKIAuthenticationPlugin instruments clients
AFAIK, AuthenticationPlugin (of whatever type) is instrumented transparently
within Solr so that Solr code usually just-works correctly.
> SolrCloud + 2 shards + subquery + auth = 401 Exception
> --
>
> Key: SOLR-12813
> URL: https://issues.apache.org/jira/browse/SOLR-12813
> Project: Solr
> Issue Type: Bug
> Components: security, SolrCloud
>Affects Versions: 6.4.1, 7.5, 8.11
>Reporter: Igor Fedoryn
>Priority: Major
> Attachments: screen1.png, screen2.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Environment: * Solr 6.4.1
> * Zookeeper 3.4.6
> * Java 1.8
> Run Zookeeper
> Upload simple configuration wherein the Solr schema has fields for a
> relationship between parent/child
> Run two Solr instance (2 nodes)
> Create the collection with 1 shard on each Solr nodes
>
> Add parent document to one shard and child document to another shard.
> The response for: *
> /select?q=ChildIdField:VALUE=*,parents:[subqery]=\{!term f=id
> v=$row.ParentIdsField}
> correct.
>
> After that add Basic Authentication with some user for collection.
> Restart Solr or reload Solr collection.
> If the simple request /select?q=*:* with authorization on Solr server is a
> success then run previously request
> with authorization on Solr server and you get the exception: "Solr HTTP
> error: Unauthorized (401) "
>
> Screens in the attachment.
--
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-12813) SolrCloud + 2 shards + subquery + auth = 401 Exception
[
https://issues.apache.org/jira/browse/SOLR-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840566#comment-17840566
]
David Smiley commented on SOLR-12813:
-
When using basic auth, is this a reference to BasicAuthPlugin, subclass of
AuthenticationPlugin?
Secondly, does anyone know why only PKIAuthenticationPlugin instruments clients
AFAIK, AuthenticationPlugin (of whatever type) is instrumented transparently
within Solr so that Solr code usually just-works correctly.
> SolrCloud + 2 shards + subquery + auth = 401 Exception
> --
>
> Key: SOLR-12813
> URL: https://issues.apache.org/jira/browse/SOLR-12813
> Project: Solr
> Issue Type: Bug
> Components: security, SolrCloud
>Affects Versions: 6.4.1, 7.5, 8.11
>Reporter: Igor Fedoryn
>Priority: Major
> Attachments: screen1.png, screen2.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Environment: * Solr 6.4.1
> * Zookeeper 3.4.6
> * Java 1.8
> Run Zookeeper
> Upload simple configuration wherein the Solr schema has fields for a
> relationship between parent/child
> Run two Solr instance (2 nodes)
> Create the collection with 1 shard on each Solr nodes
>
> Add parent document to one shard and child document to another shard.
> The response for: *
> /select?q=ChildIdField:VALUE=*,parents:[subqery]=\{!term f=id
> v=$row.ParentIdsField}
> correct.
>
> After that add Basic Authentication with some user for collection.
> Restart Solr or reload Solr collection.
> If the simple request /select?q=*:* with authorization on Solr server is a
> success then run previously request
> with authorization on Solr server and you get the exception: "Solr HTTP
> error: Unauthorized (401) "
>
> Screens in the attachment.
--
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-16833: Add blog to Solr website [solr-site]
gerlowskija commented on PR #97: URL: https://github.com/apache/solr-site/pull/97#issuecomment-2075748899 Alright, it took me longer than expected to get the first few posts written, but I finally have those done. As things stand right now, when we merge this we'll launch with two posts: - a bit of an explainer behind the motivation for starting a blog, and - a Walkthrough/Tutorial showing how to write and propose a blog post. Would love some review on these if anyone has a few minutes to give them a look! -- 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] [Closed] (SOLR-16044) SlowRequest logging disabled if SolrCore logger set to ERROR
[
https://issues.apache.org/jira/browse/SOLR-16044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl closed SOLR-16044.
--
> SlowRequest logging disabled if SolrCore logger set to ERROR
>
>
> Key: SOLR-16044
> URL: https://issues.apache.org/jira/browse/SOLR-16044
> Project: Solr
> Issue Type: Bug
> Components: logging
> Environment: Solr 8.4
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 9.4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If someone sets ROOT logger to ERROR, then {{SolrCore}} class will also be
> set to ERROR, and even if {{SolrCore.SlowRequest}} level is set to INFO, no
> logs will be written to {{{}solr_slow_requests.log{}}}.
> Some debugging revealed that changing log level of {{SolrCore}} to WARN fixes
> it. This suggests that since {{SlowRequest}} is not a real class but just a
> logger name, it is still subject to the log level of {{SolrCore}}.
> I suppose that the same will be true for {{SolrCore.Request}} logging.
> One solution could be to create a real class for SlowRequest logging. Another
> solution could be to explicitly set {{SolrCore}} level in {{log4j2.xml}} so
> that it does not follow the ROOT level.
--
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]
dsmiley commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1578420780
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws
Exception {
return zkHost;
}
+ public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception
{
+return getSolrZkClient(cli, getZkHost(cli));
+ }
+
+ public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost)
throws Exception {
+if (zkHost == null) {
+ throw new IllegalStateException(
+ "Solr at "
+ + cli.getOptionValue("solrUrl")
+ + " is running in standalone server mode, this command can only
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT,
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+ }
+
+ public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+ }
+
+ public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+ String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost),
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+ }
+
+ private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+ dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);
Review Comment:
`NodeConfig.initModules` has a comment about this going to ModuleUtils. I
think that makes sense, given this new use-case for this utility method. At
that point, think we should use the SolrResourceLoader returned to load a class
that will do the remainder of whatever work, thus putting all the modules on
the class path of all processing henceforth without needing to pass a
SolrResourceLoader around and add it to methods etc.
--
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-17255) ClientUtils.encodeLocalParamVal doesn't work with param refs, breaks SolrParams.toLocalParamsString
Chris M. Hostetter created SOLR-17255:
-
Summary: ClientUtils.encodeLocalParamVal doesn't work with param
refs, breaks SolrParams.toLocalParamsString
Key: SOLR-17255
URL: https://issues.apache.org/jira/browse/SOLR-17255
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Reporter: Chris M. Hostetter
If you try to use {{SolrParams.toLocalParamsString}} where some of your param
values are {{$other_param}} style param references, those refs will wind up
wrapped in single quotes, preventing the param de-referencing from working.
Example...
{code:java}
final ModifiableSolrParams params = new ModifiableSolrParams();
params.set("type", "edismax");
params.set("v","$other_param");
System.out.println(params.toLocalParamString())
// Output: {! type=edismax v='$other_param'}
{code}
Ironically: {{ClientUtils.encodeLocalParamVal}} actually has a check to see if
the string starts with {{"$"}} which causes it to bypass a loop that checks to
see if the string needs to be quoted – but bypassing that loop doesn't leave
the method variables ({{{}i{}}} and {{{}len{}}}) in a state that allow the
subsequent short-circut check (which returns the original value) to kick in –
so the value is always falls through to the {{// We need to enclose in
quotes... but now we need to escape}} logic
(It looks like this bug has always existed in every version of these methods)
--
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-4587: integrate lucene-monitor into solr [solr]
kotman12 commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1578213178
##
solr/modules/monitor/src/java/org/apache/solr/monitor/update/MonitorUpdateProcessorFactory.java:
##
@@ -0,0 +1,56 @@
+/*
+ *
+ * * Licensed to the Apache Software Foundation (ASF) under one or more
+ * * contributor license agreements. See the NOTICE file distributed with
+ * * this work for additional information regarding copyright ownership.
+ * * The ASF licenses this file to You under the Apache License, Version 2.0
+ * * (the "License"); you may not use this file except in compliance with
+ * * the License. You may obtain a copy of the License at
+ * *
+ * * http://www.apache.org/licenses/LICENSE-2.0
+ * *
+ * * Unless required by applicable law or agreed to in writing, software
+ * * distributed under the License is distributed on an "AS IS" BASIS,
+ * * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * * See the License for the specific language governing permissions and
+ * * limitations under the License.
+ *
+ */
+
+package org.apache.solr.monitor.update;
+
+import org.apache.lucene.monitor.MonitorFields;
+import org.apache.lucene.monitor.Presearcher;
+import org.apache.solr.common.util.NamedList;
+import org.apache.solr.monitor.PresearcherFactory;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.update.processor.UpdateRequestProcessor;
+import org.apache.solr.update.processor.UpdateRequestProcessorFactory;
+
+public class MonitorUpdateProcessorFactory extends
UpdateRequestProcessorFactory {
+
+ private Presearcher presearcher = PresearcherFactory.build();
+ private String queryFieldNameOverride;
+ private String payloadFieldNameOverride;
Review Comment:
yea .. this makes sense to me. Is there really any value to these overrides
though? I don't have a good reason why I chose to make these two fields
overridable but not the other reserved fields. Is it safe to assume that a
field prefixed by `_` _won't_ be in the user space anyway? If that is the case
then this override business is overkill. Otherwise, we probably should make
everything overridable.
--
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]
laminelam commented on PR #2417: URL: https://github.com/apache/solr/pull/2417#issuecomment-2075351191 > I am most concerned about the SolrClassLoader proliferation in a bunch of other classes. Can you please explain/justify this? In the context if this [PR](https://github.com/apache/solr/pull/1994), we need to be able to instantiate a _CloudHttp2SolrClient_ whose ZKSolrClient depends on a dependency part of a module. SolrJ doesn't have to modules directly. -- 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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]
laminelam commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1578173456
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws
Exception {
return zkHost;
}
+ public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception
{
+return getSolrZkClient(cli, getZkHost(cli));
+ }
+
+ public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost)
throws Exception {
+if (zkHost == null) {
+ throw new IllegalStateException(
+ "Solr at "
+ + cli.getOptionValue("solrUrl")
+ + " is running in standalone server mode, this command can only
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT,
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+ }
+
+ public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+ }
+
+ public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+ String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost),
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+ }
+
+ private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+ dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);
Review Comment:
Some context
[here](https://github.com/apache/solr/pull/1994#discussion_r1534863816)
If SolrZKClient needs to instantiate a class part of a module, we need to
pass a SolrClassLoader that "contains" the class/dependency.
Now, the only way to load modules/dependencies into SolrClassLoader is to
use the static method
[NodeConfig.initModules](https://github.com/apache/solr/blob/59744b0625d6c9b7b461ad6da9f44a7c6a7313dc/solr/core/src/java/org/apache/solr/core/NodeConfig.java#L523)
I know it's kind if weird but this is, to my knowledge, the only Solr has to
load modules' dependencies.
--
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]
dsmiley commented on code in PR #2417:
URL: https://github.com/apache/solr/pull/2417#discussion_r1578119949
##
solr/core/src/java/org/apache/solr/cli/SolrCLI.java:
##
@@ -607,6 +611,46 @@ public static String getZkHost(CommandLine cli) throws
Exception {
return zkHost;
}
+ public static SolrZkClient getSolrZkClient(CommandLine cli) throws Exception
{
+return getSolrZkClient(cli, getZkHost(cli));
+ }
+
+ public static SolrZkClient getSolrZkClient(CommandLine cli, String zkHost)
throws Exception {
+if (zkHost == null) {
+ throw new IllegalStateException(
+ "Solr at "
+ + cli.getOptionValue("solrUrl")
+ + " is running in standalone server mode, this command can only
be used when running in SolrCloud mode.\n");
+}
+return new SolrZkClient.Builder()
+.withUrl(zkHost)
+.withTimeout(SolrZkClientTimeout.DEFAULT_ZK_CLIENT_TIMEOUT,
TimeUnit.MILLISECONDS)
+.withSolrClassLoader(getSolrResourceLoader())
+.build();
+ }
+
+ public static CloudHttp2SolrClient getCloudHttp2SolrClient(String zkHost) {
+return getCloudHttp2SolrClient(zkHost, null);
+ }
+
+ public static CloudHttp2SolrClient getCloudHttp2SolrClient(
+ String zkHost, Http2SolrClient.Builder builder) {
+return new CloudHttp2SolrClient.Builder(Collections.singletonList(zkHost),
Optional.empty())
+.withSolrClassLoader(getSolrResourceLoader())
+.withInternalClientBuilder(builder)
+.build();
+ }
+
+ private static SolrResourceLoader getSolrResourceLoader() {
+String dir = System.getProperty("solr.solr.home");
+if (StrUtils.isNullOrEmpty(dir)) {
+ dir = System.getProperty("solr.install.dir");
+}
+final SolrResourceLoader loader = new SolrResourceLoader(Paths.get(dir));
+NodeConfig.initModules(loader, null);
Review Comment:
Jarring to me as well; why are we reading solr.xml in SolrCLI?
--
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-17248: Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage [solr]
dsmiley commented on PR #2417: URL: https://github.com/apache/solr/pull/2417#issuecomment-2075257179 I am most concerned about the SolrClassLoader proliferation in a bunch of other classes. Can you please explain/justify this? -- 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-4587: integrate lucene-monitor into solr [solr]
kotman12 commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1578054464
##
solr/modules/monitor/src/java/org/apache/solr/monitor/update/MonitorUpdateProcessorFactory.java:
##
@@ -0,0 +1,56 @@
+/*
+ *
+ * * Licensed to the Apache Software Foundation (ASF) under one or more
+ * * contributor license agreements. See the NOTICE file distributed with
+ * * this work for additional information regarding copyright ownership.
+ * * The ASF licenses this file to You under the Apache License, Version 2.0
+ * * (the "License"); you may not use this file except in compliance with
+ * * the License. You may obtain a copy of the License at
+ * *
+ * * http://www.apache.org/licenses/LICENSE-2.0
+ * *
+ * * Unless required by applicable law or agreed to in writing, software
+ * * distributed under the License is distributed on an "AS IS" BASIS,
+ * * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * * See the License for the specific language governing permissions and
+ * * limitations under the License.
+ *
+ */
+
+package org.apache.solr.monitor.update;
+
+import org.apache.lucene.monitor.MonitorFields;
+import org.apache.lucene.monitor.Presearcher;
+import org.apache.solr.common.util.NamedList;
+import org.apache.solr.monitor.PresearcherFactory;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.update.processor.UpdateRequestProcessor;
+import org.apache.solr.update.processor.UpdateRequestProcessorFactory;
+
+public class MonitorUpdateProcessorFactory extends
UpdateRequestProcessorFactory {
+
+ private Presearcher presearcher = PresearcherFactory.build();
Review Comment:
With the latest change the Presearcher only gets initialized in the
`ReverseQueryParserPlugin` and I share that core-level-singleton by making
`MonitorUpdateProcessorFactory` a `SolrCoreAware` type. Not sure if there is a
better pattern for this? This would be admittedly nicer with some kind of DI
mechanism.
--
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] adding automountServiceAccountToken [solr-operator]
jojay commented on issue #701: URL: https://github.com/apache/solr-operator/issues/701#issuecomment-2075123054 BTW: This is the finding in Azure Defender: "Kubernetes clusters should disable automounting API credentials There are multiple ways to opt out of automounting API credentials for a service account. To opt out of automounting API credentials for a single pod, set automountServiceAccountToken: false in PodSpec.[...]" -- 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
[I] adding automountServiceAccountToken [solr-operator]
jojay opened a new issue, #701: URL: https://github.com/apache/solr-operator/issues/701 Hi, is there an option to set in kind: SolrCloud somehow `automountServiceAccountToken = false` ? This will solve a security recommendation in AKS. So in STS (below the SolrCloud installed with solr-operator 8.0.0 but enriched post install with mentioned attribute. The same I would like to accomplish for zookeeper too. I would like to avoid some post processing with kustomize or forking the helm charts by myself) you would finally have: Excerpt: ``` apiVersion: apps/v1 kind: StatefulSet metadata: annotations: solr.apache.org/zkConnectionString: test-platformdev-solrcloud-zookeeper-0.test-platformdev-solrcloud-zookeeper-headless.test-platformdev.svc.cluster.local:2181,test-platformdev-solrcloud-zookeeper-1.test-platformdev-solrcloud-zookeeper-headless.test-platformdev.svc.cluster.local:2181,test-platformdev-solrcloud-zookeeper-2.test-platformdev-solrcloud-zookeeper-headless.test-platformdev.svc.cluster.local:2181/test-platformdev creationTimestamp: "2024-04-12T12:36:20Z" generation: 3 labels: solr-cloud: test-platformdev technology: solr-cloud name: test-platformdev-solrcloud namespace: test-platformdev ownerReferences: - apiVersion: solr.apache.org/v1beta1 blockOwnerDeletion: true controller: true kind: SolrCloud name: test-platformdev uid: 9ef08181-2d5e-401a-904d-6c6cd8f6e87b resourceVersion: "666711970" uid: 8f9393c1-0692-40dd-816a-8292ce2e63db spec: persistentVolumeClaimRetentionPolicy: whenDeleted: Retain whenScaled: Retain podManagementPolicy: Parallel replicas: 2 revisionHistoryLimit: 10 selector: matchLabels: solr-cloud: test-platformdev technology: solr-cloud serviceName: test-platformdev-solrcloud-headless template: metadata: annotations: solr.apache.org/solrXmlMd5: 843652bc6b529b66f46bcdae6764ab4e creationTimestamp: null labels: solr-cloud: test-platformdev technology: solr-cloud spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: agentpool operator: In values: - agentpool **automountServiceAccountToken: false** containers: - env: - name: SOLR_JAVA_MEM ``` Thank you very much in advance! -- 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.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-16044) SlowRequest logging disabled if SolrCore logger set to ERROR
[
https://issues.apache.org/jira/browse/SOLR-16044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-16044:
---
Status: Resolved (was: Closed)
> SlowRequest logging disabled if SolrCore logger set to ERROR
>
>
> Key: SOLR-16044
> URL: https://issues.apache.org/jira/browse/SOLR-16044
> Project: Solr
> Issue Type: Bug
> Components: logging
> Environment: Solr 8.4
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 9.4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If someone sets ROOT logger to ERROR, then {{SolrCore}} class will also be
> set to ERROR, and even if {{SolrCore.SlowRequest}} level is set to INFO, no
> logs will be written to {{{}solr_slow_requests.log{}}}.
> Some debugging revealed that changing log level of {{SolrCore}} to WARN fixes
> it. This suggests that since {{SlowRequest}} is not a real class but just a
> logger name, it is still subject to the log level of {{SolrCore}}.
> I suppose that the same will be true for {{SolrCore.Request}} logging.
> One solution could be to create a real class for SlowRequest logging. Another
> solution could be to explicitly set {{SolrCore}} level in {{log4j2.xml}} so
> that it does not follow the ROOT level.
--
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-14607) LTR Query, timeAllowed parameter causes a timeout exception with no result
[
https://issues.apache.org/jira/browse/SOLR-14607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Benedetti resolved SOLR-14607.
-
Fix Version/s: main (10.0)
9.6
Resolution: Fixed
> LTR Query, timeAllowed parameter causes a timeout exception with no result
> --
>
> Key: SOLR-14607
> URL: https://issues.apache.org/jira/browse/SOLR-14607
> Project: Solr
> Issue Type: Improvement
> Components: contrib - LTR
>Affects Versions: 9.0
>Reporter: Shiming Li
>Priority: Minor
> Fix For: main (10.0), 9.6
>
> Attachments: SOLR-14607-poc.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When using the LTR, open timeAllowed parameter, LTR feature of query may call
> 'ExitableFilterAtomicReader.CheckAndThrow' timeout checks.
> If a timeout occurs at this point, the exception ExitingReaderException is
> thrown, Lead to null result.
> Exception information:
> {code:java}
> The request took too long to iterate over terms. Timeout: timeoutAt:
> 50321611131050 (System.nanoTime(): 50321639573838),
> TermsEnum=org.apache.lucene.codecs.blocktree.SegmentTermsEnum@62eaeeaa
> {code}
>
> Can hold this exception in the LTR, returning partial results rather than
> null.
> This exception occurs in two places:
> 1. 'LTRScoringQuery.CreateWeight' or 'LTRScoringQuery.createWeightsParallel'.
> Here is the loading stage, timeout directly end is acceptable.
> 2. 'ModelWeight.scorer'. This is a stage that evaluates each Doc and can
> catch the exception, returns the computed document.
>
--
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-14607) LTR Query, timeAllowed parameter causes a timeout exception with no result
[
https://issues.apache.org/jira/browse/SOLR-14607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840328#comment-17840328
]
Alessandro Benedetti commented on SOLR-14607:
-
This should be fixed in 9.6 thorugh this:
https://issues.apache.org/jira/browse/SOLR-17018
Closing, in case it's a different problem feel free to elaborate and re-open
> LTR Query, timeAllowed parameter causes a timeout exception with no result
> --
>
> Key: SOLR-14607
> URL: https://issues.apache.org/jira/browse/SOLR-14607
> Project: Solr
> Issue Type: Improvement
> Components: contrib - LTR
>Affects Versions: 9.0
>Reporter: Shiming Li
>Priority: Minor
> Attachments: SOLR-14607-poc.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When using the LTR, open timeAllowed parameter, LTR feature of query may call
> 'ExitableFilterAtomicReader.CheckAndThrow' timeout checks.
> If a timeout occurs at this point, the exception ExitingReaderException is
> thrown, Lead to null result.
> Exception information:
> {code:java}
> The request took too long to iterate over terms. Timeout: timeoutAt:
> 50321611131050 (System.nanoTime(): 50321639573838),
> TermsEnum=org.apache.lucene.codecs.blocktree.SegmentTermsEnum@62eaeeaa
> {code}
>
> Can hold this exception in the LTR, returning partial results rather than
> null.
> This exception occurs in two places:
> 1. 'LTRScoringQuery.CreateWeight' or 'LTRScoringQuery.createWeightsParallel'.
> Here is the loading stage, timeout directly end is acceptable.
> 2. 'ModelWeight.scorer'. This is a stage that evaluates each Doc and can
> catch the exception, returns the computed document.
>
--
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] [Comment Edited] (SOLR-14607) LTR Query, timeAllowed parameter causes a timeout exception with no result
[
https://issues.apache.org/jira/browse/SOLR-14607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840328#comment-17840328
]
Alessandro Benedetti edited comment on SOLR-14607 at 4/24/24 8:13 AM:
--
This should be fixed in 9.6 through this:
https://issues.apache.org/jira/browse/SOLR-17018
Closing, in case it's a different problem feel free to elaborate and re-open
was (Author: alessandro.benedetti):
This should be fixed in 9.6 thorugh this:
https://issues.apache.org/jira/browse/SOLR-17018
Closing, in case it's a different problem feel free to elaborate and re-open
> LTR Query, timeAllowed parameter causes a timeout exception with no result
> --
>
> Key: SOLR-14607
> URL: https://issues.apache.org/jira/browse/SOLR-14607
> Project: Solr
> Issue Type: Improvement
> Components: contrib - LTR
>Affects Versions: 9.0
>Reporter: Shiming Li
>Priority: Minor
> Fix For: main (10.0), 9.6
>
> Attachments: SOLR-14607-poc.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When using the LTR, open timeAllowed parameter, LTR feature of query may call
> 'ExitableFilterAtomicReader.CheckAndThrow' timeout checks.
> If a timeout occurs at this point, the exception ExitingReaderException is
> thrown, Lead to null result.
> Exception information:
> {code:java}
> The request took too long to iterate over terms. Timeout: timeoutAt:
> 50321611131050 (System.nanoTime(): 50321639573838),
> TermsEnum=org.apache.lucene.codecs.blocktree.SegmentTermsEnum@62eaeeaa
> {code}
>
> Can hold this exception in the LTR, returning partial results rather than
> null.
> This exception occurs in two places:
> 1. 'LTRScoringQuery.CreateWeight' or 'LTRScoringQuery.createWeightsParallel'.
> Here is the loading stage, timeout directly end is acceptable.
> 2. 'ModelWeight.scorer'. This is a stage that evaluates each Doc and can
> catch the exception, returns the computed document.
>
--
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
