Re: [PR] SOLR-16505: Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2 [solr]
iamsanjay commented on PR #2276: URL: https://github.com/apache/solr/pull/2276#issuecomment-2099713438 Thinking out loud! The new logic, however bit ugly it is because it gives freedom to manipulate the Http2SolrClient directly instead of creating it through Builder patter -- _anti-pattern_, to copy the listeners from older Http2SolrClient to the new Http2SolrClient is added only because of the custom timeouts configuration for replication logic. ### Is there any way to avoid recreating the Http2SolrClient? The default socketTimeout and connectionTimeout for UpdateShardHandler http client is 60 secs for both, and for IndexFetcher Recovery client It is 120 and 60 seconds respectively. Can we deprecate or basically remove the older way of setting these timeouts at replication Handler level and use the UpdateShardHandler config timeouts i.e. 60 seconds for both socket and connection? -- 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-17282) Update basic-authentication-plugin.adoc
[ https://issues.apache.org/jira/browse/SOLR-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] guoshipneg updated SOLR-17282: -- Description: As I was reading through this documentation, I noticed a problem with the encryption section, as follows: (Format: base64(sha256(sha256(salt+password)) base64(salt)), so I started to think that I have to use base64 to encrypt the whole content of the back of the encryption, but in fact it's not true, there is a ')' missing, it should be like this base64(sha256(sha256( salt+password))) base64(salt), so that the result of the separate encryption can be used. was: As I was reading through this documentation, I noticed a problem with the encryption section, as follows: (Format: base64(sha256(sha256(salt+password)) base64(salt)), so I started to think that I have to use base64 to encrypt the whole content of the back of the encryption, but in fact it's not true, there is a ')' missing, it should be like this base64(sha256(sha256( salt+password))) base64(salt), so that the result of the separate encryption can be used. Translated with DeepL.com (free version) > Update basic-authentication-plugin.adoc > --- > > Key: SOLR-17282 > URL: https://issues.apache.org/jira/browse/SOLR-17282 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: guoshipneg >Priority: Major > > As I was reading through this documentation, I noticed a problem with the > encryption section, as follows: > (Format: base64(sha256(sha256(salt+password)) base64(salt)), so I started to > think that I have to use base64 to encrypt the whole content of the back of > the encryption, but in fact it's not true, there is a ')' missing, it should > be like this base64(sha256(sha256( salt+password))) base64(salt), so that the > result of the separate encryption can be used. -- 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-17282) Update basic-authentication-plugin.adoc
[ https://issues.apache.org/jira/browse/SOLR-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] guoshipneg updated SOLR-17282: -- Description: As I was reading through this documentation, I noticed a problem with the encryption section, as follows: (Format: base64(sha256(sha256(salt+password)) base64(salt)), so I started to think that I have to use base64 to encrypt the whole content of the back of the encryption, but in fact it's not true, there is a ')' missing, it should be like this base64(sha256(sha256( salt+password))) base64(salt), so that the result of the separate encryption can be used. Translated with DeepL.com (free version) was: As I was reading through this documentation, I noticed a problem with the encryption section, as follows: (Format: base64(sha256(sha256(salt+password))) base64(salt)), so I started to think that I have to use base64 to encrypt the whole content of the back of the encryption, but in fact it's not true, there is a ')' missing, it should be like this base64(sha256(sha256( salt+password))) base64(salt), so that the result of the separate encryption can be used. Translated with DeepL.com (free version) > Update basic-authentication-plugin.adoc > --- > > Key: SOLR-17282 > URL: https://issues.apache.org/jira/browse/SOLR-17282 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: guoshipneg >Priority: Major > > As I was reading through this documentation, I noticed a problem with the > encryption section, as follows: > (Format: base64(sha256(sha256(salt+password)) base64(salt)), so I started to > think that I have to use base64 to encrypt the whole content of the back of > the encryption, but in fact it's not true, there is a ')' missing, it should > be like this base64(sha256(sha256( salt+password))) base64(salt), so that the > result of the separate encryption can be used. > Translated with DeepL.com (free version) -- 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] Update basic-authentication-plugin.adoc [solr]
gspgsp opened a new pull request, #2446: URL: https://github.com/apache/solr/pull/2446 https://issues.apache.org/jira/browse/SOLR-17282 # Description for the pwd encode format, there missed a ')', and this confused me , so i added this: (Format: base64(sha256(sha256(salt+password))) base64(salt)) # Solution i added this: (Format: base64(sha256(sha256(salt+password))) base64(salt)) # 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] [Updated] (SOLR-17282) Update basic-authentication-plugin.adoc
[ https://issues.apache.org/jira/browse/SOLR-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] guoshipneg updated SOLR-17282: -- Issue Type: Improvement (was: Bug) > Update basic-authentication-plugin.adoc > --- > > Key: SOLR-17282 > URL: https://issues.apache.org/jira/browse/SOLR-17282 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: guoshipneg >Priority: Major > > As I was reading through this documentation, I noticed a problem with the > encryption section, as follows: > (Format: base64(sha256(sha256(salt+password))) base64(salt)), so I started to > think that I have to use base64 to encrypt the whole content of the back of > the encryption, but in fact it's not true, there is a ')' missing, it should > be like this base64(sha256(sha256( salt+password))) base64(salt), so that the > result of the separate encryption can be used. > Translated with DeepL.com (free version) -- 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-17282) Update basic-authentication-plugin.adoc
[ https://issues.apache.org/jira/browse/SOLR-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] guoshipneg updated SOLR-17282: -- Issue Type: Bug (was: Wish) > Update basic-authentication-plugin.adoc > --- > > Key: SOLR-17282 > URL: https://issues.apache.org/jira/browse/SOLR-17282 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: guoshipneg >Priority: Major > > As I was reading through this documentation, I noticed a problem with the > encryption section, as follows: > (Format: base64(sha256(sha256(salt+password))) base64(salt)), so I started to > think that I have to use base64 to encrypt the whole content of the back of > the encryption, but in fact it's not true, there is a ')' missing, it should > be like this base64(sha256(sha256( salt+password))) base64(salt), so that the > result of the separate encryption can be used. > Translated with DeepL.com (free version) -- 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-17282) Update basic-authentication-plugin.adoc
guoshipneg created SOLR-17282: - Summary: Update basic-authentication-plugin.adoc Key: SOLR-17282 URL: https://issues.apache.org/jira/browse/SOLR-17282 Project: Solr Issue Type: Wish Security Level: Public (Default Security Level. Issues are Public) Reporter: guoshipneg As I was reading through this documentation, I noticed a problem with the encryption section, as follows: (Format: base64(sha256(sha256(salt+password))) base64(salt)), so I started to think that I have to use base64 to encrypt the whole content of the back of the encryption, but in fact it's not true, there is a ')' missing, it should be like this base64(sha256(sha256( salt+password))) base64(salt), so that the result of the separate encryption can be used. Translated with DeepL.com (free version) -- 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-17274) atomic update error when using json w/ multiple modifiers
[
https://issues.apache.org/jira/browse/SOLR-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844479#comment-17844479
]
Calvin Smith commented on SOLR-17274:
-
Sure, I'll make a PR and some tests.
> atomic update error when using json w/ multiple modifiers
> -
>
> Key: SOLR-17274
> URL: https://issues.apache.org/jira/browse/SOLR-17274
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6
> Environment: Observed first in 9.5.0 w/ OpenJDK 11, then reproduced
> this simple test case in 9.6.0.
>Reporter: Calvin Smith
>Priority: Major
>
> I ran into a problem doing a json atomic update that tries to both `add` and
> `remove` a value for a multivalued field in a single update. I saw it
> initially in an instance that runs 9.5.0, and reproduced a minimal example
> using Solr 9.6.0.
> {{The only fields defined in the schema are:}}
> {code:java}
> required="true" stored="true"/>
>
> {code}
> {{`id` is also present, so I'm supplying docs with
> just an `id` and a multivalued `name` field. The real setup is more complex,
> but this is a minimal test case to illustrate the problem.}}
> {{Starting with an empty index, I add the following doc to the index
> successfully:}}
> {code:java}
> {"id": "1", "name": ["John Doe", "Jane Doe"]}{code}
> {{And I can query it, seeing the expected result:}}
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":23,
> "params":{
> "q":"name:*"
> }
> },
> "response":{
> "numFound":1,
> "start":0,
> "numFoundExact":true,
> "docs":[{
> "id":"1",
> "name":["John Doe","Jane Doe"],
> "_version_":1797873599884820480
> }]
> }
> }{code}
> {{Next, I send an atomic update to modify the `name` field of that document
> by removing `Jane Doe` and adding `Janet Doe`:}}
> {code:java}
> {"id": "1", "name": {"add": "Janet Doe", "remove": "Jane Doe"}}{code}
> {{This atomic update that does both an `add` and a `remove` is something that
> used to work for us under Solr 6.6, but we just noticed that it fails in our
> production 9.5 instance and in 9.6, which I just downloaded to test against.}}
> {{The error in the solr.log indicates that Solr mistakenly interprets the
> `\{"add": "Janet Doe", "remove": "Jane Doe"}` as a nested document and then
> throws an exception because our schema doesn't have the `{_}root{_}` field
> that would be expected if we were using nested docs (which we don't use).}}
> {{Here's the full stack trace from `solr.log` (version 9.6.0):}}
> {noformat}
> 2024-05-01 17:49:02.479 ERROR (qtp2059461664-30-0.0.0.0-3) [c: s: r: x:atris
> t:0.0.0.0-3] o.a.s.h.RequestHandlerBase Client exception =>
> org.apache.solr.common.SolrException: Unable to index docs with children: the
> schema must include definitions for both a uniqueKey field and the '_root_'
> field, using the exact same fieldType
> at
> org.apache.solr.update.DocumentBuilder.unexpectedNestedDocException(DocumentBuilder.java:369)
> org.apache.solr.common.SolrException: Unable to index docs with children: the
> schema must include definitions for both a uniqueKey field and the '_root_'
> field, using the exact same fieldType
> at
> org.apache.solr.update.DocumentBuilder.unexpectedNestedDocException(DocumentBuilder.java:369)
> ~[?:?]
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:153)
> ~[?:?]
> at
> org.apache.solr.update.AddUpdateCommand.makeLuceneDocs(AddUpdateCommand.java:213)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.updateDocOrDocValues(DirectUpdateHandler2.java:1056)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:421)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:375)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:312)
> ~[?:?]
> at
> org.apache.solr.update.processor.RunUpdateProcessorFactory$RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76)
> ~[?:?]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:54)
> ~[?:?]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:270)
> ~[?:?]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:533)
> ~[?:?]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:358)
>
Re: [PR] SOLR-17150: Create MemQueryLimit implementation [solr]
github-actions[bot] commented on PR #2288: URL: https://github.com/apache/solr/pull/2288#issuecomment-2099495596 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-17160: Time based tracking of core admin requests with Caffeine cache [solr]
github-actions[bot] commented on PR #2304: URL: https://github.com/apache/solr/pull/2304#issuecomment-2099495565 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
[jira] [Updated] (SOLR-17275) Major performance regression of CloudSolrClient in Solr 9.6.0 when using aliases
[
https://issues.apache.org/jira/browse/SOLR-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-17275:
Fix Version/s: 9.6.1
Ouch! The fix should go in 9.6.1.
Maybe even aliases could be checked first (why not).
> Major performance regression of CloudSolrClient in Solr 9.6.0 when using
> aliases
>
>
> Key: SOLR-17275
> URL: https://issues.apache.org/jira/browse/SOLR-17275
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
> Environment: SolrJ 9.6.0, Ubuntu 22.04, Java 17
>Reporter: Rafał Harabień
>Priority: Major
> Fix For: 9.6.1
>
> Attachments: image-2024-05-06-17-23-42-236.png
>
>
> I observe worse performance of CloudSolrClient after upgrading from SolrJ
> 9.5.0 to 9.6.0, especially on p99.
> p99 jumped from ~25 ms to ~400 ms
> p90 jumped from ~9.9 ms to ~22 ms
> p75 jumped from ~7 ms to ~11 ms
> p50 jumped from ~4.5 ms to ~7.5 ms
> Screenshot from Grafana (at ~14:30 was deployed the new version):
> !image-2024-05-06-17-23-42-236.png!
> I've got a thread-dump and I can see many threads waiting in
> [ZkStateReader.forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]:
> {noformat}
> Thread info: "suggest-solrThreadPool-thread-52" prio=5 Id=600 BLOCKED on
> org.apache.solr.common.cloud.ZkStateReader@62e6bc3d owned by
> "suggest-solrThreadPool-thread-34" Id=582
> at
> app//org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:506)
> - blocked on org.apache.solr.common.cloud.ZkStateReader@62e6bc3d
> at
> app//org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.getState(ZkClientClusterStateProvider.java:155)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.resolveAliases(CloudSolrClient.java:1207)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:892)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:820)
> at
> app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:255)
> at
> app//org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> ...
> Number of locked synchronizers = 1
> - java.util.concurrent.ThreadPoolExecutor$Worker@1beb7ed3
> {noformat}
> At the same time qTime from Solr hasn't changed so I'm pretty sure it's a
> client regression.
> I've tried reproducing it locally and I can see
> [forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]
> function being called for every request in my application. I can see that
> [this|https://github.com/apache/solr/commit/8cf552aa3642be473c6a08ce44feceb9cbe396d7]
> commit
> changed the logic in ZkClientClusterStateProvider.getState so the mentioned
> function gets called if clusterState.getCollectionRef [returns
> null|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/client/solrj/impl/ZkClientClusterStateProvider.java#L151].
> In 9.5.0 it wasn't the case (forceUpdateCollection was not called in this
> place). I can see in the debugger that getCollectionRef only supports
> collections and not aliases (collectionStates map contains only collections).
> In my application all collections are referenced using aliases so I guess
> that's why I can see the regression in Solr response time.
> I am not familiar with the code enough to prepare a PR but I hope this
> insight will be enough to fix this issue.
--
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-17274) atomic update error when using json w/ multiple modifiers
[
https://issues.apache.org/jira/browse/SOLR-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1787#comment-1787
]
David Smiley commented on SOLR-17274:
-
Ah right, if the schema isn't child doc enabled, then isChildDoc can return
false. I like it! Deja-vu... probably an existing idea written somewhere. If
you can submit a PR, that'd be great. Call {{IndexSchema.isUsableForChildDocs()
}}to see if we can return early.
> atomic update error when using json w/ multiple modifiers
> -
>
> Key: SOLR-17274
> URL: https://issues.apache.org/jira/browse/SOLR-17274
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6
> Environment: Observed first in 9.5.0 w/ OpenJDK 11, then reproduced
> this simple test case in 9.6.0.
>Reporter: Calvin Smith
>Priority: Major
>
> I ran into a problem doing a json atomic update that tries to both `add` and
> `remove` a value for a multivalued field in a single update. I saw it
> initially in an instance that runs 9.5.0, and reproduced a minimal example
> using Solr 9.6.0.
> {{The only fields defined in the schema are:}}
> {code:java}
> required="true" stored="true"/>
>
> {code}
> {{`id` is also present, so I'm supplying docs with
> just an `id` and a multivalued `name` field. The real setup is more complex,
> but this is a minimal test case to illustrate the problem.}}
> {{Starting with an empty index, I add the following doc to the index
> successfully:}}
> {code:java}
> {"id": "1", "name": ["John Doe", "Jane Doe"]}{code}
> {{And I can query it, seeing the expected result:}}
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":23,
> "params":{
> "q":"name:*"
> }
> },
> "response":{
> "numFound":1,
> "start":0,
> "numFoundExact":true,
> "docs":[{
> "id":"1",
> "name":["John Doe","Jane Doe"],
> "_version_":1797873599884820480
> }]
> }
> }{code}
> {{Next, I send an atomic update to modify the `name` field of that document
> by removing `Jane Doe` and adding `Janet Doe`:}}
> {code:java}
> {"id": "1", "name": {"add": "Janet Doe", "remove": "Jane Doe"}}{code}
> {{This atomic update that does both an `add` and a `remove` is something that
> used to work for us under Solr 6.6, but we just noticed that it fails in our
> production 9.5 instance and in 9.6, which I just downloaded to test against.}}
> {{The error in the solr.log indicates that Solr mistakenly interprets the
> `\{"add": "Janet Doe", "remove": "Jane Doe"}` as a nested document and then
> throws an exception because our schema doesn't have the `{_}root{_}` field
> that would be expected if we were using nested docs (which we don't use).}}
> {{Here's the full stack trace from `solr.log` (version 9.6.0):}}
> {noformat}
> 2024-05-01 17:49:02.479 ERROR (qtp2059461664-30-0.0.0.0-3) [c: s: r: x:atris
> t:0.0.0.0-3] o.a.s.h.RequestHandlerBase Client exception =>
> org.apache.solr.common.SolrException: Unable to index docs with children: the
> schema must include definitions for both a uniqueKey field and the '_root_'
> field, using the exact same fieldType
> at
> org.apache.solr.update.DocumentBuilder.unexpectedNestedDocException(DocumentBuilder.java:369)
> org.apache.solr.common.SolrException: Unable to index docs with children: the
> schema must include definitions for both a uniqueKey field and the '_root_'
> field, using the exact same fieldType
> at
> org.apache.solr.update.DocumentBuilder.unexpectedNestedDocException(DocumentBuilder.java:369)
> ~[?:?]
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:153)
> ~[?:?]
> at
> org.apache.solr.update.AddUpdateCommand.makeLuceneDocs(AddUpdateCommand.java:213)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.updateDocOrDocValues(DirectUpdateHandler2.java:1056)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:421)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:375)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:312)
> ~[?:?]
> at
> org.apache.solr.update.processor.RunUpdateProcessorFactory$RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76)
> ~[?:?]
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:54)
> ~[?:?]
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:270)
> ~[?:?]
> at
>
[jira] [Commented] (SOLR-17274) atomic update error when using json w/ multiple modifiers
[
https://issues.apache.org/jira/browse/SOLR-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1780#comment-1780
]
Calvin Smith commented on SOLR-17274:
-
It would be nice if we didn't have to switch to a non-Json format. We're a
Python backend that uses JSON everywhere and XML nowhere currently, and last
time I checked, CBOR didn't support something that we use via JSON, so the path
of least resistance for us would be to work around the JSON limitations somehow.
In terms of possible changes though, could Solr take into account whether a
`_root_` field is defined for the index/schema, and if not, then don't consider
it a child doc? Or alternately, maybe a configuration option to enable or
disable nested documents that don't provide a `uniqueKey` field, and it could
behave differently in that case (e.g., old logic if nested docs without a
`uniqueKey` are not enabled and new logic or something like it if so). For
folks like us that don't ever use nested docs (with or without a `uniqueKey`),
the old logic worked perfectly.
> atomic update error when using json w/ multiple modifiers
> -
>
> Key: SOLR-17274
> URL: https://issues.apache.org/jira/browse/SOLR-17274
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6
> Environment: Observed first in 9.5.0 w/ OpenJDK 11, then reproduced
> this simple test case in 9.6.0.
>Reporter: Calvin Smith
>Priority: Major
>
> I ran into a problem doing a json atomic update that tries to both `add` and
> `remove` a value for a multivalued field in a single update. I saw it
> initially in an instance that runs 9.5.0, and reproduced a minimal example
> using Solr 9.6.0.
> {{The only fields defined in the schema are:}}
> {code:java}
> required="true" stored="true"/>
>
> {code}
> {{`id` is also present, so I'm supplying docs with
> just an `id` and a multivalued `name` field. The real setup is more complex,
> but this is a minimal test case to illustrate the problem.}}
> {{Starting with an empty index, I add the following doc to the index
> successfully:}}
> {code:java}
> {"id": "1", "name": ["John Doe", "Jane Doe"]}{code}
> {{And I can query it, seeing the expected result:}}
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":23,
> "params":{
> "q":"name:*"
> }
> },
> "response":{
> "numFound":1,
> "start":0,
> "numFoundExact":true,
> "docs":[{
> "id":"1",
> "name":["John Doe","Jane Doe"],
> "_version_":1797873599884820480
> }]
> }
> }{code}
> {{Next, I send an atomic update to modify the `name` field of that document
> by removing `Jane Doe` and adding `Janet Doe`:}}
> {code:java}
> {"id": "1", "name": {"add": "Janet Doe", "remove": "Jane Doe"}}{code}
> {{This atomic update that does both an `add` and a `remove` is something that
> used to work for us under Solr 6.6, but we just noticed that it fails in our
> production 9.5 instance and in 9.6, which I just downloaded to test against.}}
> {{The error in the solr.log indicates that Solr mistakenly interprets the
> `\{"add": "Janet Doe", "remove": "Jane Doe"}` as a nested document and then
> throws an exception because our schema doesn't have the `{_}root{_}` field
> that would be expected if we were using nested docs (which we don't use).}}
> {{Here's the full stack trace from `solr.log` (version 9.6.0):}}
> {noformat}
> 2024-05-01 17:49:02.479 ERROR (qtp2059461664-30-0.0.0.0-3) [c: s: r: x:atris
> t:0.0.0.0-3] o.a.s.h.RequestHandlerBase Client exception =>
> org.apache.solr.common.SolrException: Unable to index docs with children: the
> schema must include definitions for both a uniqueKey field and the '_root_'
> field, using the exact same fieldType
> at
> org.apache.solr.update.DocumentBuilder.unexpectedNestedDocException(DocumentBuilder.java:369)
> org.apache.solr.common.SolrException: Unable to index docs with children: the
> schema must include definitions for both a uniqueKey field and the '_root_'
> field, using the exact same fieldType
> at
> org.apache.solr.update.DocumentBuilder.unexpectedNestedDocException(DocumentBuilder.java:369)
> ~[?:?]
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:153)
> ~[?:?]
> at
> org.apache.solr.update.AddUpdateCommand.makeLuceneDocs(AddUpdateCommand.java:213)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.updateDocOrDocValues(DirectUpdateHandler2.java:1056)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:421)
> ~[?:?]
> at
>
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_r1593008731
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java:
##
@@ -115,6 +115,11 @@ public class Http2SolrClient extends HttpSolrClientBase {
private SSLConfig sslConfig;
private List listenerFactory = new ArrayList<>();
+
+ public List getListenerFactory() {
Review Comment:
Minor, but this getter is very misplaced. It shouldn't be placed amidst the
fields.
##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/Http2SolrClientTest.java:
##
@@ -587,5 +587,27 @@ public void testBuilder() {
}
}
+ @Test
+ public void testIdleTimeoutWithHttpClient() {
Review Comment:
nice!
--
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_r1592994488
##
solr/core/src/test/org/apache/solr/handler/TestUserManagedReplicationWithAuth.java:
##
@@ -0,0 +1,267 @@
+/*
+ * 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.handler;
+
+import static org.apache.solr.common.params.CommonParams.JAVABIN;
+import static org.apache.solr.handler.ReplicationHandler.CMD_DISABLE_POLL;
+import static org.apache.solr.handler.ReplicationHandler.CMD_FETCH_INDEX;
+import static org.apache.solr.handler.ReplicationHandler.COMMAND;
+import static
org.apache.solr.handler.ReplicationTestHelper.createAndStartJetty;
+
+import java.io.IOException;
+import java.nio.charset.StandardCharsets;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.SolrTestCaseJ4.SuppressSSL;
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.client.solrj.SolrQuery;
+import org.apache.solr.client.solrj.SolrRequest;
+import org.apache.solr.client.solrj.SolrResponse;
+import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.request.HealthCheckRequest;
+import org.apache.solr.client.solrj.request.QueryRequest;
+import org.apache.solr.client.solrj.request.UpdateRequest;
+import org.apache.solr.client.solrj.response.QueryResponse;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.params.CommonParams;
+import org.apache.solr.common.params.ModifiableSolrParams;
+import org.apache.solr.embedded.JettySolrRunner;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+
+@SuppressSSL
+public class TestUserManagedReplicationWithAuth extends SolrTestCaseJ4 {
+ JettySolrRunner leaderJetty, followerJetty, followerJettyWithAuth;
+ SolrClient leaderClient, followerClient, followerClientWithAuth;
+ ReplicationTestHelper.SolrInstance leader = null, follower = null,
followerWithAuth = null;
+
+ private static String user = "solr";
+ private static String pass = "SolrRocks";
+ private static String securityJson =
+ "{\n"
+ + "\"authentication\":{ \n"
+ + " \"blockUnknown\": true, \n"
+ + " \"class\":\"solr.BasicAuthPlugin\",\n"
+ + "
\"credentials\":{\"solr\":\"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=\"}, \n"
+ + " \"realm\":\"My Solr users\", \n"
+ + " \"forwardCredentials\": false \n"
+ + "},\n"
+ + "\"authorization\":{\n"
+ + " \"class\":\"solr.RuleBasedAuthorizationPlugin\",\n"
+ + " \"permissions\":[{\"name\":\"security-edit\",\n"
+ + " \"role\":\"admin\"}],\n"
+ + " \"user-role\":{\"solr\":\"admin\"}\n"
+ + "}}";
+
+ @Override
+ @Before
+ public void setUp() throws Exception {
+super.setUp();
+systemSetPropertySolrDisableUrlAllowList("true");
+// leader with Basic auth enabled via security.json
+leader =
+new ReplicationTestHelper.SolrInstance(
+createTempDir("solr-instance").toFile(), "leader", null);
+leader.setUp();
+// Configuring basic auth for Leader
+Path solrLeaderHome = Path.of(leader.getHomeDir());
+Files.write(
+solrLeaderHome.resolve("security.json"),
securityJson.getBytes(StandardCharsets.UTF_8));
+leaderJetty = ReplicationTestHelper.createAndStartJetty(leader);
+leaderClient =
+ReplicationTestHelper.createNewSolrClient(
+buildUrl(leaderJetty.getLocalPort()), DEFAULT_TEST_CORENAME);
+
+// follower with no basic auth credentials for leader configured.
+follower =
+new ReplicationTestHelper.SolrInstance(
+createTempDir("solr-instance").toFile(), "follower",
leaderJetty.getLocalPort());
+follower.setUp();
+followerJetty = createAndStartJetty(follower);
+followerClient =
+ReplicationTestHelper.createNewSolrClient(
+buildUrl(followerJetty.getLocalPort()), DEFAULT_TEST_CORENAME);
+
+// follower with basic auth credentials for leader configured in
solrconfig.xml.
+followerWithAuth =
+
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_r1592989945
##
solr/core/src/test/org/apache/solr/handler/TestUserManagedReplicationWithAuth.java:
##
@@ -0,0 +1,267 @@
+/*
+ * 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.handler;
+
+import static org.apache.solr.common.params.CommonParams.JAVABIN;
+import static org.apache.solr.handler.ReplicationHandler.CMD_DISABLE_POLL;
+import static org.apache.solr.handler.ReplicationHandler.CMD_FETCH_INDEX;
+import static org.apache.solr.handler.ReplicationHandler.COMMAND;
+import static
org.apache.solr.handler.ReplicationTestHelper.createAndStartJetty;
+
+import java.io.IOException;
+import java.nio.charset.StandardCharsets;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.SolrTestCaseJ4.SuppressSSL;
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.client.solrj.SolrQuery;
+import org.apache.solr.client.solrj.SolrRequest;
+import org.apache.solr.client.solrj.SolrResponse;
+import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.request.HealthCheckRequest;
+import org.apache.solr.client.solrj.request.QueryRequest;
+import org.apache.solr.client.solrj.request.UpdateRequest;
+import org.apache.solr.client.solrj.response.QueryResponse;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.params.CommonParams;
+import org.apache.solr.common.params.ModifiableSolrParams;
+import org.apache.solr.embedded.JettySolrRunner;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+
+@SuppressSSL
+public class TestUserManagedReplicationWithAuth extends SolrTestCaseJ4 {
+ JettySolrRunner leaderJetty, followerJetty, followerJettyWithAuth;
+ SolrClient leaderClient, followerClient, followerClientWithAuth;
+ ReplicationTestHelper.SolrInstance leader = null, follower = null,
followerWithAuth = null;
+
+ private static String user = "solr";
+ private static String pass = "SolrRocks";
+ private static String securityJson =
+ "{\n"
+ + "\"authentication\":{ \n"
+ + " \"blockUnknown\": true, \n"
+ + " \"class\":\"solr.BasicAuthPlugin\",\n"
+ + "
\"credentials\":{\"solr\":\"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=\"}, \n"
+ + " \"realm\":\"My Solr users\", \n"
+ + " \"forwardCredentials\": false \n"
+ + "},\n"
+ + "\"authorization\":{\n"
+ + " \"class\":\"solr.RuleBasedAuthorizationPlugin\",\n"
+ + " \"permissions\":[{\"name\":\"security-edit\",\n"
+ + " \"role\":\"admin\"}],\n"
+ + " \"user-role\":{\"solr\":\"admin\"}\n"
+ + "}}";
+
+ @Override
+ @Before
+ public void setUp() throws Exception {
+super.setUp();
+systemSetPropertySolrDisableUrlAllowList("true");
+// leader with Basic auth enabled via security.json
+leader =
+new ReplicationTestHelper.SolrInstance(
+createTempDir("solr-instance").toFile(), "leader", null);
+leader.setUp();
+// Configuring basic auth for Leader
+Path solrLeaderHome = Path.of(leader.getHomeDir());
+Files.write(
+solrLeaderHome.resolve("security.json"),
securityJson.getBytes(StandardCharsets.UTF_8));
+leaderJetty = ReplicationTestHelper.createAndStartJetty(leader);
+leaderClient =
+ReplicationTestHelper.createNewSolrClient(
+buildUrl(leaderJetty.getLocalPort()), DEFAULT_TEST_CORENAME);
+
+// follower with no basic auth credentials for leader configured.
+follower =
+new ReplicationTestHelper.SolrInstance(
+createTempDir("solr-instance").toFile(), "follower",
leaderJetty.getLocalPort());
+follower.setUp();
+followerJetty = createAndStartJetty(follower);
+followerClient =
+ReplicationTestHelper.createNewSolrClient(
+buildUrl(followerJetty.getLocalPort()), DEFAULT_TEST_CORENAME);
+
+// follower with basic auth credentials for leader configured in
solrconfig.xml.
+followerWithAuth =
+
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_r1592980298
##
solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java:
##
@@ -133,16 +135,25 @@ public UpdateShardHandler(UpdateShardHandlerConfig cfg) {
DistributedUpdateProcessor.DISTRIB_FROM,
DistributingUpdateProcessorFactory.DISTRIB_UPDATE_PARAM);
Http2SolrClient.Builder updateOnlyClientBuilder = new
Http2SolrClient.Builder();
+Http2SolrClient.Builder recoveryOnlyClientBuilder = new
Http2SolrClient.Builder();
Review Comment:
@markrmiller do you recall why there are separate clients for "updateOnly"
vs "recoveryOnly"?
--
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-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
[
https://issues.apache.org/jira/browse/SOLR-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844424#comment-17844424
]
Michael Gibney commented on SOLR-17280:
---
If the main question on this issue is about why SolrRangeQuery inserts itself
in the cache, then that's more of an "under-the-hood" question, arguably
orthogonal to the recursive update IllegalStateException, which I really do
think is same issue as SOLR-16707, even if the description on this issue is
more fully fleshed out.
I don't think we can practically require individual queries to know whether
they might need to set themselves to async=true. Also, above mentions [PR
1480|https://github.com/apache/solr/pull/1480], which fixes the test, but not
the user-facing behavior; but there's also [PR
1481|https://github.com/apache/solr/pull/1481], which fixes both, by detecting
recursive invocation (when async==false) at runtime and falling back to
get-then-put only when it's actually necessary in practice.
Apologies for letting that PR (1481) languish so long. I should update to
respond to David's review suggestions and just merge it, I think it's the right
thing to do.
That said, I am in favor of deprecating {{async=false}}. PR 1481 really does
fix this though (incl. for users -- all configurations), which makes me a bit
ambivalent on whether to push for such deprecation, because I believe there is
one case where {{async=false}} is potentially desirable: in cases of very high
cache turnover with values that are computed very fast, at which point the
overhead of async bookkeeping can become non-negligible wrt the cost of cache
consultation overall. None of the default solr caches actually fit this
description though, afaik, and I am basically already swayed by the argument
that keeping {{async=false}} around for third-party use cases that _do_ fit
this description is not worth the extra complexity. (Notably, if somebody has
such a use case, directly using Caffeine or writing a custom SolrCache wrapper
around Caffeine would be pretty straightforward).
> SolrRangeQuery can trigger "IllegalStateException: Recursive update" in
> CaffeineCache / ConcurrentHashMap
> -
>
> Key: SOLR-17280
> URL: https://issues.apache.org/jira/browse/SOLR-17280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Sample stacktrace...
> {noformat}
> 2> => java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> 2> java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> ~[?:?]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
> ~[main/:?]
> 2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
> ~[main/:?]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
[jira] [Commented] (SOLR-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
[
https://issues.apache.org/jira/browse/SOLR-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844415#comment-17844415
]
Mike Drob commented on SOLR-17280:
--
As far as the cache insertion, that dates all the way back to the [introduction
of
SolrRangeQuery|https://github.com/apache/solr/commit/996a3fb117f8ee275ac16cbc789eb65eeb1898ed],
so you might have to ask [~yonik] about what is actually going on.
IIRC, when I committed this I did a bunch of manual cache inspection so I think
it gives the right results, but it's also very possible that the tests are
missing an edge case to verify correctness.
The comment about the "naked put" relates to the cache check earlier, since we
know we got a null (lines 440 + 447), so we don't need a
putIfAbsent/computeIfAbsent, and can go straight to put.
> SolrRangeQuery can trigger "IllegalStateException: Recursive update" in
> CaffeineCache / ConcurrentHashMap
> -
>
> Key: SOLR-17280
> URL: https://issues.apache.org/jira/browse/SOLR-17280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Sample stacktrace...
> {noformat}
> 2> => java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> 2> java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> ~[?:?]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
> ~[main/:?]
> 2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
> ~[main/:?]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:154)
> ~[main/:?]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:141) ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1387)
> ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.lambda$getAndCacheDocSet$1(SolrIndexSearcher.java:991)
> ~[main/:?]
> 2>at
> org.apache.solr.search.CaffeineCache.lambda$computeIfAbsent$1(CaffeineCache.java:258)
> ~[main/:?]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.lambda$statsAware$2(LocalCache.java:167)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$14(BoundedLocalCache.java:2688)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2686)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2669)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
>
[jira] [Commented] (SOLR-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
[
https://issues.apache.org/jira/browse/SOLR-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844414#comment-17844414
]
Mike Drob commented on SOLR-17280:
--
Yea, I hear what you're saying.
I suspect that what we need to do is either 1) Make all caches async and remove
the async=false option, or 2) make queries with sub-queries always set
themselves as async.
I didn't do (1) because I was thinking that we needed to give the feature time
to bake (which it has had plenty of time to do so) and if somebody is running
non-composite queries they can opt into the old system. I was worried about
cache usage changing or something else unexpected happening. But maybe it's
time for that now.
I'm not sure if (2) is possible on a per query basis or not. It's been a while
since I looked at that code. Maybe [~magibney] has additional insight.
> SolrRangeQuery can trigger "IllegalStateException: Recursive update" in
> CaffeineCache / ConcurrentHashMap
> -
>
> Key: SOLR-17280
> URL: https://issues.apache.org/jira/browse/SOLR-17280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Sample stacktrace...
> {noformat}
> 2> => java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> 2> java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> ~[?:?]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
> ~[main/:?]
> 2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
> ~[main/:?]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:154)
> ~[main/:?]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:141) ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1387)
> ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.lambda$getAndCacheDocSet$1(SolrIndexSearcher.java:991)
> ~[main/:?]
> 2>at
> org.apache.solr.search.CaffeineCache.lambda$computeIfAbsent$1(CaffeineCache.java:258)
> ~[main/:?]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.lambda$statsAware$2(LocalCache.java:167)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$14(BoundedLocalCache.java:2688)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2686)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2669)
>
[jira] [Commented] (SOLR-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
[
https://issues.apache.org/jira/browse/SOLR-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844413#comment-17844413
]
Chris M. Hostetter commented on SOLR-17280:
---
My main question would be: WTF does SolrRangeQuery explicitly inject itself in
the cache?!?!?!
(Is it even putting the *_correct_* answer in the cache? ... or just a part of
the answer for single segment answer that it then replaces on the next segment,
etc...)
> SolrRangeQuery can trigger "IllegalStateException: Recursive update" in
> CaffeineCache / ConcurrentHashMap
> -
>
> Key: SOLR-17280
> URL: https://issues.apache.org/jira/browse/SOLR-17280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Sample stacktrace...
> {noformat}
> 2> => java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> 2> java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> ~[?:?]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
> ~[main/:?]
> 2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
> ~[main/:?]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:154)
> ~[main/:?]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:141) ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1387)
> ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.lambda$getAndCacheDocSet$1(SolrIndexSearcher.java:991)
> ~[main/:?]
> 2>at
> org.apache.solr.search.CaffeineCache.lambda$computeIfAbsent$1(CaffeineCache.java:258)
> ~[main/:?]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.lambda$statsAware$2(LocalCache.java:167)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$14(BoundedLocalCache.java:2688)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2686)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2669)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:112)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.LocalManualCache.get(LocalManualCache.java:62)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> org.apache.solr.search.CaffeineCache.computeIfAbsent(CaffeineCache.java:253)
> ~[main/:?]
> 2>at
[jira] [Commented] (SOLR-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
[
https://issues.apache.org/jira/browse/SOLR-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844412#comment-17844412
]
Chris M. Hostetter commented on SOLR-17280:
---
Seems alluded to – in particular the way PR 1480 seems to suggest making a
config change to prevent the test from failing.
But i don't know if i would call them the same issue?
I also don't know that anything about the summary/description of SOLR-16707 (or
the change in PR 1480) is really going to stand out, or help, an arbitrary solr
user who runs into sporadic problems if/when they use range queries in their
solr deployment.
(At least here there is a stack trace they can say "That look like what i see
in my logs!")
> SolrRangeQuery can trigger "IllegalStateException: Recursive update" in
> CaffeineCache / ConcurrentHashMap
> -
>
> Key: SOLR-17280
> URL: https://issues.apache.org/jira/browse/SOLR-17280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Sample stacktrace...
> {noformat}
> 2> => java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> 2> java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> ~[?:?]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
> ~[main/:?]
> 2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
> ~[main/:?]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:154)
> ~[main/:?]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:141) ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1387)
> ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.lambda$getAndCacheDocSet$1(SolrIndexSearcher.java:991)
> ~[main/:?]
> 2>at
> org.apache.solr.search.CaffeineCache.lambda$computeIfAbsent$1(CaffeineCache.java:258)
> ~[main/:?]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.lambda$statsAware$2(LocalCache.java:167)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$14(BoundedLocalCache.java:2688)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2686)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2669)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:112)
>
[jira] [Commented] (SOLR-17279) consolidate security.json constants in test code
[ https://issues.apache.org/jira/browse/SOLR-17279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844410#comment-17844410 ] Rudi Seitz commented on SOLR-17279: --- PR: https://github.com/apache/solr/pull/2445 > consolidate security.json constants in test code > > > Key: SOLR-17279 > URL: https://issues.apache.org/jira/browse/SOLR-17279 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Rudi Seitz >Priority: Trivial > Time Spent: 20m > Remaining Estimate: 0h > > Various unit tests declare a SECURITY_JSON constant. Maybe of these constants > are identical (likely introduced via copy/paste from other tests, resulting > in code duplication). This ticket is to consolidate the various SECURITY_JSON > constants across the tests in a central place. > This point was raised during discussion of the fix for SOLR-12813. See > https://github.com/apache/solr/pull/2404#discussion_r1568012056 > In that discussion, it was agreed to address SECURITY_JSON consolidation in a > separate ticket -- this is that ticket. > Tagging [~epugh] -- 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-17279: consolidate security.json constants in tests [solr]
rseitz commented on PR #2445: URL: https://github.com/apache/solr/pull/2445#issuecomment-2098977485 Tagging @epugh -- 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-17279: consolidate security.json constants in tests [solr]
rseitz opened a new pull request, #2445: URL: https://github.com/apache/solr/pull/2445 https://issues.apache.org/jira/browse/SOLR-17279 # Description The PR creates a SecurityJson utility class that holds a standard "security.json" configuration for use by tests that enable security. Various tests were declaring the same copy/pasted SECURITY_JSON constant, resulting in code duplication; this PR updates those tests to use the new SecurityJson.SIMPLE constant. This is a refactoring PR that only affects test code and does not change any test logic. # Solution N/A # Tests No new tests added; got a successful `./gradlew check` # 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`. - [ ] 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-10654: Introduce output of Prometheus metrics for Solr Core registry [solr]
mlbiscoc commented on PR #2405: URL: https://github.com/apache/solr/pull/2405#issuecomment-2098969932 > ``` > io.prometheus:prometheus-metrics-config:1.1.0 (1 constraints: 3e164ed8) > io.prometheus:prometheus-metrics-exposition-formats:1.1.0 (1 constraints: 0405f335) > io.prometheus:prometheus-metrics-model:1.1.0 (2 constraints: 411b133b) > io.prometheus:prometheus-metrics-shaded-protobuf:1.1.0 (1 constraints: > ``` > > No, there are 4 dependencies. Only the last one concerns me. Why is protobuf needed at all? Can it be excluded? Can any of the others be excluded as well, while you're at it? Ah ok you were correct. I went ahead and removed the transitive dependencies `prometheus-metrics-shaded-protobuf` and `prometheus-metrics-config` so there should now only be 2 -- 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-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
[
https://issues.apache.org/jira/browse/SOLR-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844407#comment-17844407
]
Mike Drob commented on SOLR-17280:
--
Is this the same as SOLR-16707
> SolrRangeQuery can trigger "IllegalStateException: Recursive update" in
> CaffeineCache / ConcurrentHashMap
> -
>
> Key: SOLR-17280
> URL: https://issues.apache.org/jira/browse/SOLR-17280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Sample stacktrace...
> {noformat}
> 2> => java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> 2> java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> ~[?:?]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
> ~[main/:?]
> 2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
> ~[main/:?]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:154)
> ~[main/:?]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:141) ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1387)
> ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.lambda$getAndCacheDocSet$1(SolrIndexSearcher.java:991)
> ~[main/:?]
> 2>at
> org.apache.solr.search.CaffeineCache.lambda$computeIfAbsent$1(CaffeineCache.java:258)
> ~[main/:?]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.lambda$statsAware$2(LocalCache.java:167)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$14(BoundedLocalCache.java:2688)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2686)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2669)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:112)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.LocalManualCache.get(LocalManualCache.java:62)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> org.apache.solr.search.CaffeineCache.computeIfAbsent(CaffeineCache.java:253)
> ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:991)
> ~[main/:?]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:946)
> ~[main/:?]
> 2>at
>
[jira] [Commented] (SOLR-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
[
https://issues.apache.org/jira/browse/SOLR-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844401#comment-17844401
]
Chris M. Hostetter commented on SOLR-17280:
---
This can sometimes be reproduced by some of the sporadic jenkins failures that
we've seen from {{TestFiltering.testRandomFiltering}} over the past 3 years ...
{noformat}
hossman@slate:~/lucene/solr [j11] [main] $ git rev-parse HEAD
d5b82412d8729a6bfa8056e7000a5a7be0b9b86e
hossman@slate:~/lucene/solr [j11] [main] $ ./gradlew clean test --tests
TestFiltering -Dtests.seed=8B449AF7C2324BE4 -Dtests.multiplier=3
-Dtests.locale=fr-BE -Dtests.timezone=Europe/Sarajevo -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
...{noformat}
The root of the problem seems to be this bit of {{SolrRangeQuery}} ...
{noformat}
if (doCheck) {
answer = createDocSet(solrSearcher, count);
// This can be a naked put because the cache usually gets checked in
SolrIndexSearcher
solrSearcher.getFilterCache().put(SolrRangeQuery.this, answer);
return segStates[context.ord] = new SegState(new
SegmentDocIdSet(answer, context));
}
{noformat}
...for some reason the query is trying to inject itself directly into the
cache, which can obviously cause a recursion problem when the query is being
executed as part of a {{SimpleFacets.getFacetQueryCount ->
SolrIndexSearcher.getAndCacheDocSet -> CaffeineCache.computeIfAbsent}} call
stack
---
/ping [~mdrob] & [~magibney] as they are the last people to touch this chunk of
code.
mdrob: in particular i note that you added the comment about the "naked put" as
part of SOLR-1, which was committed almost exactly when
{{TestFiltering.testRandomFiltering}} started failing at a a very predictable
rate...
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering
> SolrRangeQuery can trigger "IllegalStateException: Recursive update" in
> CaffeineCache / ConcurrentHashMap
> -
>
> Key: SOLR-17280
> URL: https://issues.apache.org/jira/browse/SOLR-17280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Sample stacktrace...
> {noformat}
> 2> => java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> 2> java.lang.IllegalStateException: Recursive update
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
> ~[?:?]
> 2>at
> java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
> ~[?:?]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
> ~[caffeine-3.1.8.jar:3.1.8]
> 2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
> ~[main/:?]
> 2>at
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
> ~[main/:?]
> 2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
> ~[main/:?]
> 2>at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
> ~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
> 2024-02-14 16:48:06]
> 2>at
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:154)
> ~[main/:?]
> 2>at
>
[jira] [Created] (SOLR-17280) SolrRangeQuery can trigger "IllegalStateException: Recursive update" in CaffeineCache / ConcurrentHashMap
Chris M. Hostetter created SOLR-17280:
-
Summary: SolrRangeQuery can trigger "IllegalStateException:
Recursive update" in CaffeineCache / ConcurrentHashMap
Key: SOLR-17280
URL: https://issues.apache.org/jira/browse/SOLR-17280
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
Sample stacktrace...
{noformat}
2> => java.lang.IllegalStateException: Recursive update
2>at
java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
2> java.lang.IllegalStateException: Recursive update
2>at
java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1063)
~[?:?]
2>at
java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1541)
~[?:?]
2>at
com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2312)
~[caffeine-3.1.8.jar:3.1.8]
2>at
com.github.benmanes.caffeine.cache.BoundedLocalCache.put(BoundedLocalCache.java:2278)
~[caffeine-3.1.8.jar:3.1.8]
2>at org.apache.solr.search.CaffeineCache.put(CaffeineCache.java:277)
~[main/:?]
2>at
org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:482)
~[main/:?]
2>at
org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:552)
~[main/:?]
2>at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:135)
~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
2024-02-14 16:48:06]
2>at
org.apache.lucene.search.BooleanWeight.requiredBulkScorer(BooleanWeight.java:289)
~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
2024-02-14 16:48:06]
2>at
org.apache.lucene.search.BooleanWeight.booleanScorer(BooleanWeight.java:402)
~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
2024-02-14 16:48:06]
2>at
org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:443)
~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
2024-02-14 16:48:06]
2>at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:737)
~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
2024-02-14 16:48:06]
2>at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:720)
~[main/:?]
2>at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:552)
~[lucene-core-9.10.0.jar:9.10.0 695c0ac84508438302cd346a812cfa2fdc5a10df -
2024-02-14 16:48:06]
2>at
org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:154)
~[main/:?]
2>at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:141)
~[main/:?]
2>at
org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1387)
~[main/:?]
2>at
org.apache.solr.search.SolrIndexSearcher.lambda$getAndCacheDocSet$1(SolrIndexSearcher.java:991)
~[main/:?]
2>at
org.apache.solr.search.CaffeineCache.lambda$computeIfAbsent$1(CaffeineCache.java:258)
~[main/:?]
2>at
com.github.benmanes.caffeine.cache.LocalCache.lambda$statsAware$2(LocalCache.java:167)
~[caffeine-3.1.8.jar:3.1.8]
2>at
com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$14(BoundedLocalCache.java:2688)
~[caffeine-3.1.8.jar:3.1.8]
2>at
java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
~[?:?]
2>at
com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2686)
~[caffeine-3.1.8.jar:3.1.8]
2>at
com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2669)
~[caffeine-3.1.8.jar:3.1.8]
2>at
com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:112)
~[caffeine-3.1.8.jar:3.1.8]
2>at
com.github.benmanes.caffeine.cache.LocalManualCache.get(LocalManualCache.java:62)
~[caffeine-3.1.8.jar:3.1.8]
2>at
org.apache.solr.search.CaffeineCache.computeIfAbsent(CaffeineCache.java:253)
~[main/:?]
2>at
org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:991)
~[main/:?]
2>at
org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:946)
~[main/:?]
2>at
org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2367)
~[main/:?]
2>at
org.apache.solr.request.SimpleFacets.getFacetQueryCount(SimpleFacets.java:320)
~[main/:?]
2>at
org.apache.solr.request.SimpleFacets.getFacetQueryCounts(SimpleFacets.java:302)
~[main/:?]
2>at
org.apache.solr.handler.component.FacetComponent.getFacetCounts(FacetComponent.java:331)
~[main/:?]
2>at
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:279)
~[main/:?]
2>
Re: [PR] SOLR-10654: Introduce output of Prometheus metrics for Solr Core registry [solr]
dsmiley commented on PR #2405: URL: https://github.com/apache/solr/pull/2405#issuecomment-2098523726 ``` io.prometheus:prometheus-metrics-config:1.1.0 (1 constraints: 3e164ed8) io.prometheus:prometheus-metrics-exposition-formats:1.1.0 (1 constraints: 0405f335) io.prometheus:prometheus-metrics-model:1.1.0 (2 constraints: 411b133b) io.prometheus:prometheus-metrics-shaded-protobuf:1.1.0 (1 constraints: ``` No, there are 4 dependencies. Only the last one concerns me. Why is protobuf needed at all? Can it be excluded? Can any of the others be excluded as well, while you're at 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-10654: Introduce output of Prometheus metrics for Solr Core registry [solr]
mlbiscoc commented on PR #2405: URL: https://github.com/apache/solr/pull/2405#issuecomment-2098515667 > > There are enough additional dependencies that I feel strongly this should be another module. > > WDYT? Sorry, I somehow completely missed this comment. When you say be another module, do you mean move it to `solr/modules` that needs to be enabled? If so, I think that prometheus metrics is valuable enough to be part of core and enabled by default but I also only added 2 additional dependencies. Is that enough to be its own module? -- 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-17278) Timezone with DST=true and DST=0 fails test
[
https://issues.apache.org/jira/browse/SOLR-17278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844308#comment-17844308
]
Ishan Chattopadhyaya commented on SOLR-17278:
-
Fwiw, it is a useless suggestion.
> Timezone with DST=true and DST=0 fails test
> ---
>
> Key: SOLR-17278
> URL: https://issues.apache.org/jira/browse/SOLR-17278
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.7
>
> Attachments: SOLR-17278-1.patch, SOLR-17278.patch
>
>
> The TimeZoneUtilsTest#testValidIds() fails with some timezones that have
> useDaylightTime() as true but getDSTSavings() returns 0. Such timezones can't
> be converted to String using String.valueOf().
> Here's my JVM:
> {code}
> [ishan@deskmini solr] $ java -version
> openjdk version "11.0.22" 2024-01-16
> OpenJDK Runtime Environment (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7, mixed
> mode, sharing)
> {code}
--
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-17278) Timezone with DST=true and DST=0 fails test
[
https://issues.apache.org/jira/browse/SOLR-17278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844306#comment-17844306
]
Ishan Chattopadhyaya commented on SOLR-17278:
-
Ouch, I didn't check for it. I checked with `gradlew check` several times.
I can get to this only tomorrow. Sorry for the inconvenience.
> Timezone with DST=true and DST=0 fails test
> ---
>
> Key: SOLR-17278
> URL: https://issues.apache.org/jira/browse/SOLR-17278
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.7
>
> Attachments: SOLR-17278-1.patch, SOLR-17278.patch
>
>
> The TimeZoneUtilsTest#testValidIds() fails with some timezones that have
> useDaylightTime() as true but getDSTSavings() returns 0. Such timezones can't
> be converted to String using String.valueOf().
> Here's my JVM:
> {code}
> [ishan@deskmini solr] $ java -version
> openjdk version "11.0.22" 2024-01-16
> OpenJDK Runtime Environment (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7, mixed
> mode, sharing)
> {code}
--
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-10654: Introduce output of Prometheus metrics for Solr Core registry [solr]
dsmiley commented on PR #2405: URL: https://github.com/apache/solr/pull/2405#issuecomment-2098449310 > There are enough additional dependencies that I feel strongly this should be another module. WDYT? -- 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-17279) consolidate security.json constants in test code
[ https://issues.apache.org/jira/browse/SOLR-17279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844295#comment-17844295 ] Rudi Seitz commented on SOLR-17279: --- Will open a PR for this shortly. > consolidate security.json constants in test code > > > Key: SOLR-17279 > URL: https://issues.apache.org/jira/browse/SOLR-17279 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Rudi Seitz >Priority: Trivial > > Various unit tests declare a SECURITY_JSON constant. Maybe of these constants > are identical (likely introduced via copy/paste from other tests, resulting > in code duplication). This ticket is to consolidate the various SECURITY_JSON > constants across the tests in a central place. > This point was raised during discussion of the fix for SOLR-12813. See > https://github.com/apache/solr/pull/2404#discussion_r1568012056 > In that discussion, it was agreed to address SECURITY_JSON consolidation in a > separate ticket -- this is that ticket. > Tagging [~epugh] -- 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-17279) consolidate security.json constants in test code
Rudi Seitz created SOLR-17279: - Summary: consolidate security.json constants in test code Key: SOLR-17279 URL: https://issues.apache.org/jira/browse/SOLR-17279 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: Tests Reporter: Rudi Seitz Various unit tests declare a SECURITY_JSON constant. Maybe of these constants are identical (likely introduced via copy/paste from other tests, resulting in code duplication). This ticket is to consolidate the various SECURITY_JSON constants across the tests in a central place. This point was raised during discussion of the fix for SOLR-12813. See https://github.com/apache/solr/pull/2404#discussion_r1568012056 In that discussion, it was agreed to address SECURITY_JSON consolidation in a separate ticket -- this is that ticket. Tagging [~epugh] -- 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-17278) Timezone with DST=true and DST=0 fails test
[
https://issues.apache.org/jira/browse/SOLR-17278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844277#comment-17844277
]
Eric Pugh commented on SOLR-17278:
--
I think this commit broke errorprone? I am seeing:
Task :solr:core:compileTestJava FAILED
/home/runner/work/solr/solr/solr/core/src/test/org/apache/solr/util/TimeZoneUtilsTest.java:65:
warning: [OperatorPrecedence] Use grouping parenthesis to make the operator
precedence explicit
if (expected.useDaylightTime() && expected.getDSTSavings() == 0
^
(see [https://errorprone.info/bugpattern/OperatorPrecedence)]
Did you mean 'if ((expected.useDaylightTime() && expected.getDSTSavings() ==
0)'?
/home/runner/work/solr/solr/solr/core/src/test/org/apache/solr/util/TimeZoneUtilsTest.java:66:
warning: [OperatorPrecedence] Use grouping parenthesis to make the operator
precedence explicit
|| actual.useDaylightTime() && actual.getDSTSavings() == 0) {
^
(see [https://errorprone.info/bugpattern/OperatorPrecedence)]
Did you mean '|| (actual.useDaylightTime() && actual.getDSTSavings() == 0))
{'?
error: warnings found and -Werror specified
> Timezone with DST=true and DST=0 fails test
> ---
>
> Key: SOLR-17278
> URL: https://issues.apache.org/jira/browse/SOLR-17278
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.7
>
> Attachments: SOLR-17278-1.patch, SOLR-17278.patch
>
>
> The TimeZoneUtilsTest#testValidIds() fails with some timezones that have
> useDaylightTime() as true but getDSTSavings() returns 0. Such timezones can't
> be converted to String using String.valueOf().
> Here's my JVM:
> {code}
> [ishan@deskmini solr] $ java -version
> openjdk version "11.0.22" 2024-01-16
> OpenJDK Runtime Environment (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7, mixed
> mode, sharing)
> {code}
--
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] DelegatingBackupRepository extends AbstractBackupRepository. [solr]
bruno-roustant opened a new pull request, #2444: URL: https://github.com/apache/solr/pull/2444 One line PR to make DelegatingBackupRepository extend AbstractBackupRepository, so it has the config and the shouldVerifyChecksum field. -- 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-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
draperunner commented on code in PR #2232:
URL: https://github.com/apache/solr/pull/2232#discussion_r1592370513
##
solr/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java:
##
@@ -103,6 +104,13 @@ public class SolrExporter {
private static final String ARG_CREDENTIALS_HELP =
"Specify the credentials in the format username:password. Example:
--credentials solr:SolrRocks";
+ private static final String[] ARG_SSL_FLAGS = {"-ssl", "--ssl-enabled"};
+ private static final String ARG_SSL_METAVAR = "SSL_ENABLED";
+ private static final String ARG_SSL_DEST = "ssl_enabled";
+ private static final boolean ARG_SSL_DEFAULT = false;
+ private static final String ARG_SSL_HELP =
+ "Enable tls to Solr. Expects following env varables: SOLR_SSL_KEY_STORE,
SOLR_SSL_KEY_STORE_PASSWORD, SOLR_SSL_TRUST_STORE,
SOLR_SSL_TRUST_STORE_PASSWORD. Example: --ssl-enabled true";
Review Comment:
Good point. I have updated the text with your suggestion and also fixed the
typo in "varables".
--
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-13350: Multithreaded search [solr]
cpoerschke commented on PR #2248: URL: https://github.com/apache/solr/pull/2248#issuecomment-2098220313 > Merging to main was unexpected to me because of the healthy code review happening here didn't conclude. ... I was surprised by this merge too and my initial thought was that it might have been an accident and well that happens sometimes and we can just revert the commit and resume on a new PR then. -- 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-17137 Add configuration for SSL between Solr and Prometheus exporter. [solr]
epugh commented on code in PR #2232:
URL: https://github.com/apache/solr/pull/2232#discussion_r1592330465
##
solr/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java:
##
@@ -103,6 +104,13 @@ public class SolrExporter {
private static final String ARG_CREDENTIALS_HELP =
"Specify the credentials in the format username:password. Example:
--credentials solr:SolrRocks";
+ private static final String[] ARG_SSL_FLAGS = {"-ssl", "--ssl-enabled"};
+ private static final String ARG_SSL_METAVAR = "SSL_ENABLED";
+ private static final String ARG_SSL_DEST = "ssl_enabled";
+ private static final boolean ARG_SSL_DEFAULT = false;
+ private static final String ARG_SSL_HELP =
+ "Enable tls to Solr. Expects following env varables: SOLR_SSL_KEY_STORE,
SOLR_SSL_KEY_STORE_PASSWORD, SOLR_SSL_TRUST_STORE,
SOLR_SSL_TRUST_STORE_PASSWORD. Example: --ssl-enabled true";
Review Comment:
is TLS normally capitalized? "Enable TLS connection to Solr.".
--
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] EncryptionBackupRepository to back up encrypted files. [solr-sandbox]
bruno-roustant commented on code in PR #106:
URL: https://github.com/apache/solr-sandbox/pull/106#discussion_r1592115657
##
encryption/src/main/java/org/apache/solr/encryption/EncryptionBackupRepository.java:
##
@@ -0,0 +1,98 @@
+/*
+ * 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.encryption;
+
+import org.apache.lucene.codecs.CodecUtil;
+import org.apache.lucene.store.ChecksumIndexInput;
+import org.apache.lucene.store.Directory;
+import org.apache.lucene.store.FilterDirectory;
+import org.apache.solr.common.util.NamedList;
+import org.apache.solr.core.DirectoryFactory;
+import org.apache.solr.core.backup.repository.DelegatingBackupRepository;
+
+import java.io.IOException;
+import java.net.URI;
+
+import static
org.apache.solr.core.backup.repository.AbstractBackupRepository.PARAM_VERIFY_CHECKSUM;
+
+/**
+ * Encryption {@link org.apache.solr.core.backup.repository.BackupRepository}
that delegates
+ * to another {@link org.apache.solr.core.backup.repository.BackupRepository}
and intercepts
+ * index files copy to check their checksum in the decrypted from, but to copy
them in their
Review Comment:
Reworded using this PR description.
--
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
