[jira] [Commented] (SOLR-16507) Remove NodeStateProvider & Snitch
[ https://issues.apache.org/jira/browse/SOLR-16507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702633#comment-17702633 ] Vinayak Hegde commented on SOLR-16507: -- Okay, will pause the work until we get some advice from [~ab] or [~ilan]. > Remove NodeStateProvider & Snitch > - > > Key: SOLR-16507 > URL: https://issues.apache.org/jira/browse/SOLR-16507 > Project: Solr > Issue Type: Task >Reporter: David Smiley >Priority: Major > Labels: newdev > > The NodeStateProvider is a relic relating to the old autoscaling framework > that was removed in Solr 9. The only remaining usage of it is for > SplitShardCmd to check the disk space. For this, it could use the metrics > api. > I think we'll observe that Snitch and other classes in > org.apache.solr.common.cloud.rule can be removed as well, as it's related to > NodeStateProvider. > Only > org.apache.solr.cluster.placement.impl.AttributeFetcherImpl#getMetricSnitchTag > and org.apache.solr.cluster.placement.impl.NodeMetricImpl refer to some > constants in the code to be removed. Those constants could move out, > consolidated somewhere we think is appropriate. -- 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-16391) Cosmetic improvements and migration to JAX-RS (collection, collection prop, core CRUD APIs)
[
https://issues.apache.org/jira/browse/SOLR-16391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702642#comment-17702642
]
Vinayak Hegde commented on SOLR-16391:
--
I will work on _Is Collection Healthcheck Enabled_
> Cosmetic improvements and migration to JAX-RS (collection, collection prop,
> core CRUD APIs)
> ---
>
> Key: SOLR-16391
> URL: https://issues.apache.org/jira/browse/SOLR-16391
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
>Affects Versions: main (10.0)
>Reporter: Jason Gerlowski
>Priority: Major
> Labels: newdev
> Time Spent: 1h
> Remaining Estimate: 0h
>
> As mentioned on SOLR-15781, the v2 API currently has an experimental
> designation, and the community has expressed an interest in using this period
> to update our v2 endpoints to be more REST-ful and consistent. The current
> plan is to follow the specific changes laid out in [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
> though of course nothing there is set in stone and there are still warts to
> be worked out.
> While we're touching the code for these endpoints, we should also convert
> them to JAX-RS framework definitions. (This was initially tracked as a
> separate effort - see SOLR-16370 - but the edit that were required ended up
> overlapping so significantly with the "cosmetic" improvements here that in
> practice it almost always makes sense to do the two together.)
> This ticket plans to tackle making the changes required for Solr's collection
> and collection-prop CRUD APIs, as well as its collection-status APIs. These
> are described in detail in the spreadsheet linked above, but are summarized
> in the tables below for convenience and ease of tracking progress.
> *JAX-RS Conversion and Cosmetic Changes*
> ||API Name||Original Form||Desired Form||Status||Volunteer||
> |Create Collection|POST /api/collections \{create: \{...\}\}|POST
> /api/collections \{...\}|Open|Jason|
> |Get Collection Details|N/A|GET
> /api/collections/collName?details=specificFlags|Open|N/A|
> |Create Core|POST /api/cores \{"create": \{...\}\}|POST /api/cores
> \{...\}|Open|N/A|
> |Collection Ping/Healthcheck|GET /api/collections/collName/admin/ping|GET
> /api/collections/collName/health|Open|N/A|
> |Is Collection Healthcheck Enabled|GET
> /api/collections/collName/admin/ping?action=STATUS|GET
> /api/collections/collName/health/status|Open|N/A|
> |Enable/Disable Collection Healthcheck|GET
> /api/collections/collName/admin/ping?action=enable\|disable|PUT
> /api/collections/collName/health/status \{"enabled": true\|false\}|Open|N/A|
> |-Delete Collections-|-DELETE /api/collections/collName-|-DELETE
> /api/collections/collName-|-Finished-|-Jason-|
> |-Set Collection Property-|-POST /api/collections/collName
> \{set-collection-property: \{...\}\}-|-PUT
> /api/collections/collName/properties/propName \{"value":
> "someVal"\}-|-Finished-|-Jason-|
> |-Delete Collection Property-|-POST /api/collections/collName
> \{set-collection-property: \{...\}\}-|-DELETE
> /api/collections/collName/properties/propName-|-Finished-|-Jason-|
> *JAX-RS Conversion Only*
> ||API Name||Endpoint||Status||Volunteer||
> |-List Collections-|-GET /api/collections-|-Finished-|-Jason-|
--
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-16707) TestFiltering.testRandomFiltering Caffeine cache async=false IllegalStateException: Recursive update
[ https://issues.apache.org/jira/browse/SOLR-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702648#comment-17702648 ] Mikhail Khludnev commented on SOLR-16707: - I think it's what explained in [https://solr.apache.org/guide/solr/latest/configuration-guide/caches-warming.html#cache-parameters] > TestFiltering.testRandomFiltering Caffeine cache async=false > IllegalStateException: Recursive update > > > Key: SOLR-16707 > URL: https://issues.apache.org/jira/browse/SOLR-16707 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > > see the linked mail thread. > There are systematic test failures with async=false. > Why can't we just turn `async=true` for this test and others? -- 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
[GitHub] [solr] risdenk commented on pull request #1466: WIP Remove Guava usages
risdenk commented on PR #1466: URL: https://github.com/apache/solr/pull/1466#issuecomment-1476261941 ugh - [890a6cc](https://github.com/apache/solr/pull/1466/commits/890a6cca9ff0a48022338e1c2448797801a482d1) broke some tests. I need to figure out which change did 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
[GitHub] [solr] risdenk commented on a diff in pull request #1466: WIP Remove Guava usages
risdenk commented on code in PR #1466: URL: https://github.com/apache/solr/pull/1466#discussion_r1142197268 ## solr/modules/s3-repository/src/java/org/apache/solr/s3/S3StorageClient.java: ## @@ -422,6 +423,7 @@ private Collection deleteObjects(Collection paths) throws S3Exce * @param batchSize number of deletes to send to S3 at a time */ @VisibleForTesting + @SuppressForbidden(reason = "Lists.partition") Review Comment: I'd love to use Java Streams of this but doesn't seem to be a good fit. Will look at it again. -- 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
[GitHub] [solr] bszabo97 commented on pull request #1182: SOLR-16504 Convert CLI tools to Jetty HTTP 2 client.
bszabo97 commented on PR #1182: URL: https://github.com/apache/solr/pull/1182#issuecomment-1476344039 I have extracted an existing ResponseParser which parsed JSON responses and using that I was able to work around the hack which we talked about in Http2SolrClient, but this raised another concern: the `writeRawFile` function is (of course) also used for getting other raw files, not just json formatted ones, so I had to leave the original method which uses filestream. It is not quite pretty but I was not able to come up with a nicer solution. The other thing is that DistribPackageStore is also making use of the apache http client in some places which I was not yet able to get rid of, because firstly I wanted to solve this problem around the PackageStoreAPI. Any suggestion is very welcomed! -- 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-16707) TestFiltering.testRandomFiltering Caffeine cache async=false IllegalStateException: Recursive update
[
https://issues.apache.org/jira/browse/SOLR-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702769#comment-17702769
]
Michael Gibney commented on SOLR-16707:
---
The only possible benefit of {{async=false}} that I see documented there is
{quote}
Disabling the async option may use slightly less memory per cache entry at the
expense of increased CPU
{quote}
When this says "slightly", it _really_ means slightly. Specifically, 24 bytes
-- the cost of one {{CompletableFuture}} -- per entry, according to the
implementation of {{Accountable.ramBytesUsed()}}; IMO the documented
distinction is not enough to warrant retaining this as a configuration option.
Unless maybe there's another, implicit/undocumented reason?
> TestFiltering.testRandomFiltering Caffeine cache async=false
> IllegalStateException: Recursive update
>
>
> Key: SOLR-16707
> URL: https://issues.apache.org/jira/browse/SOLR-16707
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> see the linked mail thread.
> There are systematic test failures with async=false.
> Why can't we just turn `async=true` for this test and others?
--
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-16710) Suppress certain parameters in the logs
Joel Bernstein created SOLR-16710: - Summary: Suppress certain parameters in the logs Key: SOLR-16710 URL: https://issues.apache.org/jira/browse/SOLR-16710 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Joel Bernstein With KNN vector queries the logs records can be large because the vectors themselves can take 20K+ to express as strings. It's likely that many users would prefer not to log the vectors. I don't believe there is a way currently to tell Solr not to log certain parameters. This ticket is to discuss how this might done in a clean way. -- 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-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-16710: -- Description: With KNN vector queries the log records can be large because the vectors themselves can take 20K+ to express as strings. It's likely that many users would prefer not to log the vectors. I don't believe there is a way currently to tell Solr not to log certain parameters. This ticket is to discuss how this might done in a clean way. was: With KNN vector queries the logs records can be large because the vectors themselves can take 20K+ to express as strings. It's likely that many users would prefer not to log the vectors. I don't believe there is a way currently to tell Solr not to log certain parameters. This ticket is to discuss how this might done in a clean way. > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might done in a clean way. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein reassigned SOLR-16710: - Assignee: Joel Bernstein > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might be done in a clean way. -- 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-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-16710: -- Description: With KNN vector queries the log records can be large because the vectors themselves can take 20K+ to express as strings. It's likely that many users would prefer not to log the vectors. I don't believe there is a way currently to tell Solr not to log certain parameters. This ticket is to discuss how this might be done in a clean way. was: With KNN vector queries the log records can be large because the vectors themselves can take 20K+ to express as strings. It's likely that many users would prefer not to log the vectors. I don't believe there is a way currently to tell Solr not to log certain parameters. This ticket is to discuss how this might done in a clean way. > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might be done in a clean way. -- 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
[GitHub] [solr] risdenk commented on a diff in pull request #1466: WIP Remove Guava usages
risdenk commented on code in PR #1466:
URL: https://github.com/apache/solr/pull/1466#discussion_r1142246317
##
solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java:
##
@@ -1221,7 +1217,7 @@ public Elevation(Set elevatedIds, Set
excludedIds, String qu
includeQuery = EMPTY_QUERY;
this.elevatedIds = Collections.emptySet();
} else {
-this.elevatedIds = ImmutableSet.copyOf(elevatedIds);
+this.elevatedIds = Set.copyOf(elevatedIds);
Review Comment:
The issue is here :( `ImmutableSet.copyOf` keeps things in order it looks
like. `Set.copyOf` doesn't care.
--
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-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702785#comment-17702785 ] Kevin Risden commented on SOLR-16710: - SOLR-16582 is semi related about using markers - not sure that approach would work here. > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might be done in a clean way. -- 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
[GitHub] [solr] risdenk commented on a diff in pull request #1466: WIP Remove Guava usages
risdenk commented on code in PR #1466:
URL: https://github.com/apache/solr/pull/1466#discussion_r1142287314
##
solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java:
##
@@ -1221,7 +1217,7 @@ public Elevation(Set elevatedIds, Set
excludedIds, String qu
includeQuery = EMPTY_QUERY;
this.elevatedIds = Collections.emptySet();
} else {
-this.elevatedIds = ImmutableSet.copyOf(elevatedIds);
+this.elevatedIds = Set.copyOf(elevatedIds);
Review Comment:
Fixed in b2d239f651e407f7dea149e8d84f7db6424e4105
--
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
[GitHub] [solr] risdenk commented on a diff in pull request #1466: WIP Remove Guava usages
risdenk commented on code in PR #1466: URL: https://github.com/apache/solr/pull/1466#discussion_r1142197268 ## solr/modules/s3-repository/src/java/org/apache/solr/s3/S3StorageClient.java: ## @@ -422,6 +423,7 @@ private Collection deleteObjects(Collection paths) throws S3Exce * @param batchSize number of deletes to send to S3 at a time */ @VisibleForTesting + @SuppressForbidden(reason = "Lists.partition") Review Comment: I'd love to use Java Streams for this but doesn't seem to be a good fit. Will look at it again. -- 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
[GitHub] [solr] risdenk commented on a diff in pull request #1466: WIP Remove Guava usages
risdenk commented on code in PR #1466:
URL: https://github.com/apache/solr/pull/1466#discussion_r1142293958
##
solr/core/src/java/org/apache/solr/handler/designer/ManagedSchemaDiff.java:
##
@@ -215,7 +216,7 @@ protected static Map diff(
* @param simpleOrderedMap2 Map to treat as "right" map
* @return List containing the left diff and right diff
*/
- @SuppressWarnings("unchecked")
Review Comment:
See if there is a java streams way to do this
##
solr/core/src/java/org/apache/solr/handler/designer/SchemaDesignerConfigSetHelper.java:
##
@@ -755,6 +756,7 @@ protected ZkStateReader zkStateReader() {
return cc.getZkController().getZkStateReader();
}
+ @SuppressForbidden(reason = "Sets.difference")
Review Comment:
See if there is a java streams way to do this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] hmontesdeoca opened a new issue, #534: zk provided pvc
hmontesdeoca opened a new issue, #534: URL: https://github.com/apache/solr-operator/issues/534 Hello, I am currently using Azure to set up aks clusters utilizing solr-cloud helm charts and the provided zookeeper ensemble. I want to mount zookeeper logs onto a Azure File Share but I cant seem to specify a pvc for the zk provided ensemble. It only seems to accept a 'spec' as some sort of reference. How can I specify a PVC for zookeeper? Can I mount directly to the logs directory for zookeeper pods? ``` zk: provided: persistence: spec: storageClassName: "solr" #can I specify a path, volume, volume mount, or pvc? ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] Frankkkkk commented on issue #534: zk provided pvc
Frank commented on issue #534: URL: https://github.com/apache/solr-operator/issues/534#issuecomment-1476486297 You must specify a storage class name. You can list them with `kubectl get sc`. On azure, you could use `azurefile-csi-premium` for example -- 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
[GitHub] [solr-operator] hmontesdeoca commented on issue #534: zk provided pvc
hmontesdeoca commented on issue #534: URL: https://github.com/apache/solr-operator/issues/534#issuecomment-1476504523 I have specified a storage class name but I would like to mount this pvc to an azure file share. For example, once I create this release via helm I notice it automatically creates new data pvc's according to how many replicas I would like set for the ensemble. In this case the following command `kubectl get pvc -n ` with 3 replicas for a values file this would show: `-solrcloud-zookeeper-0` `-solrcloud-zookeeper-1` `-solrcloud-zookeeper-2' And they are all bound to the storage class "solr" as mentioned above with the snippet of the yaml file. I would simply like to have a mount to a fileshare represented as a pvc in addition to these automatically provisioned pvcs. This could be seen with the solrcloud helm chart and many others. I just cant seem to find the documentation on this zookeeper provided subchart when specifying volume mounts. -- 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-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702839#comment-17702839 ] Alex Deparvu commented on SOLR-16710: - not sure if this can provide the param filtering you need to reduce the logs https://solr.apache.org/guide/solr/latest/query-guide/common-query-parameters.html#logparamslist-parameter > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might be done in a clean way. -- 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-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702840#comment-17702840 ] Joel Bernstein commented on SOLR-16710: --- [~stillalex] that looks to be exactly what I had in mind for this ticket. I'll try it out. Thanks! > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might be done in a clean way. -- 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
[GitHub] [solr] HoustonPutman merged pull request #1470: Fix smoke test jar checks & release wizard
HoustonPutman merged PR #1470: URL: https://github.com/apache/solr/pull/1470 -- 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
[GitHub] [solr] HoustonPutman commented on pull request #1436: Add solrbot dependency upgrades to CHANGES for 9.2
HoustonPutman commented on PR #1436: URL: https://github.com/apache/solr/pull/1436#issuecomment-1476581693 Sorry I missed this somehow, I will merge it before starting the RC! -- 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
[GitHub] [solr] risdenk commented on pull request #1466: WIP Remove Guava usages
risdenk commented on PR #1466: URL: https://github.com/apache/solr/pull/1466#issuecomment-1476588836 Things are looking better but have this reproducing failure: ``` ./gradlew :solr:core:test --tests "org.apache.solr.cloud.NestedShardedAtomicUpdateTest.doNestedInplaceUpdateTest" -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m" -Ptests.seed=E12B264EDC3501AD -Ptests.file.encoding=ISO-8859-1 ``` haven't had a chance to figure out why yet. -- 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
[GitHub] [solr] epugh commented on pull request #1182: SOLR-16504 Convert CLI tools to Jetty HTTP 2 client.
epugh commented on PR #1182: URL: https://github.com/apache/solr/pull/1182#issuecomment-1476645596 I wonder if the DistribPackageStore should wait for another time/PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-10888) almost self-generating python script(s) to access V2 APIs
[
https://issues.apache.org/jira/browse/SOLR-10888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702860#comment-17702860
]
Eric Pugh commented on SOLR-10888:
--
I think this ticket has been obsoleted by the new V2 API's support OpenAPI
annotations, and that is what we'll use to generate language specific clients!
Thoughts on closing this one?
> almost self-generating python script(s) to access V2 APIs
> -
>
> Key: SOLR-10888
> URL: https://issues.apache.org/jira/browse/SOLR-10888
> Project: Solr
> Issue Type: New Feature
> Components: v2 API
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10888.patch, solr_cli.py
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The V2 API supports introspection and the results of such introspection(s)
> can be used to automatically on-the-fly generate a (nested)
> {{argparse.ArgumentParser}} in a python script and then to again
> automatically transform the script arguments into a url and http call to the
> V2 API.
> Illustrative patch and sample output to follow.
--
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-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702862#comment-17702862 ] Joel Bernstein commented on SOLR-16710: --- https://solr.apache.org/guide/solr/latest/query-guide/common-query-parameters.html#logparamslist-parameter is exactly what we needed, thanks! Closing out this ticket. > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might be done in a clean way. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16710) Suppress certain parameters in the logs
[ https://issues.apache.org/jira/browse/SOLR-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein resolved SOLR-16710. --- Resolution: Not A Problem > Suppress certain parameters in the logs > --- > > Key: SOLR-16710 > URL: https://issues.apache.org/jira/browse/SOLR-16710 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > With KNN vector queries the log records can be large because the vectors > themselves can take 20K+ to express as strings. It's likely that many users > would prefer not to log the vectors. I don't believe there is a way currently > to tell Solr not to log certain parameters. This ticket is to discuss how > this might be done in a clean way. -- 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
[GitHub] [solr] dsmiley commented on pull request #1182: SOLR-16504 Convert CLI tools to Jetty HTTP 2 client.
dsmiley commented on PR #1182: URL: https://github.com/apache/solr/pull/1182#issuecomment-1476674958 > I wonder if the DistribPackageStore should wait for another time/PR? +1 Those scope of this issue is just CLI tools so definitely keep this already big PR focused on that please. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-16711) Seperate tools out of SolrCLI.java into their own files.
Eric Pugh created SOLR-16711: Summary: Seperate tools out of SolrCLI.java into their own files. Key: SOLR-16711 URL: https://issues.apache.org/jira/browse/SOLR-16711 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: clients - java Affects Versions: 9.1.1 Reporter: Eric Pugh Assignee: Eric Pugh On my flight home from vacation, I looked at SolrCLI again and found it completly overwhelming of a class. I'd like to make it more manageable to work with by pulling out the various Tools into a org.apache.solr.utils.cli package. I suspect there are opportunities to simplify how the various tools work as well... -- 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
[GitHub] [solr] epugh opened a new pull request, #1476: SOLR-16711: Extract SolrCLI tool implementations into their own package and classes
epugh opened a new pull request, #1476: URL: https://github.com/apache/solr/pull/1476 https://issues.apache.org/jira/browse/SOLR-16711 # Description SolrCLI.java is overwhelming to work with. # Solution Extract tools into their own package. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [X ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) 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
[GitHub] [solr] dsmiley commented on a diff in pull request #1182: SOLR-16504 Convert CLI tools to Jetty HTTP 2 client.
dsmiley commented on code in PR #1182:
URL: https://github.com/apache/solr/pull/1182#discussion_r1142492764
##
solr/core/src/java/org/apache/solr/filestore/DistribPackageStore.java:
##
@@ -181,14 +189,17 @@ private boolean fetchFileFromNodeAndPersist(String
fromNode) {
ByteBuffer metadata = null;
Map m = null;
- try {
-metadata =
-Utils.executeGET(
-coreContainer.getUpdateShardHandler().getDefaultHttpClient(),
-baseUrl + "/node/files" + getMetaPath(),
-Utils.newBytesConsumer((int) MAX_PKG_SIZE));
+ try (SolrClient solrClient = new
Http2SolrClient.Builder(baseUrl).build()) {
+GenericSolrRequest request =
+new GenericSolrRequest(
+SolrRequest.METHOD.GET,
+"/node/files" + getMetaPath(),
+new ModifiableSolrParams().add(CommonParams.WT,
CommonParams.JSON));
Review Comment:
Looks like you were hunting for string constants wherever you could find
them. In this line of code, we want "json" as a value, not as a parameter name
(which it is also, actually). You can just use "json" string literal.
--
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
[GitHub] [solr] epugh merged pull request #1475: Use TimeUnit parameter on builder methods.
epugh merged PR #1475: URL: https://github.com/apache/solr/pull/1475 -- 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
[GitHub] [solr] epugh commented on pull request #1353: SOLR-16563 DefaultCollectionSolrClient
epugh commented on PR #1353: URL: https://github.com/apache/solr/pull/1353#issuecomment-1476728883 I don't think right now I am going to push forward with this approach While it may have value in general, it didn't make it easier for me to migrate the tests away from changing the collection that the client was pointed at. Instead, I am working on updating the tests to not require/need the use of a `solrClient.setDefaultCollection()` method... -- 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
[GitHub] [solr] epugh commented on a diff in pull request #1256: SOLR-10466: setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
epugh commented on code in PR #1256:
URL: https://github.com/apache/solr/pull/1256#discussion_r1142529353
##
solr/test-framework/src/java/org/apache/solr/cloud/MiniSolrCloudCluster.java:
##
@@ -716,6 +718,12 @@ public void shutdown() throws Exception {
try {
IOUtils.closeQuietly(solrClient);
+
+ solrClientForCollectionCache.values().parallelStream()
Review Comment:
done
--
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
[GitHub] [solr] epugh commented on a diff in pull request #1256: SOLR-10466: setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
epugh commented on code in PR #1256:
URL: https://github.com/apache/solr/pull/1256#discussion_r1142529060
##
solr/test-framework/src/java/org/apache/solr/cloud/MiniSolrCloudCluster.java:
##
@@ -156,11 +157,12 @@ public class MiniSolrCloudCluster {
private final boolean externalZkServer;
private final List jettys = new CopyOnWriteArrayList<>();
private final Path baseDir;
- private final CloudSolrClient solrClient;
+ private CloudSolrClient solrClient;
Review Comment:
So, I have gone back and forth on this. it feels weird to use a "" string
as a magic meaning... aRgualby no collection should be specified by a null
instead of a "".And solrClient is now actually only ever used internally to
MiniSolrCloudCluster...
##
solr/test-framework/src/java/org/apache/solr/cloud/MiniSolrCloudCluster.java:
##
@@ -156,11 +157,12 @@ public class MiniSolrCloudCluster {
private final boolean externalZkServer;
private final List jettys = new CopyOnWriteArrayList<>();
private final Path baseDir;
- private final CloudSolrClient solrClient;
+ private CloudSolrClient solrClient;
private final JettyConfig jettyConfig;
private final boolean trackJettyMetrics;
private final AtomicInteger nodeIds = new AtomicInteger();
+ private Map solrClientForCollectionCache = new
ConcurrentHashMap<>();
Review Comment:
Done!
--
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
[GitHub] [solr] epugh commented on a diff in pull request #1256: SOLR-10466: setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
epugh commented on code in PR #1256:
URL: https://github.com/apache/solr/pull/1256#discussion_r1142529996
##
solr/solr-ref-guide/modules/indexing-guide/examples/IndexingNestedDocuments.java:
##
@@ -66,89 +69,94 @@ public static SolrClient getSolrClient() {
*/
public void testIndexingAnonKids() throws Exception {
final String collection = "test_anon";
+
CollectionAdminRequest.createCollection(collection, ANON_KIDS_CONFIG, 1, 1)
.setPerReplicaState(SolrCloudTestCase.USE_PER_REPLICA_STATE)
.process(cluster.getSolrClient());
-cluster.getSolrClient().setDefaultCollection(collection);
+
+// configure the client with the default collection name, to simplify our
example below.
+IndexingNestedDocuments.clientUsedInSolrJExample =
+
cluster.basicSolrClientBuilder().withDefaultCollection(collection).build();
//
-// DO NOT MODIFY THESE EXAMPLE DOCS WITH OUT MAKING THE SAME CHANGES TO
THE JSON AND XML
-// EQUIVILENT EXAMPLES IN 'indexing-nested-documents.adoc'
+// DO NOT MODIFY THESE EXAMPLE DOCS WITHOUT MAKING THE SAME CHANGES TO THE
JSON AND XML
+// EQUIVALENT EXAMPLES IN 'indexing-nested-documents.adoc'
Review Comment:
Yeah, as in, it didn't need to be done! Thanks for the reminder! The code
change was actually just typo fixes.
--
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
[GitHub] [solr] epugh commented on a diff in pull request #1256: SOLR-10466: setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
epugh commented on code in PR #1256:
URL: https://github.com/apache/solr/pull/1256#discussion_r1142530226
##
solr/core/src/test/org/apache/solr/cloud/TestCloudSearcherWarming.java:
##
@@ -311,14 +307,11 @@ public boolean onStateChanged(Set liveNodes,
DocCollection collectionSta
log.error(
"registered searcher not null, maxdocs = {}",
registeredSearcher.get().maxDoc());
+registeredSearcher.decref();
Review Comment:
Restored back to what you had... thanks!
--
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
[GitHub] [solr] epugh commented on a diff in pull request #1256: SOLR-10466: setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
epugh commented on code in PR #1256:
URL: https://github.com/apache/solr/pull/1256#discussion_r1142530690
##
solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java:
##
@@ -305,8 +306,17 @@ private void doForceLeader(String collectionName, String
shard)
throws IOException, SolrServerException {
CollectionAdminRequest.ForceLeader forceLeader =
CollectionAdminRequest.forceLeaderElection(collectionName, shard);
+boolean shardLeadersOnly = random().nextBoolean();
+RandomizingCloudSolrClientBuilder builder =
Review Comment:
I wish we had a commumnity standard for when to use a var...or that `gw
tidy` did it for me.. I went ahead and put one in.
--
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
[GitHub] [solr] epugh commented on a diff in pull request #1256: SOLR-10466: setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
epugh commented on code in PR #1256:
URL: https://github.com/apache/solr/pull/1256#discussion_r1142531595
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java:
##
@@ -332,6 +335,11 @@ public Builder withRetryExpiryTime(long expiryTime,
TimeUnit unit) {
return this;
}
+/** Sets the default collection for request. */
+public Builder withDefaultCollection(String collection) {
Review Comment:
Would you like to push up an example of what you are thinking? I'm not
wedded to how this works ;-).
--
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
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1476: SOLR-16711: Extract SolrCLI tool implementations into their own package and classes
sonatype-lift[bot] commented on code in PR #1476:
URL: https://github.com/apache/solr/pull/1476#discussion_r1142548264
##
solr/core/src/java/org/apache/solr/util/SolrCLI.java:
##
@@ -267,7 +155,7 @@ protected abstract void runCloudTool(CloudLegacySolrClient
cloudSolrClient, Comm
OPTION_VERBOSE
};
- private static void exit(int exitStatus) {
+ public static void exit(int exitStatus) {
try {
System.exit(exitStatus);
} catch (java.lang.SecurityException secExc) {
Review Comment:
https://lift.sonatype.com/api/commentimage/fixrate/7/display.svg";>
*[UnnecessarilyFullyQualified](https://errorprone.info/bugpattern/UnnecessarilyFullyQualified):*
This fully qualified name is unambiguous to the compiler if imported.
---
```suggestion
} catch (SecurityException secExc) {
```
---
ℹ️ Expand to see all @sonatype-lift
commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Help us improve LIFT! (Sonatype LiftBot external survey)
Was this a good recommendation for you? Answering this survey
will not impact your Lift settings.
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=444297000&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=444297000&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=444297000&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=444297000&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=444297000&lift_comment_rating=5)
]
##
solr/core/src/java/org/apache/solr/util/SolrCLI.java:
##
@@ -1227,156 +918,7 @@ public String toString() {
}
}
- /** Requests health information about a specific collection in SolrCloud. */
- public static class HealthcheckTool extends SolrCloudTool {
-
-public HealthcheckTool() {
- this(CLIO.getOutStream());
-}
-
-public HealthcheckTool(PrintStream stdout) {
- super(stdout);
-}
-
-@Override
-public String getName() {
- return "healthcheck";
-}
-
-@Override
-protected void runCloudTool(CloudLegacySolrClient cloudSolrClient,
CommandLine cli)
-throws Exception {
- raiseLogLevelUnlessVerbose(cli);
- String collection = cli.getOptionValue("collection");
- if (collection == null)
-throw new IllegalArgumentException(
-"Must provide a collection to run a healthcheck against!");
-
- log.debug("Running healthcheck for {}", collection);
-
- ZkStateReader zkStateReader = ZkStateReader.from(cloudSolrClient);
-
- ClusterState clusterState = zkStateReader.getClusterState();
- Set liveNodes = clusterState.getLiveNodes();
- final DocCollection docCollection =
clusterState.getCollectionOrNull(collection);
- if (docCollection == null || docCollection.getSlices() == null)
-throw new IllegalArgumentException("Collection " + collection + " not
found!");
-
- Collection slices = docCollection.getSlices();
- // Test http code using a HEAD request first, fail fast if
authentication failure
- String urlForColl =
- zkStateReader.getLeaderUrl(collection,
slices.stream().findFirst().get().getName(), 1000);
- attemptHttpHead(urlForColl, cloudSolrClient.getHttpClient());
-
- SolrQuery q = new SolrQuery("*:*");
- q.setRows(0);
- QueryResponse qr = cloudSolrClient.query(collection, q);
- String collErr = null;
- long docCount = -1;
- try {
-docCount = qr.getResults().getNumFound();
- } catch (Exception exc) {
-collErr = String.valueOf(exc);
- }
-
- List shardList = new ArrayList<>();
- boolean collectionIsHealthy = (docCount != -1);
-
- for (Slice slice : slices) {
-String shardName = slice.getName();
-// since we're reporting health of this shard, there's no guarantee of
a leader
-String leaderUrl = null;
-try {
- leaderUrl = zkStateReader.getLeaderUrl(collection, shardName, 1000);
-} catch (Exception exc) {
- log.warn("Failed to get leader for shard
[GitHub] [solr] risdenk commented on pull request #1466: WIP Remove Guava usages
risdenk commented on PR #1466: URL: https://github.com/apache/solr/pull/1466#issuecomment-1476782916 `NestedShadedAtomicUpdateTest` fixed with 184449a -- 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-10285) Skip LEADER messages when there are leader only shards
[
https://issues.apache.org/jira/browse/SOLR-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702900#comment-17702900
]
David Smiley commented on SOLR-10285:
-
FYI my colleague [~pierre.salagnac] observed that this optimization can be
faulty when the leader looses the status and becomes the leader again (no other
leader in the meantime). May require the Overseer to be very busy. It'd be
better to optimize avoiding recovery status instead of leadership.
> Skip LEADER messages when there are leader only shards
> --
>
> Key: SOLR-10285
> URL: https://issues.apache.org/jira/browse/SOLR-10285
> Project: Solr
> Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: 7.1, 8.0
>
> Attachments: SOLR-10285.patch, SOLR-10285.patch, SOLR-10285.patch
>
>
> For shards which have 1 replica ( leader ) we know it doesn't need to recover
> from anyone. We should short-circuit the recovery process in this case.
> The motivation for this being that we will generate less state events and be
> able to mark these replicas as active again without it needing to go into
> 'recovering' state.
> We already short circuit when you set {{-Dsolrcloud.skip.autorecovery=true}}
> but that sys prop was meant for tests only. Extending this to make sure the
> code short-circuits when the core knows its the only replica in the shard is
> the motivation of the Jira.
--
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
[GitHub] [solr] HoustonPutman merged pull request #1436: Add solrbot dependency upgrades to CHANGES for 9.2
HoustonPutman merged PR #1436: URL: https://github.com/apache/solr/pull/1436 -- 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
[GitHub] [solr] risdenk commented on a diff in pull request #1466: WIP Remove Guava usages
risdenk commented on code in PR #1466: URL: https://github.com/apache/solr/pull/1466#discussion_r1142606285 ## solr/modules/s3-repository/src/java/org/apache/solr/s3/S3StorageClient.java: ## @@ -422,6 +423,7 @@ private Collection deleteObjects(Collection paths) throws S3Exce * @param batchSize number of deletes to send to S3 at a time */ @VisibleForTesting + @SuppressForbidden(reason = "Lists.partition") Review Comment: don't see a simple way to do this with java streams. -- 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
[GitHub] [solr] risdenk commented on a diff in pull request #1466: WIP Remove Guava usages
risdenk commented on code in PR #1466:
URL: https://github.com/apache/solr/pull/1466#discussion_r1142606711
##
solr/core/src/java/org/apache/solr/handler/designer/ManagedSchemaDiff.java:
##
@@ -215,7 +216,7 @@ protected static Map diff(
* @param simpleOrderedMap2 Map to treat as "right" map
* @return List containing the left diff and right diff
*/
- @SuppressWarnings("unchecked")
Review Comment:
Handled in df954cc38766a2094d623ba816ac71bd0c55231e
##
solr/core/src/java/org/apache/solr/handler/designer/SchemaDesignerConfigSetHelper.java:
##
@@ -755,6 +756,7 @@ protected ZkStateReader zkStateReader() {
return cc.getZkController().getZkStateReader();
}
+ @SuppressForbidden(reason = "Sets.difference")
Review Comment:
handled in df954cc38766a2094d623ba816ac71bd0c55231e
--
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-16707) TestFiltering.testRandomFiltering Caffeine cache async=false IllegalStateException: Recursive update
[
https://issues.apache.org/jira/browse/SOLR-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702919#comment-17702919
]
Mikhail Khludnev commented on SOLR-16707:
-
{quote}However, the async cache will not prevent data races for time-limited
queries, since those are expected to provide partial results.
{quote}
> TestFiltering.testRandomFiltering Caffeine cache async=false
> IllegalStateException: Recursive update
>
>
> Key: SOLR-16707
> URL: https://issues.apache.org/jira/browse/SOLR-16707
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> see the linked mail thread.
> There are systematic test failures with async=false.
> Why can't we just turn `async=true` for this test and others?
--
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
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1476: SOLR-16711: Extract SolrCLI tool implementations into their own package and classes
sonatype-lift[bot] commented on code in PR #1476:
URL: https://github.com/apache/solr/pull/1476#discussion_r1142689261
##
solr/core/src/java/org/apache/solr/util/cli/ToolBase.java:
##
@@ -0,0 +1,70 @@
+/*
+ * 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.util.cli;
+
+import java.io.PrintStream;
+import org.apache.commons.cli.CommandLine;
+import org.apache.solr.util.CLIO;
+import org.apache.solr.util.SolrCLI;
+
+public abstract class ToolBase implements Tool {
+ protected PrintStream stdout;
+ protected boolean verbose = false;
+
+ protected ToolBase() {
+this(CLIO.getOutStream());
+ }
+
+ protected ToolBase(PrintStream stdout) {
+this.stdout = stdout;
+ }
+
+ protected void echoIfVerbose(final String msg, CommandLine cli) {
+if (cli.hasOption(SolrCLI.OPTION_VERBOSE.getOpt())) {
+ echo(msg);
+}
+ }
+
+ protected void echo(final String msg) {
+stdout.println(msg);
+ }
+
+ @Override
+ public int runTool(CommandLine cli) throws Exception {
+verbose = cli.hasOption(SolrCLI.OPTION_VERBOSE.getOpt());
+
+int toolExitStatus = 0;
+try {
+ runImpl(cli);
+} catch (Exception exc) {
+ // since this is a CLI, spare the user the stacktrace
+ String excMsg = exc.getMessage();
+ if (excMsg != null) {
+CLIO.err("\nERROR: " + excMsg + "\n");
+if (verbose) {
+ exc.printStackTrace(CLIO.getErrStream());
Review Comment:
https://lift.sonatype.com/api/commentimage/fixrate/0/display.svg";>
*[INFORMATION_EXPOSURE_THROUGH_AN_ERROR_MESSAGE](https://find-sec-bugs.github.io/bugs.htm#INFORMATION_EXPOSURE_THROUGH_AN_ERROR_MESSAGE):*
Possible information exposure through an error message
---
ℹ️ Expand to see all @sonatype-lift
commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Help us improve LIFT! (Sonatype LiftBot external survey)
Was this a good recommendation for you? Answering this survey
will not impact your Lift settings.
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=04662&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=04662&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=04662&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=04662&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=04662&lift_comment_rating=5)
]
##
solr/core/src/java/org/apache/solr/util/cli/RunExampleTool.java:
##
@@ -0,0 +1,1055 @@
+/*
+ * 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.util.cli;
+
+i
[jira] [Created] (SOLR-16712) Simplify PerReplicaStates (PRS) logic in DocCollection
Patson Luk created SOLR-16712: - Summary: Simplify PerReplicaStates (PRS) logic in DocCollection Key: SOLR-16712 URL: https://issues.apache.org/jira/browse/SOLR-16712 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 9.1.1, main (10.0) Reporter: Patson Luk The current implementation of PRS requires an extra param to the DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS states from ZK. The implementation of such supplier `LazyPrsSupplier` would only fetch the state on first call. While this flow does work properly, this flow might introduce some unnecessary complexity: # PRS entry fetching from ZK is done either during or after the `DocCollection` construction, this could be a bit inconsistent with existing non PRS `DocCollection` design which `DocCollection` is simply a immutable container that does not fetch data after its instantiation # The lazy fetching could introduce some uncertainties as to when exactly the fetching happens (and if any Zookeeper IO exceptions arises) My guess was that the lazy loading was introduced in https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS states multiple times in the ctor of `DocCollection`, however, if we only fetch the `PerReplicaStates` once on update before calling the `DocCollection` ctor, and pass the `PerReplicaStates` object to the `DocCollection` instead, it can probably achieve similar result but with reduced complexity. -- 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-16712) Simplify PerReplicaStates (PRS) logic in DocCollection, replace PrsSupplier with actual PerReplicaStates param
[ https://issues.apache.org/jira/browse/SOLR-16712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patson Luk updated SOLR-16712: -- Summary: Simplify PerReplicaStates (PRS) logic in DocCollection, replace PrsSupplier with actual PerReplicaStates param (was: Simplify PerReplicaStates (PRS) logic in DocCollection) > Simplify PerReplicaStates (PRS) logic in DocCollection, replace PrsSupplier > with actual PerReplicaStates param > -- > > Key: SOLR-16712 > URL: https://issues.apache.org/jira/browse/SOLR-16712 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: main (10.0), 9.1.1 >Reporter: Patson Luk >Priority: Major > > The current implementation of PRS requires an extra param to the > DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS > states from ZK. The implementation of such supplier `LazyPrsSupplier` would > only fetch the state on first call. > > While this flow does work properly, this flow might introduce some > unnecessary complexity: > # PRS entry fetching from ZK is done either during or after the > `DocCollection` construction, this could be a bit inconsistent with existing > non PRS `DocCollection` design which `DocCollection` is simply a immutable > container that does not fetch data after its instantiation > # The lazy fetching could introduce some uncertainties as to when exactly > the fetching happens (and if any Zookeeper IO exceptions arises) > > My guess was that the lazy loading was introduced in > https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS > states multiple times in the ctor of `DocCollection`, however, if we only > fetch the `PerReplicaStates` once on update before calling the > `DocCollection` ctor, and pass the `PerReplicaStates` object to the > `DocCollection` instead, it can probably achieve similar result but with > reduced complexity. > > -- 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-16712) Simplify PerReplicaStates (PRS) logic in DocCollection, replace PrsSupplier with actual PerReplicaStates param
[ https://issues.apache.org/jira/browse/SOLR-16712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patson Luk updated SOLR-16712: -- Description: The current implementation of PRS requires an extra param to the DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS states from ZK. The implementation of such supplier `LazyPrsSupplier` would only fetch the state on first call. While this flow does work properly, this flow might introduce some unnecessary complexity: # PRS entry fetching from ZK is done either during or after the `DocCollection` construction, this could be a bit inconsistent with existing non PRS `DocCollection` design which `DocCollection` is simply a immutable container that does not fetch data after its instantiation # The lazy fetching could introduce some uncertainties as to when exactly the fetching happens (and if any Zookeeper IO exceptions arises) My guess was that the lazy loading was introduced in https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS states multiple times in the ctor of `DocCollection`, however, if we only fetch the `PerReplicaStates` once on update before calling the `DocCollection` ctor, and pass the `PerReplicaStates` object to the `DocCollection` instead, it can probably achieve similar result but with reduced uncertainty after `DocCollection` construction. was: The current implementation of PRS requires an extra param to the DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS states from ZK. The implementation of such supplier `LazyPrsSupplier` would only fetch the state on first call. While this flow does work properly, this flow might introduce some unnecessary complexity: # PRS entry fetching from ZK is done either during or after the `DocCollection` construction, this could be a bit inconsistent with existing non PRS `DocCollection` design which `DocCollection` is simply a immutable container that does not fetch data after its instantiation # The lazy fetching could introduce some uncertainties as to when exactly the fetching happens (and if any Zookeeper IO exceptions arises) My guess was that the lazy loading was introduced in https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS states multiple times in the ctor of `DocCollection`, however, if we only fetch the `PerReplicaStates` once on update before calling the `DocCollection` ctor, and pass the `PerReplicaStates` object to the `DocCollection` instead, it can probably achieve similar result but with reduced complexity. > Simplify PerReplicaStates (PRS) logic in DocCollection, replace PrsSupplier > with actual PerReplicaStates param > -- > > Key: SOLR-16712 > URL: https://issues.apache.org/jira/browse/SOLR-16712 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: main (10.0), 9.1.1 >Reporter: Patson Luk >Priority: Major > > The current implementation of PRS requires an extra param to the > DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS > states from ZK. The implementation of such supplier `LazyPrsSupplier` would > only fetch the state on first call. > > While this flow does work properly, this flow might introduce some > unnecessary complexity: > # PRS entry fetching from ZK is done either during or after the > `DocCollection` construction, this could be a bit inconsistent with existing > non PRS `DocCollection` design which `DocCollection` is simply a immutable > container that does not fetch data after its instantiation > # The lazy fetching could introduce some uncertainties as to when exactly > the fetching happens (and if any Zookeeper IO exceptions arises) > > My guess was that the lazy loading was introduced in > https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS > states multiple times in the ctor of `DocCollection`, however, if we only > fetch the `PerReplicaStates` once on update before calling the > `DocCollection` ctor, and pass the `PerReplicaStates` object to the > `DocCollection` instead, it can probably achieve similar result but with > reduced uncertainty after `DocCollection` construction. > > -- 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-16712) Simplify PerReplicaStates (PRS) logic in DocCollection, replace PrsSupplier with actual PerReplicaStates param
[ https://issues.apache.org/jira/browse/SOLR-16712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patson Luk updated SOLR-16712: -- Description: The current implementation of PRS requires an extra param to the DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS states from ZK. The implementation of such supplier `LazyPrsSupplier` would only fetch the state on first call. While this flow does work properly, this flow might introduce some unnecessary complexity: # PRS entry fetching from ZK is done either during or after the `DocCollection` construction, this could be a bit inconsistent with existing non PRS `DocCollection` design which `DocCollection` is simply a immutable container that does not fetch data after its instantiation # The lazy fetching could introduce some uncertainties as to when exactly the fetching happens (and if any Zookeeper IO exceptions arises) My guess was that the lazy loading was introduced in https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS states multiple times in the ctor of `DocCollection`, however, if we only fetch the `PerReplicaStates` once on update before calling the `DocCollection` ctor, and pass the `PerReplicaStates` object to the `DocCollection` instead, it can probably achieve similar result but with reduced uncertainty after `DocCollection` construction. There's another branch which experimented with making DocCollection, Slice and Replica immutable as well for PRS enabled collection [https://github.com/cowpaths/fullstory-solr/pull/84] but is beyond the discussion of this Jira ticket was: The current implementation of PRS requires an extra param to the DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS states from ZK. The implementation of such supplier `LazyPrsSupplier` would only fetch the state on first call. While this flow does work properly, this flow might introduce some unnecessary complexity: # PRS entry fetching from ZK is done either during or after the `DocCollection` construction, this could be a bit inconsistent with existing non PRS `DocCollection` design which `DocCollection` is simply a immutable container that does not fetch data after its instantiation # The lazy fetching could introduce some uncertainties as to when exactly the fetching happens (and if any Zookeeper IO exceptions arises) My guess was that the lazy loading was introduced in https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS states multiple times in the ctor of `DocCollection`, however, if we only fetch the `PerReplicaStates` once on update before calling the `DocCollection` ctor, and pass the `PerReplicaStates` object to the `DocCollection` instead, it can probably achieve similar result but with reduced uncertainty after `DocCollection` construction. > Simplify PerReplicaStates (PRS) logic in DocCollection, replace PrsSupplier > with actual PerReplicaStates param > -- > > Key: SOLR-16712 > URL: https://issues.apache.org/jira/browse/SOLR-16712 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: main (10.0), 9.1.1 >Reporter: Patson Luk >Priority: Major > > The current implementation of PRS requires an extra param to the > DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS > states from ZK. The implementation of such supplier `LazyPrsSupplier` would > only fetch the state on first call. > > While this flow does work properly, this flow might introduce some > unnecessary complexity: > # PRS entry fetching from ZK is done either during or after the > `DocCollection` construction, this could be a bit inconsistent with existing > non PRS `DocCollection` design which `DocCollection` is simply a immutable > container that does not fetch data after its instantiation > # The lazy fetching could introduce some uncertainties as to when exactly > the fetching happens (and if any Zookeeper IO exceptions arises) > > My guess was that the lazy loading was introduced in > https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS > states multiple times in the ctor of `DocCollection`, however, if we only > fetch the `PerReplicaStates` once on update before calling the > `DocCollection` ctor, and pass the `PerReplicaStates` object to the > `DocCollection` instead, it can probably achieve similar result but with > reduced uncertainty after `DocCollection` construction. > > There's another branch which experimented with making DocCollection, Slice > and Replica immutable as well for PRS enabled collect
[jira] [Resolved] (SOLR-16709) Use TimeUnit methods in conjunction with SolrClient builders
[ https://issues.apache.org/jira/browse/SOLR-16709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-16709. -- Fix Version/s: main (10.0) 9.3 Resolution: Fixed > Use TimeUnit methods in conjunction with SolrClient builders > > > Key: SOLR-16709 > URL: https://issues.apache.org/jira/browse/SOLR-16709 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.2 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > Fix For: main (10.0), 9.3 > > > Following up on SOLR-16595 where we introduced TimeUnit as a parameter on > many of the builder methods, we should switch Solr code over to using those > methods. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] patsonluk opened a new pull request, #1477: SOLR-16712: Simplify DocCollection ctor for PRS enabled collection
patsonluk opened a new pull request, #1477: URL: https://github.com/apache/solr/pull/1477 https://issues.apache.org/jira/browse/SOLR-16712 # Description The current implementation of PRS requires an extra param to the DocCollection, the `PrsSupplier`, when `get` is called, would fetch the PRS states from ZK. The implementation of such supplier `LazyPrsSupplier` would only fetch the state on first call. While this flow does work properly, this flow might introduce some unnecessary complexity: 1. PRS entry fetching from ZK is done either during or after the `DocCollection` construction, this could be a bit inconsistent with existing non PRS `DocCollection` design which `DocCollection` is simply a immutable container that does not fetch data after its instantiation 2. The lazy fetching could introduce some uncertainties as to when exactly the fetching happens (and if any Zookeeper IO exceptions arises) My guess was that the lazy loading was introduced in https://issues.apache.org/jira/browse/SOLR-16580 as to avoid fetching the PRS states multiple times in the ctor of `DocCollection`, however, if we only fetch the `PerReplicaStates` once on update before calling the `DocCollection` ctor, and pass the `PerReplicaStates` object to the `DocCollection` instead, it can probably achieve similar result but with reduced uncertainty after `DocCollection` construction. There's another branch which experimented with making DocCollection, Slice and Replica immutable as well for PRS enabled collection [https://github.com/cowpaths/fullstory-solr/pull/84] but is beyond the discussion of this Jira ticket # Solution Changed `DocCollector` last param from `PrsSupplier` to `PerReplicaStates`, which means in order to create a PRS enabled `DocCollection` , the `PerReplicaStates` object need to be provided upfront instead of getting fetched later on, which used to happen in `DocCollection ctor -> Slice#setPrsSupplier -> Slice#findLeader() -> Replica#isLeader() -> PrsSuppler#get` In order to minimize the impact, a new builder method `buildDocCollection` is added to `DocCollection` and accept the identical signature as the `DocCollection` before this change (which accepts `PrsSupplier`) Take note that `DocCollection#copyWith(PerReplicaStates)` has also been renamed to `DocCollection#setReplicaStates(PerReplicaStates)`, this is to better describes that such method simply set the `PerReplicaStates` but does not "copy" (ie creates new `DocCollection` instance). # Tests No new test cases are introduced, all the existing unit test cases should provide sufficient coverage # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [ ] 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] [Commented] (SOLR-16707) TestFiltering.testRandomFiltering Caffeine cache async=false IllegalStateException: Recursive update
[
https://issues.apache.org/jira/browse/SOLR-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702995#comment-17702995
]
Michael Gibney commented on SOLR-16707:
---
I think that happens externally, [in
SolrIndexSearcher|https://github.com/apache/solr/blob/bfccca2837e3f1625145454e75e2d602689f3781/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L958-L973].
I interpret the above snippet means "you can configure a cache {{async=true}},
but it won't actually be computed async if you have timeout enabled".
So iiuc this is not actually a reason to configure a cache {{async=false}} --
{{async=true}} caches can definitely have timeout enabled, it just won't be
particularly helpful in the way that one might hope {{async=true}} would be.
> TestFiltering.testRandomFiltering Caffeine cache async=false
> IllegalStateException: Recursive update
>
>
> Key: SOLR-16707
> URL: https://issues.apache.org/jira/browse/SOLR-16707
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> see the linked mail thread.
> There are systematic test failures with async=false.
> Why can't we just turn `async=true` for this test and others?
--
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-16707) TestFiltering.testRandomFiltering Caffeine cache async=false IllegalStateException: Recursive update
[ https://issues.apache.org/jira/browse/SOLR-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702997#comment-17702997 ] David Smiley commented on SOLR-16707: - I could imagine timeAllowed support being added for async. That needn't be a blocker for enabling this by default, though. > TestFiltering.testRandomFiltering Caffeine cache async=false > IllegalStateException: Recursive update > > > Key: SOLR-16707 > URL: https://issues.apache.org/jira/browse/SOLR-16707 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > > see the linked mail thread. > There are systematic test failures with async=false. > Why can't we just turn `async=true` for this test and others? -- 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
[GitHub] [solr] dsmiley commented on a diff in pull request #1256: SOLR-10466: setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
dsmiley commented on code in PR #1256:
URL: https://github.com/apache/solr/pull/1256#discussion_r1142859716
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudHttp2SolrClient.java:
##
@@ -332,6 +335,11 @@ public Builder withRetryExpiryTime(long expiryTime,
TimeUnit unit) {
return this;
}
+/** Sets the default collection for request. */
+public Builder withDefaultCollection(String collection) {
Review Comment:
(done)
--
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
