Re: [PR] Bump up Java version to 21 [solr]
dsmiley commented on PR #2682: URL: https://github.com/apache/solr/pull/2682#issuecomment-2400529478 Note that "api" module should also be Java Language 17, as it's included with SolrJ. -- 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-16286 : Topic stream not honoring initialCheckpoint in getPersis… [solr]
github-actions[bot] commented on PR #935: URL: https://github.com/apache/solr/pull/935#issuecomment-2401012717 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
Re: [PR] SOLR-16260: Add support for Instant, LocalDate and ZonedDateTime to JavaBinCodec [solr]
github-actions[bot] closed pull request #913: SOLR-16260: Add support for Instant, LocalDate and ZonedDateTime to JavaBinCodec URL: https://github.com/apache/solr/pull/913 -- 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-15476) Add ResponseBuilder.(newShardsInfo|addShardInfo) methods to facilitate 'shards.info' content customisation.
[
https://issues.apache.org/jira/browse/SOLR-15476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-15476:
--
Labels: pull-request-available (was: )
> Add ResponseBuilder.(newShardsInfo|addShardInfo) methods to facilitate
> 'shards.info' content customisation.
> ---
>
> Key: SOLR-15476
> URL: https://issues.apache.org/jira/browse/SOLR-15476
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13511 previously added a {{SearchHandler.newResponseBuilder}} method to
> facilitate custom plugins' maintenance of per-request state in a custom
> {{ResponseBuilder}}.
> The factoring out of two {{ResponseBuilder}} methods would support
> {{shards.info}} customisations such as returning of a list instead of a map
> container and/or removal or redaction of some {{shards.info}} elements.
--
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-16438) Shard split should be able to set preferred leaders on other replicas
[ https://issues.apache.org/jira/browse/SOLR-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-16438: Fix Version/s: (was: 9.2) > Shard split should be able to set preferred leaders on other replicas > - > > Key: SOLR-16438 > URL: https://issues.apache.org/jira/browse/SOLR-16438 > Project: Solr > Issue Type: Improvement >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently, shard split always create a first replica for each sub-shard on > the current host. Then it creates other replicas and their corresponding > sub-shards are in RECOVERY state. The effect is that the first replica (on > the current host) is always the leader, meaning that if the sub-shards are > split themselves, their sub-sub-shards leaders are also on the same host. > This can lead to very unbalanced situation where the same host is the leader > for a whole set of shards. > A solution to distribute evenly the leaders is to flag some other replicas > with the preferredLeader property during the split. Then a rebalance-leaders > command can elect the appropriate leaders. If we do that for each split, then > all the sub-shards have their leaders correctly balanced. > To go further, we can improve CollectionsHandler#CollectionOperation to > support combined operations. That way a CollectionOperation#SPLITSHARD_OP can > trigger a split op, then a wait for split completion op, and then a rebalance > leaders op. -- 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-15437: ReRanking/LTR does not work in combination with custom sort and SolrCloud [solr]
github-actions[bot] commented on PR #151: URL: https://github.com/apache/solr/pull/151#issuecomment-2401013006 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
[jira] [Updated] (SOLR-17462) Collection RESTORE: Invalid Status Request Error
[
https://issues.apache.org/jira/browse/SOLR-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-17462:
Summary: Collection RESTORE: Invalid Status Request Error (was: Invalid
Status Request Error During Restoration)
> Collection RESTORE: Invalid Status Request Error
> -
>
> Key: SOLR-17462
> URL: https://issues.apache.org/jira/browse/SOLR-17462
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 9.7, 9.6.1
>Reporter: Hakan Özler
>Priority: Major
> Attachments: logs.png
>
>
> We're unable to restore a S3 backup taken from 9.6.1 to 9.7.0. There are no
> helpful log messages from Solr during the restore apart from "Invalid status
> request for requestId: '168686616873218' - 'notfound'. Retried 6 times" .
> Interestingly, although we received this error message once, the data was
> successfully downloaded from S3. We even noticed this message "Successfully
> restored to the backup index" a couple of times. There is more; once we have
> the full data with the error message, the search completely failed, showing
> `Cannot invoke "java.util.Map.values()" because "rb.resultIds" is null`.
> However, we were able to retrieve the data using the `shards` parameter with
> all the shard names e.g. `shards=shard1,shard2,shard3,...,shardN`.
> {code:java}
> org.apache.solr.common.SolrException: Invalid status request for requestId:
> 'xx168686616873218' - 'notfound'. Retried 6 times
> at
> org.apache.solr.cloud.api.collections.CollectionHandlingUtils.waitForCoreAdminAsyncCallToComplete(CollectionHandlingUtils.java:549)
> at
> org.apache.solr.cloud.api.collections.CollectionHandlingUtils$ShardRequestTracker.waitForAsyncCallsToComplete(CollectionHandlingUtils.java:705)
> at
> org.apache.solr.cloud.api.collections.CollectionHandlingUtils$ShardRequestTracker.processResponses(CollectionHandlingUtils.java:694)
> at
> org.apache.solr.cloud.api.collections.CollectionHandlingUtils$ShardRequestTracker.processResponses(CollectionHandlingUtils.java:665)
> at
> org.apache.solr.cloud.api.collections.RestoreCmd.requestReplicasToRestore(RestoreCmd.java:139)
> at
> org.apache.solr.cloud.api.collections.RestoreCmd$RestoreOnANewCollection.process(RestoreCmd.java:298)
> at
> org.apache.solr.cloud.api.collections.RestoreCmd.call(RestoreCmd.java:109)
> at
> org.apache.solr.cloud.api.collections.CollApiCmds$TraceAwareCommand.call(CollApiCmds.java:225)
> at
> org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:130)
> at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:564)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$1(ExecutorUtil.java:449)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Unknown Source)
> {code}
> !logs.png|width=997,height=176!
> {code:java}
> java.lang.NullPointerException: Cannot invoke "java.util.Map.values()"
> because "rb.resultIds" is null
> at
> org.apache.solr.handler.component.QueryComponent.createRetrieveDocs(QueryComponent.java:1246)
> at
> org.apache.solr.handler.component.QueryComponent.regularDistributedProcess(QueryComponent.java:629)
> at
> org.apache.solr.handler.component.QueryComponent.distributedProcess(QueryComponent.java:578)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:508)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880)
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208)
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243)
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHan
Re: [PR] SOLR-16287 : MapStream - remap tuple value(s) [solr]
github-actions[bot] closed pull request #936: SOLR-16287 : MapStream - remap tuple value(s) URL: https://github.com/apache/solr/pull/936 -- 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-17485) Remove Slf4j ClassNotFoundException avoidance checks
David Smiley created SOLR-17485: --- Summary: Remove Slf4j ClassNotFoundException avoidance checks Key: SOLR-17485 URL: https://issues.apache.org/jira/browse/SOLR-17485 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: David Smiley If a user removes logging libs from lib/ext, they are on their own, more or less. CheckLoggingConfiguration (SOLR-5951) tries to detect an early ClassNotFoundException and prints a more helpful error. IMO we're doing too much; a CNFE is clear enough, and furthermore Slf4j will print an explicit ERROR as well right before (what happens if we remove it; I tried). I suspect it came out when Solr still supported a WAR or maybe was less clear what the error was back then. And I suspect it hasn't worked since we added a ServletContextListener for CoreContainerProvider. While it could be remedied, I'd rather remove the old 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-6122) API to cancel an already submitted/running Collections API call
[ https://issues.apache.org/jira/browse/SOLR-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887753#comment-17887753 ] David Smiley commented on SOLR-6122: I see this is for "submitted not started". Coincidentally at work (Salesforce) we have an Overseer customization but it's scoped to a synchronous use-case and only when the caller has gone/vanished. Any way, for async, I think this is simpler. DELETESTATUS is documented to only succeed for completed tasks. But I could imagine adding a parameter to cancel a not-started status. Can you look into this? I suppose this might be viewed as very similar to your listed Approach #2. Honestly I don't think your listed "Cons" for it is a is a big concern. To make it a little better, you could put the relevant logic for the details of that in OverseerTaskProcessor or other similar place close to the queue logic and not in the command you will write. BTW I really appreciate your open development process here, even if it takes longer. It's good to solicit early feedback from others who have been in and out of this code a lot. Often times I see a PR before a discussion of the approach :-/ > API to cancel an already submitted/running Collections API call > --- > > Key: SOLR-6122 > URL: https://issues.apache.org/jira/browse/SOLR-6122 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Reporter: Anshum Gupta >Priority: Major > > Right now we can trigger a long running task with no way to cancel it > cleanly. > We should have an API that interrupts the already running/submitted > collections API call. -- 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-17449) bboxField subfield Error in atomic updating
[
https://issues.apache.org/jira/browse/SOLR-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887771#comment-17887771
]
Seunghan Jung commented on SOLR-17449:
--
This is an example where the error I mentioned occurs.
I indexed the bbox field and a general text field (text_en) as follows:
{code:java}
{
"responseHeader":{
"zkConnected":true,
"status":0,
"QTime":0,
"params":{
"q":"*:*",
"indent":"true",
"q.op":"OR",
"useParams":"",
"_":"1728450525945"
}
},
"response":{
"numFound":1,
"start":0,
"numFoundExact":true,
"docs":[{
"id":"1",
"text_en":"This is bbox field bug example",
"bbox":"ENVELOPE(-10, 10, 20, -20)",
"bbox__maxX":10.0,
"_version_":1812411633878695936,
"bbox__maxY":20.0,
"bbox__minX":-10.0,
"bbox__minY":-20.0
}]
}
} {code}
The schema status is as follows:
{code:java}
{code}
To preserve the bbox field value during an atomic update, stored="true" is
required.
At this point, I try an atomic update on text_en as follows:
{code:java}
{
"id": "1",
"text_en": {"set": "Error happens!"}
}{code}
However, the following error occurs, and the atomic update fails:
{code:java}
Exception writing document id 1 to the index; possible analysis error:
DocValuesField "bbox__maxX" appears more than once in this document (only one
value is allowed per field){code}
> bboxField subfield Error in atomic updating
> ---
>
> Key: SOLR-17449
> URL: https://issues.apache.org/jira/browse/SOLR-17449
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: main (10.0)
>Reporter: Seunghan Jung
>Priority: Minor
> Attachments: image-2024-09-13-17-45-17-161.png
>
>
> For fields of type `bboxField`, derived fields such as `minX`, `maxX`,
> `minY`, `maxY`, etc., are added to the schema and indexed.
> However, this causes issues during atomic updates. During an atomic update,
> when a new document is moved and indexed, the fields of type `bboxField` are
> re-indexed with `minX`, `maxX`, `minY`, `maxY` just as they were initially.
> Since the original document already contains these fields, they are indexed
> again in the new document. However, because they are already indexed by the
> `bbox` field, this results in duplicate indexing. If the `numberType`
> attribute of the bbox field type has `docValues=true`, an error occurs due to
> the docValues being written twice.
> Here is the error message for this case:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: DocValuesField "bbox__maxX"
> appears more than once in this document (only one value is allowed per field)
> at
> org.apache.lucene.index.NumericDocValuesWriter.addValue(NumericDocValuesWriter.java:53)
> ~[?:?]
> at
> org.apache.lucene.index.IndexingChain.indexDocValue(IndexingChain.java:937)
> ~[?:?]
> at
> org.apache.lucene.index.IndexingChain.processField(IndexingChain.java:723)
> ~[?:?]
> at
> org.apache.lucene.index.IndexingChain.processDocument(IndexingChain.java:576)
> ~[?:?]
> at
> org.apache.lucene.index.DocumentsWriterPerThread.updateDocuments(DocumentsWriterPerThread.java:242)
> ~[?:?]
> at
> org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:432)
> ~[?:?]
> at
> org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1545)
> ~[?:?]
> at
> org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1521)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.updateDocOrDocValues(DirectUpdateHandler2.java:1062)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:421)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:374)
> ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:311)
> ~[?:?]{code}
>
> Of course, setting the docValues="false" for the field type used in
> numberType resolves the issue.
> However, this is not explained in the[ Solr Reference
> Guide|https://solr.apache.org/guide/solr/latest/query-guide/spatial-search.html#bboxfield].
> Instead, the example schema shows docValues="true", which makes it seem like
> this is how it should be configured.
> !image-2024-09-13-17-45-17-161.png|width=1037,height=233!
--
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-16645) Support ss and netstat as alternatives to lsof
[
https://issues.apache.org/jira/browse/SOLR-16645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887720#comment-17887720
]
Jan Høydahl commented on SOLR-16645:
The only place lsof is used is check if solr is running on a certain port. That
can probably achieved in pure java with status toolafter SOLR-17450 is done.
> Support ss and netstat as alternatives to lsof
> --
>
> Key: SOLR-16645
> URL: https://issues.apache.org/jira/browse/SOLR-16645
> Project: Solr
> Issue Type: Improvement
>Reporter: Colvin Cowie
>Priority: Trivial
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The current start command requires {{lsof}} to be available. If you don't
> have {{lsof}} it does a hardcoded 10 second wait and then assumes the process
> has started.
> There are several other tools common tools that can be used if lsof` isn't
> available, so I'll create a PR to add netstat and ss as alternative options.
--
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-15476: Facilitate 'shards.info' content customisation. [solr]
github-actions[bot] closed pull request #176: SOLR-15476: Facilitate 'shards.info' content customisation. URL: https://github.com/apache/solr/pull/176 -- 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-15437: ReRanking/LTR does not work in combination with custom sort and SolrCloud [solr]
github-actions[bot] closed pull request #151: SOLR-15437: ReRanking/LTR does not work in combination with custom sort and SolrCloud URL: https://github.com/apache/solr/pull/151 -- 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-16292 : NVector for alternative great-circle distance calculations [solr]
github-actions[bot] closed pull request #940: SOLR-16292 : NVector for alternative great-circle distance calculations URL: https://github.com/apache/solr/pull/940 -- 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-16292 : NVector for alternative great-circle distance calculations [solr]
github-actions[bot] commented on PR #940: URL: https://github.com/apache/solr/pull/940#issuecomment-2401012606 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
Re: [PR] SOLR-16243: Compile SQL to a Streaming Expression while visiting the … [solr]
github-actions[bot] commented on PR #899: URL: https://github.com/apache/solr/pull/899#issuecomment-2401012786 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
[jira] [Updated] (SOLR-16291) Decay function queries gauss,linear,exponential
[
https://issues.apache.org/jira/browse/SOLR-16291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-16291:
--
Labels: pull-request-available (was: )
> Decay function queries gauss,linear,exponential
> ---
>
> Key: SOLR-16291
> URL: https://issues.apache.org/jira/browse/SOLR-16291
> Project: Solr
> Issue Type: Improvement
> Components: query parsers, search
>Affects Versions: 9.0
>Reporter: Dan Rosher
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h2. Description
> This is a Solr version of the Decay functions [available in
> Elasticsearch|[https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html|https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html#function-decay]
> ]
> To see how the functions work [see
> here|https://www.desmos.com/calculator/a7i0bwz5ha]
> Decay functions score a document with a function that decays depending on the
> distance of a numeric field value of the document from a user given origin.
> This is similar to a range query, but with smooth edges instead of boxes.
> To use distance scoring on a query that has numerical fields, the user has to
> define an origin and a scale for each field. The origin is needed to define
> the “central point” from which the distance is calculated, and the scale to
> define the rate of decay. The decay function is specified as
>
> {code:java}
> (,scale,origin,offset,decay) for numerical/date
> field
> (,scale,origin_lat,origin_lon,offset,decay) for
> geo fields {code}
> * should be one of 'linear', 'exp', or 'gauss'
> * The must be a NumericFieldType, DatePointField, or
> LatLonPointSpatialField field, NOT multi-valued. e.g.
> linear("location","23km",52.0247, -0.490,"0km",0.5)
> In the above example, the field is a geo_point and origin can be provided in
> geo format. scale and offset must be given with a unit in this case. If your
> field is a date field, you can set scale and offset as days, hours, as with
> DateMath.
>
> e.g. gauss(pdate,"+2DAY+6HOUR","2021-07-20T00:00:00Z","+3DAY",0.5)
>
> pdate: DatePointField "+2DAY+6HOUR": range "2021-07-20T00:00:00Z: origin
> (defaults to NOW) "+3DAY: offset (defaults to zero) 0.5: decay{*}{{*}}
>
> * *origin* The point of origin used for calculating distance. Must be given
> as a number for numeric field, date for date fields and geo point for geo
> fields. Required for geo and numeric field. For date fields the default is
> NOW. Date math (for example NOW-1h) is supported for origin.
> * *scale* Required for all types. Defines the distance from origin + offset
> at which the computed score will equal decay parameter. For geo fields: Can
> be defined as number+unit (1km, 12m,...). Default unit is KM. For date
> fields: Can to be defined as a number+unit ("1h", "10d",…). For numeric
> field: Any number.
> * *offset* If an offset is defined, the decay function will only compute the
> decay function for documents with a distance greater than the defined offset.
> The default is 0.
> * *decay* The decay parameter defines how documents are scored at the
> distance given at scale. If no decay is defined, documents at the distance
> scale will be scored 0.5.
>
> To get a feel for how these function work you can see [here on
> desmos|https://www.desmos.com/calculator/a7i0bwz5ha] . Adjust origin, offset,
> scale and decay to get a feel of how these parameters adjust the equation for
> gauss, exp or linear.
> h3. Supported decay functions
>
> The DECAY_FUNCTION determines the shape of the decay:
> *gauss* Normal decay, computed as:
> score(doc) = exp(- (max(0,|doc.val - origin| - offset)^2)/2sig^2)
> where sig is computed to assure that the score takes the value decay at
> distance scale from origin+-offset
> sig^2 = -scale^2/(2.ln(decay))
> *exp* Exponential decay, computed as:
> score(doc) = exp(lmda . max(0,|doc.val - origin| - offset))
> lmda = ln(decay)/scale
> where again the parameter lambda is computed to assure that the score takes
> the value decay at distance scale from origin+-offset
> *linear* Linear decay, computed as:
> score(doc) = max((s-v)/s,0)
> where: v = max(0,|doc.val - origin| - offset) s = scale(1.0-decay))
> where again the parameter s is computed to assure that the score takes the
> value decay at distance scale from origin+-offset
> In contrast to the normal and exponential decay, this function actually sets
> the score to 0 if the field value exceeds twice the user given scale value.
> For single functions the three decay functions together with their parameters
> can be visualized like this (the field in this example called "age"):
> h3. Detailed examp
[jira] [Updated] (SOLR-16292) NVector for alternative great-circle distance calculations
[ https://issues.apache.org/jira/browse/SOLR-16292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16292: -- Labels: pull-request-available (was: ) > NVector for alternative great-circle distance calculations > -- > > Key: SOLR-16292 > URL: https://issues.apache.org/jira/browse/SOLR-16292 > Project: Solr > Issue Type: Improvement > Components: search, spatial >Affects Versions: 9.0 >Reporter: Dan Rosher >Priority: Minor > Labels: pull-request-available > Time Spent: 4h 40m > Remaining Estimate: 0h > > [N-Vector|https://en.wikipedia.org/wiki/N-vector#Example:_Great_circle_distance] > is a three-parameter representation that can be used to calculate the > great-circle distance (assuming a spherical Earth). > This implementation makes use of fast implementation of acos I wrote, that > approximates acos with a maclaurin series expansion. > For small distances it compares well with Math.acos, and is a faster way of > calculating the great-circle distance than Haversine. > > > -- 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-17444) Add Passage Sorting Option in UnifiedSolrHighlighter
[ https://issues.apache.org/jira/browse/SOLR-17444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seunghan Jung updated SOLR-17444: - Affects Version/s: main (10.0) (was: 9.6.2) > Add Passage Sorting Option in UnifiedSolrHighlighter > > > Key: SOLR-17444 > URL: https://issues.apache.org/jira/browse/SOLR-17444 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: main (10.0) >Reporter: Seunghan Jung >Priority: Minor > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > We will add the passageSortComparator option, introduced in the > UnifiedHighlighter in the Lucene 9.11 project, to the Solr highlighter > parameters, enabling its functionality within Solr. > For reference, here is the related Lucene project commit: > https://github.com/apache/lucene/commit/8773725ac0f15962b39bcc1f6fc5fb331b7a6d62 > -- 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-16286 : Topic stream not honoring initialCheckpoint in getPersis… [solr]
github-actions[bot] closed pull request #935: SOLR-16286 : Topic stream not honoring initialCheckpoint in getPersis… URL: https://github.com/apache/solr/pull/935 -- 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-16287 : MapStream - remap tuple value(s) [solr]
github-actions[bot] commented on PR #936: URL: https://github.com/apache/solr/pull/936#issuecomment-2401012693 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
[jira] [Updated] (SOLR-16438) Shard split should be able to set preferred leaders on other replicas
[ https://issues.apache.org/jira/browse/SOLR-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-16438: Status: Reopened (was: Closed) > Shard split should be able to set preferred leaders on other replicas > - > > Key: SOLR-16438 > URL: https://issues.apache.org/jira/browse/SOLR-16438 > Project: Solr > Issue Type: Improvement >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently, shard split always create a first replica for each sub-shard on > the current host. Then it creates other replicas and their corresponding > sub-shards are in RECOVERY state. The effect is that the first replica (on > the current host) is always the leader, meaning that if the sub-shards are > split themselves, their sub-sub-shards leaders are also on the same host. > This can lead to very unbalanced situation where the same host is the leader > for a whole set of shards. > A solution to distribute evenly the leaders is to flag some other replicas > with the preferredLeader property during the split. Then a rebalance-leaders > command can elect the appropriate leaders. If we do that for each split, then > all the sub-shards have their leaders correctly balanced. > To go further, we can improve CollectionsHandler#CollectionOperation to > support combined operations. That way a CollectionOperation#SPLITSHARD_OP can > trigger a split op, then a wait for split completion op, and then a rebalance > leaders op. -- 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-16556) Solr stream expression: Implement Page Streaming Decorator to allow results to be displayed with pagination.
[ https://issues.apache.org/jira/browse/SOLR-16556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887586#comment-17887586 ] Eric Pugh commented on SOLR-16556: -- I am going back through old stale PR's that got autoclosed, and if you are still interested in this one and getting the renaming done, then I htink we can finally get this one merged!!! > Solr stream expression: Implement Page Streaming Decorator to allow results > to be displayed with pagination. > > > Key: SOLR-16556 > URL: https://issues.apache.org/jira/browse/SOLR-16556 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Reporter: Maulin >Assignee: Eric Pugh >Priority: Major > Labels: Streamingexpression, decorator, paging > Attachments: Page Decorator Performance Reading.xlsx > > Time Spent: 10m > Remaining Estimate: 0h > > Solr stream expression: Implement Page Streaming Decorator to allow results > to be displayed with pagination. -- 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-16556) Solr stream expression: Implement Page Streaming Decorator to allow results to be displayed with pagination.
[ https://issues.apache.org/jira/browse/SOLR-16556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-16556: Assignee: Eric Pugh > Solr stream expression: Implement Page Streaming Decorator to allow results > to be displayed with pagination. > > > Key: SOLR-16556 > URL: https://issues.apache.org/jira/browse/SOLR-16556 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Reporter: Maulin >Assignee: Eric Pugh >Priority: Major > Labels: Streamingexpression, decorator, paging > Attachments: Page Decorator Performance Reading.xlsx > > Time Spent: 10m > Remaining Estimate: 0h > > Solr stream expression: Implement Page Streaming Decorator to allow results > to be displayed with pagination. -- 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-16556) Solr stream expression: Implement Page Streaming Decorator to allow results to be displayed with pagination.
[ https://issues.apache.org/jira/browse/SOLR-16556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-16556: Assignee: (was: Eric Pugh) > Solr stream expression: Implement Page Streaming Decorator to allow results > to be displayed with pagination. > > > Key: SOLR-16556 > URL: https://issues.apache.org/jira/browse/SOLR-16556 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Reporter: Maulin >Priority: Major > Labels: Streamingexpression, decorator, paging > Attachments: Page Decorator Performance Reading.xlsx > > Time Spent: 10m > Remaining Estimate: 0h > > Solr stream expression: Implement Page Streaming Decorator to allow results > to be displayed with pagination. -- 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-17482: Change long form of -r to --recursive [solr]
epugh merged PR #2746: URL: https://github.com/apache/solr/pull/2746 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17470) CLI: Resolve -s flag conflicts
[ https://issues.apache.org/jira/browse/SOLR-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17470. -- Fix Version/s: 9.8 Resolution: Fixed > CLI: Resolve -s flag conflicts > -- > > Key: SOLR-17470 > URL: https://issues.apache.org/jira/browse/SOLR-17470 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: 9.7, 9x >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, migration > Fix For: 9.8 > > > The -s flag was previously used in many CLI options. Some conflicts were > resolved in 9.7, others in main (10.0), and some are still unresolved. For > this reason, this ticket focuses on adding the necessary deprecation warnings > and removals for the remaining cases. > -s is currently used for: > * -"scheme" in ConfigTool- (see SOLR-17459) > * "shards" in CreateTool (only in 9.7, 9x and main use -sh instead of -s) > * "solr url" in bin/solr and bin/solr.cmd > * "solr home" in ZkCLI (9.7 and 9x), bin/solr and bin/solr.cmd > * "scrape interval" in SolrExporter > * "started" in AssertTool > * "not-started" (-S uppercase here) in AssertTool > * "script" in RunExampleTool > * "service name" in install_solr_service.sh > h4. Proposed Conflict Resolution > Fix in branch_9_7 (9.7.1) -s for shards by replacing it with -sh in > CreateTool. Previous changes from SOLR-17359 / #2593 mistakenly introduced -s > for "shards", causing new conflicts that were resolved in branch_9x and main > but not any possible patch-releases of 9.7 (branch_9_7). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "script" in RunExampleTool > to avoid confusion with -s for "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -s for "service name" in > install_solr_service.sh by replacing it with --service. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "solr home" in bin/solr, > bin/solr.cmd and ZKCLI (only present in 9x releases) to avoid confusion with > solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -url (that violates the > single-letter naming convention for flags) by replacing it with -s for > "solr-url" in SolrCLI, so that the help output from Zk*Tool and other tools > are correct (see notes below). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "scrape-interval" in > SolrExporter in favor to further migrations of solr url params and to avoid > confusions wiht solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "started" in AssertTool. A > future proposal may include a full rewrite of AssertTool, but for now we will > deprecate -s in favor to "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -S (cap) for "not-started" in > AssertTool. A future proposal may include a full rewrite of AssertTool, but > for now we will deprecate -S in favor to "solr-url" and because > case-sensitivity is avoided. > h4. Additional Notes > Zookeeper CLI classes (Zk*Tool) are mentioning in their help output "-s > " for providing solr-url but the solr-url options support only -url and > --solr-url (and other variants) as options, but not -s. This is partly a typo > / bug that should be fixed. -- 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-17480) CLI: Merge solr-data with data-home and resolve -t
[
https://issues.apache.org/jira/browse/SOLR-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17480:
--
Labels: cli pull-request-available (was: cli)
> CLI: Merge solr-data with data-home and resolve -t
> --
>
> Key: SOLR-17480
> URL: https://issues.apache.org/jira/browse/SOLR-17480
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.7, 9.6.1
>Reporter: Christos Malliaridis
>Assignee: Eric Pugh
>Priority: Major
> Labels: cli, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The environment variable {{solr.data.home}} is set in {{bin/solr}} (Unix) via
> {{\-\-data-home}} and in {{bin/solr.cmd}} (Windows) via {{\-\-solr-data}}.
> This is an inconsistency and should be resolved by deprecating either option
> and go with only the extended name to avoid conflicts with single-letter name
> {{t}} (currently used for {{type}}).
> For this reason, the following changes are proposed:
> - deprecate (9.x) and remove (10.0) the option {{\-\-solr-data}}/{{\-t}} by
> replacing it with {{\-\-data-home}}
> - deprecate (9.x) and remove (10.0) the option name {{\-t}} that is used for
> {{\-\-data-home}}
--
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-17480) CLI: Merge solr-data with data-home and resolve -t
[
https://issues.apache.org/jira/browse/SOLR-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887653#comment-17887653
]
ASF subversion and git services commented on SOLR-17480:
Commit f5b012912aa9313c801d20835a1de05e0407a6b1 in solr's branch
refs/heads/main from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f5b012912aa ]
SOLR-17480: Use --data-home everywhere (#2747)
> CLI: Merge solr-data with data-home and resolve -t
> --
>
> Key: SOLR-17480
> URL: https://issues.apache.org/jira/browse/SOLR-17480
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.7, 9.6.1
>Reporter: Christos Malliaridis
>Assignee: Eric Pugh
>Priority: Major
> Labels: cli, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The environment variable {{solr.data.home}} is set in {{bin/solr}} (Unix) via
> {{\-\-data-home}} and in {{bin/solr.cmd}} (Windows) via {{\-\-solr-data}}.
> This is an inconsistency and should be resolved by deprecating either option
> and go with only the extended name to avoid conflicts with single-letter name
> {{t}} (currently used for {{type}}).
> For this reason, the following changes are proposed:
> - deprecate (9.x) and remove (10.0) the option {{\-\-solr-data}}/{{\-t}} by
> replacing it with {{\-\-data-home}}
> - deprecate (9.x) and remove (10.0) the option name {{\-t}} that is used for
> {{\-\-data-home}}
--
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-17480) CLI: Merge solr-data with data-home and resolve -t
[
https://issues.apache.org/jira/browse/SOLR-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887655#comment-17887655
]
ASF subversion and git services commented on SOLR-17480:
Commit 9ef97f95a222ee6dd24352fa428f84e008bd2913 in solr's branch
refs/heads/branch_9x from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=9ef97f95a22 ]
SOLR-17480: Use --data-home everywhere (#2747)
> CLI: Merge solr-data with data-home and resolve -t
> --
>
> Key: SOLR-17480
> URL: https://issues.apache.org/jira/browse/SOLR-17480
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.7, 9.6.1
>Reporter: Christos Malliaridis
>Assignee: Eric Pugh
>Priority: Major
> Labels: cli, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The environment variable {{solr.data.home}} is set in {{bin/solr}} (Unix) via
> {{\-\-data-home}} and in {{bin/solr.cmd}} (Windows) via {{\-\-solr-data}}.
> This is an inconsistency and should be resolved by deprecating either option
> and go with only the extended name to avoid conflicts with single-letter name
> {{t}} (currently used for {{type}}).
> For this reason, the following changes are proposed:
> - deprecate (9.x) and remove (10.0) the option {{\-\-solr-data}}/{{\-t}} by
> replacing it with {{\-\-data-home}}
> - deprecate (9.x) and remove (10.0) the option name {{\-t}} that is used for
> {{\-\-data-home}}
--
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-17480: Use --data-home everywhere [solr]
epugh merged PR #2747: URL: https://github.com/apache/solr/pull/2747 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17480) CLI: Merge solr-data with data-home and resolve -t
[
https://issues.apache.org/jira/browse/SOLR-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17480.
--
Fix Version/s: 9.8
Resolution: Fixed
> CLI: Merge solr-data with data-home and resolve -t
> --
>
> Key: SOLR-17480
> URL: https://issues.apache.org/jira/browse/SOLR-17480
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.7, 9.6.1
>Reporter: Christos Malliaridis
>Assignee: Eric Pugh
>Priority: Major
> Labels: cli, pull-request-available
> Fix For: 9.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The environment variable {{solr.data.home}} is set in {{bin/solr}} (Unix) via
> {{\-\-data-home}} and in {{bin/solr.cmd}} (Windows) via {{\-\-solr-data}}.
> This is an inconsistency and should be resolved by deprecating either option
> and go with only the extended name to avoid conflicts with single-letter name
> {{t}} (currently used for {{type}}).
> For this reason, the following changes are proposed:
> - deprecate (9.x) and remove (10.0) the option {{\-\-solr-data}}/{{\-t}} by
> replacing it with {{\-\-data-home}}
> - deprecate (9.x) and remove (10.0) the option name {{\-t}} that is used for
> {{\-\-data-home}}
--
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-16503) Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
[
https://issues.apache.org/jira/browse/SOLR-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887544#comment-17887544
]
ASF subversion and git services commented on SOLR-16503:
Commit 47c4aae0375f6edf82d608147a9d04acf4f42faa in solr's branch
refs/heads/main from Sanjay Dutt
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=47c4aae0375 ]
SOLR-16503: New home for default http2 client (#2689)
* Introduced `HttpSolrClientProvider` as the new provider for `Http2SolrClient`.
* `UpdateShardHandler#getDefaultHttpClient` has been marked deprecated.
* Updated `IOUtils.closeQuietly` to accept `AutoCloseable` instead of
`Closeable`, enhancing its flexibility.
-
Co-authored-by: David Smiley
> Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
> -
>
> Key: SOLR-16503
> URL: https://issues.apache.org/jira/browse/SOLR-16503
> Project: Solr
> Issue Type: Sub-task
>Reporter: David Smiley
>Priority: Major
> Labels: pull-request-available
> Attachments: Screenshot 2024-03-16 at 9.14.36 PM.png
>
> Time Spent: 10h 50m
> Remaining Estimate: 0h
>
> Much of Solr's remaining uses of Apache HttpClient (HTTP 1) is due to
> {{org.apache.solr.update.UpdateShardHandler#getDefaultHttpClient}} which
> underlies most Solr-to-Solr connectivity. This also underlies the
> {{{}CoreContainer.getSolrClientCache{}}}. Lets switch to Jetty (HTTP 2).
>
> In SolrClientCache in particular:
> Switch use of CloudLegacySolrClient.Builder to CloudSolrClient.Builder
> Switch use of HttpSolrClient.Builder to Http2SolrClient.Builder
> Undeprecate all the methods here. They should not have been deprecated in
> the first place.
> The constructor: switch from Apache HttpClient to a Jetty HttpClient.
--
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-17482) CLI: Merge --recurse with --recursive
[ https://issues.apache.org/jira/browse/SOLR-17482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17482: -- Labels: cli pull-request-available (was: cli) > CLI: Merge --recurse with --recursive > - > > Key: SOLR-17482 > URL: https://issues.apache.org/jira/browse/SOLR-17482 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: 9.7, 9.6.1 >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We are currently using --recurse and --resursive, introducing unnecessary > differences in flags that serve "recursive" actions. > To avoid potential user mistakes, we should merge both options into one and > use only recursive. > Deprecate (9.x) and remove (10.0) --recurse as an option and use > --recursive/-r instead. -- 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-17482) CLI: Merge --recurse with --recursive
[ https://issues.apache.org/jira/browse/SOLR-17482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887617#comment-17887617 ] ASF subversion and git services commented on SOLR-17482: Commit a9817c9aadeacf7781bc3ca9945e565ab8ee4bb8 in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=a9817c9aade ] SOLR-17482: Change long form of -r to --recursive (#2746) Use --recursive instead of --recurse to be consistent. > CLI: Merge --recurse with --recursive > - > > Key: SOLR-17482 > URL: https://issues.apache.org/jira/browse/SOLR-17482 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: 9.7, 9.6.1 >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We are currently using --recurse and --resursive, introducing unnecessary > differences in flags that serve "recursive" actions. > To avoid potential user mistakes, we should merge both options into one and > use only recursive. > Deprecate (9.x) and remove (10.0) --recurse as an option and use > --recursive/-r instead. -- 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-17470) CLI: Resolve -s flag conflicts
[ https://issues.apache.org/jira/browse/SOLR-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887605#comment-17887605 ] ASF subversion and git services commented on SOLR-17470: Commit 69256c39f2beaba3b480a446d46b634dc0e1f8d8 in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=69256c39f2b ] Fix backport of SOLR-17470 > CLI: Resolve -s flag conflicts > -- > > Key: SOLR-17470 > URL: https://issues.apache.org/jira/browse/SOLR-17470 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: 9.7, 9x >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, migration > > The -s flag was previously used in many CLI options. Some conflicts were > resolved in 9.7, others in main (10.0), and some are still unresolved. For > this reason, this ticket focuses on adding the necessary deprecation warnings > and removals for the remaining cases. > -s is currently used for: > * -"scheme" in ConfigTool- (see SOLR-17459) > * "shards" in CreateTool (only in 9.7, 9x and main use -sh instead of -s) > * "solr url" in bin/solr and bin/solr.cmd > * "solr home" in ZkCLI (9.7 and 9x), bin/solr and bin/solr.cmd > * "scrape interval" in SolrExporter > * "started" in AssertTool > * "not-started" (-S uppercase here) in AssertTool > * "script" in RunExampleTool > * "service name" in install_solr_service.sh > h4. Proposed Conflict Resolution > Fix in branch_9_7 (9.7.1) -s for shards by replacing it with -sh in > CreateTool. Previous changes from SOLR-17359 / #2593 mistakenly introduced -s > for "shards", causing new conflicts that were resolved in branch_9x and main > but not any possible patch-releases of 9.7 (branch_9_7). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "script" in RunExampleTool > to avoid confusion with -s for "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -s for "service name" in > install_solr_service.sh by replacing it with --service. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "solr home" in bin/solr, > bin/solr.cmd and ZKCLI (only present in 9x releases) to avoid confusion with > solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -url (that violates the > single-letter naming convention for flags) by replacing it with -s for > "solr-url" in SolrCLI, so that the help output from Zk*Tool and other tools > are correct (see notes below). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "scrape-interval" in > SolrExporter in favor to further migrations of solr url params and to avoid > confusions wiht solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "started" in AssertTool. A > future proposal may include a full rewrite of AssertTool, but for now we will > deprecate -s in favor to "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -S (cap) for "not-started" in > AssertTool. A future proposal may include a full rewrite of AssertTool, but > for now we will deprecate -S in favor to "solr-url" and because > case-sensitivity is avoided. > h4. Additional Notes > Zookeeper CLI classes (Zk*Tool) are mentioning in their help output "-s > " for providing solr-url but the solr-url options support only -url and > --solr-url (and other variants) as options, but not -s. This is partly a typo > / bug that should be fixed. -- 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-17470) CLI: Resolve -s flag conflicts
[ https://issues.apache.org/jira/browse/SOLR-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887604#comment-17887604 ] ASF subversion and git services commented on SOLR-17470: Commit 9a7eca896a24a7927718f83dc06594c277689288 in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=9a7eca896a2 ] SOLR-17470: CLI resolve -s (#2743) The -s parameter now only means "provide a solr url" through out all of our most widely used Solr CLI scripts. - Co-authored-by: Christos Malliaridis (cherry picked from commit 8d7edeb335c0e00ccc52d55ca421df6062195bc5) > CLI: Resolve -s flag conflicts > -- > > Key: SOLR-17470 > URL: https://issues.apache.org/jira/browse/SOLR-17470 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: 9.7, 9x >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, migration > > The -s flag was previously used in many CLI options. Some conflicts were > resolved in 9.7, others in main (10.0), and some are still unresolved. For > this reason, this ticket focuses on adding the necessary deprecation warnings > and removals for the remaining cases. > -s is currently used for: > * -"scheme" in ConfigTool- (see SOLR-17459) > * "shards" in CreateTool (only in 9.7, 9x and main use -sh instead of -s) > * "solr url" in bin/solr and bin/solr.cmd > * "solr home" in ZkCLI (9.7 and 9x), bin/solr and bin/solr.cmd > * "scrape interval" in SolrExporter > * "started" in AssertTool > * "not-started" (-S uppercase here) in AssertTool > * "script" in RunExampleTool > * "service name" in install_solr_service.sh > h4. Proposed Conflict Resolution > Fix in branch_9_7 (9.7.1) -s for shards by replacing it with -sh in > CreateTool. Previous changes from SOLR-17359 / #2593 mistakenly introduced -s > for "shards", causing new conflicts that were resolved in branch_9x and main > but not any possible patch-releases of 9.7 (branch_9_7). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "script" in RunExampleTool > to avoid confusion with -s for "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -s for "service name" in > install_solr_service.sh by replacing it with --service. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "solr home" in bin/solr, > bin/solr.cmd and ZKCLI (only present in 9x releases) to avoid confusion with > solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -url (that violates the > single-letter naming convention for flags) by replacing it with -s for > "solr-url" in SolrCLI, so that the help output from Zk*Tool and other tools > are correct (see notes below). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "scrape-interval" in > SolrExporter in favor to further migrations of solr url params and to avoid > confusions wiht solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "started" in AssertTool. A > future proposal may include a full rewrite of AssertTool, but for now we will > deprecate -s in favor to "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -S (cap) for "not-started" in > AssertTool. A future proposal may include a full rewrite of AssertTool, but > for now we will deprecate -S in favor to "solr-url" and because > case-sensitivity is avoided. > h4. Additional Notes > Zookeeper CLI classes (Zk*Tool) are mentioning in their help output "-s > " for providing solr-url but the solr-url options support only -url and > --solr-url (and other variants) as options, but not -s. This is partly a typo > / bug that should be fixed. -- 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-16645) Support ss and netstat as alternatives to lsof
[
https://issues.apache.org/jira/browse/SOLR-16645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-16645.
--
Resolution: Abandoned
There is a PR out there but it's fallen victim to the bike shed ;). Please do
reopen this ticket if it's somethign we want to do, and let's summon up some
energy to get it done.
I really want the CLI stuff to pretty much "in a good place" before Solr 10 ;).
> Support ss and netstat as alternatives to lsof
> --
>
> Key: SOLR-16645
> URL: https://issues.apache.org/jira/browse/SOLR-16645
> Project: Solr
> Issue Type: Improvement
>Reporter: Colvin Cowie
>Priority: Trivial
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The current start command requires {{lsof}} to be available. If you don't
> have {{lsof}} it does a hardcoded 10 second wait and then assumes the process
> has started.
> There are several other tools common tools that can be used if lsof` isn't
> available, so I'll create a PR to add netstat and ss as alternative options.
--
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-17470) CLI: Resolve -s flag conflicts
[ https://issues.apache.org/jira/browse/SOLR-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887595#comment-17887595 ] ASF subversion and git services commented on SOLR-17470: Commit 8d7edeb335c0e00ccc52d55ca421df6062195bc5 in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=8d7edeb335c ] SOLR-17470: CLI resolve -s (#2743) The -s parameter now only means "provide a solr url" through out all of our most widely used Solr CLI scripts. - Co-authored-by: Christos Malliaridis > CLI: Resolve -s flag conflicts > -- > > Key: SOLR-17470 > URL: https://issues.apache.org/jira/browse/SOLR-17470 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: 9.7, 9x >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, migration > > The -s flag was previously used in many CLI options. Some conflicts were > resolved in 9.7, others in main (10.0), and some are still unresolved. For > this reason, this ticket focuses on adding the necessary deprecation warnings > and removals for the remaining cases. > -s is currently used for: > * -"scheme" in ConfigTool- (see SOLR-17459) > * "shards" in CreateTool (only in 9.7, 9x and main use -sh instead of -s) > * "solr url" in bin/solr and bin/solr.cmd > * "solr home" in ZkCLI (9.7 and 9x), bin/solr and bin/solr.cmd > * "scrape interval" in SolrExporter > * "started" in AssertTool > * "not-started" (-S uppercase here) in AssertTool > * "script" in RunExampleTool > * "service name" in install_solr_service.sh > h4. Proposed Conflict Resolution > Fix in branch_9_7 (9.7.1) -s for shards by replacing it with -sh in > CreateTool. Previous changes from SOLR-17359 / #2593 mistakenly introduced -s > for "shards", causing new conflicts that were resolved in branch_9x and main > but not any possible patch-releases of 9.7 (branch_9_7). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "script" in RunExampleTool > to avoid confusion with -s for "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -s for "service name" in > install_solr_service.sh by replacing it with --service. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "solr home" in bin/solr, > bin/solr.cmd and ZKCLI (only present in 9x releases) to avoid confusion with > solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -url (that violates the > single-letter naming convention for flags) by replacing it with -s for > "solr-url" in SolrCLI, so that the help output from Zk*Tool and other tools > are correct (see notes below). > Deprecate (9x and 9.7.1) and remove (10.0) -s for "scrape-interval" in > SolrExporter in favor to further migrations of solr url params and to avoid > confusions wiht solr-url. > Deprecate (9x and 9.7.1) and remove (10.0) -s for "started" in AssertTool. A > future proposal may include a full rewrite of AssertTool, but for now we will > deprecate -s in favor to "solr-url". > Deprecate (9x and 9.7.1) and remove (10.0) -S (cap) for "not-started" in > AssertTool. A future proposal may include a full rewrite of AssertTool, but > for now we will deprecate -S in favor to "solr-url" and because > case-sensitivity is avoided. > h4. Additional Notes > Zookeeper CLI classes (Zk*Tool) are mentioning in their help output "-s > " for providing solr-url but the solr-url options support only -url and > --solr-url (and other variants) as options, but not -s. This is partly a typo > / bug that should be fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] SOLR-17131: Optimize rows=0 since score/sort isn't necessary [solr]
risdenk opened a new pull request, #2221: URL: https://github.com/apache/solr/pull/2221 https://issues.apache.org/jira/browse/SOLR-17131 # Description If a query has `rows=0` Solr does not need to sort the results or even compute the score. This means the filterCache can be more efficient to compute the result and Solr doesn't spend time on unnecessarily sorting and scoring large result sets for it to be thrown away. There is one subtle difference from this change - `maxScore` is no longer returned if `rows=0` which seems like a reasonable tradeoff. If `maxScore` is needed then set `rows=1`. `maxScore` can't reliably be compared across searches anyway so no reason to have it when `rows=0`. This was found while looking at https://issues.apache.org/jira/browse/SOLR-14765 and trying to reason through the case of `rows=0` that are sometimes used to just determine count of matching results. This change adds the check for `rows=0` before other checks to ensure that we can short circuit scoring even if there is a scoring query. We also don't add the query to the filter cache since that could result in filter cache thrashing. In some tests, we found that queries with `rows=0` p99 improved by 50% and CPU dropped by 5%. # Tests Updated tests in TestMainQueryCaching to account for this optimization. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] SOLR-17130: edismax-matchalldocs-optimization [solr]
risdenk opened a new pull request, #2218: URL: https://github.com/apache/solr/pull/2218 https://issues.apache.org/jira/browse/SOLR-17130 # Description This unwraps the case of using edismax query parser and `q=*:*`. Prior to this change, `*:*` was being changed to `+*:*` which wraps the `MatchAllDocsQuery` with a boolean query. We can unwrap the boolean query since its not necessary if the `MatchAllDocsQuery` is the only clause. I found this by looking at https://issues.apache.org/jira/browse/SOLR-14765 and wondering why when using `edismax` the optimizations were skipped even though the query was `*:*`. The boolean wrapped `MatchAllDocsQuery` means that some of the optimization logic is skipped - https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L1623 # Tests Added tests to confirm that if `*` or `*:*` is the query then Solr returns just a `MatchAllDocsQuery` instead of a boolean wrapped `MatchAllDocsQuery`. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17131) Optimize rows=0 queries since score/sort isn't necessary
[ https://issues.apache.org/jira/browse/SOLR-17131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17131: -- Labels: pull-request-available (was: ) > Optimize rows=0 queries since score/sort isn't necessary > > > Key: SOLR-17131 > URL: https://issues.apache.org/jira/browse/SOLR-17131 > Project: Solr > Issue Type: Improvement >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Labels: pull-request-available > Time Spent: 6.5h > Remaining Estimate: 0h > > If a query has rows=0 Solr does not need to sort the results or even compute > the score. This means the filterCache can be more efficient to compute the > result and Solr doesn't spend time on unnecessarily sorting and scoring large > result sets for it to be thrown away. > There is one subtle difference from this change - `maxScore` is no longer > returned if `rows=0` which seems like a reasonable tradeoff. If `maxScore` is > needed then set `rows=1`. `maxScore` can't reliably be compared across > searches anyway so no reason to have it when `rows=0`. > This was found while looking at > https://issues.apache.org/jira/browse/SOLR-14765 and trying to reason through > the case of rows=0 that are sometimes used to just determine count of > matching results. This change adds the check for rows=0 before other checks > to ensure that we can short circuit scoring even if there is a scoring query. > We also don't add the query to the filter cache since that could result in > filter cache thrashing. > In some tests, we found that queries with rows=0 p99 improved by 50% and CPU > dropped by 5%. -- 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-17130) edismax MatchAllDocsQuery (*:*) Optimization
[ https://issues.apache.org/jira/browse/SOLR-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17130: -- Labels: pull-request-available (was: ) > edismax MatchAllDocsQuery (*:*) Optimization > > > Key: SOLR-17130 > URL: https://issues.apache.org/jira/browse/SOLR-17130 > Project: Solr > Issue Type: Improvement >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > This unwraps the case of using edismax query parser and q=*:*. Prior to this > change, *:* was being changed to +*:* which wraps the MatchAllDocsQuery with > a boolean query. We can unwrap the boolean query since its not necessary if > the MatchAllDocsQuery is the only clause. > I found this by looking at https://issues.apache.org/jira/browse/SOLR-14765 > and wondering why when using edismax the optimizations were skipped even > though the query was *:*. The boolean wrapped MatchAllDocsQuery means that > some of the optimization logic is skipped - > https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L1623 -- 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-6122) API to cancel an already submitted/running Collections API call
[ https://issues.apache.org/jira/browse/SOLR-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887702#comment-17887702 ] Yuntong Qu commented on SOLR-6122: -- I believe there could be 2 possible approach to handle this. Apporach 1: * Make another queue for collection-queue-cancel * collection handle submit cancel request as Znode to collection-queue-cancel * In Overseer, during each [run()|https://github.com/apache/solr/blob/383d21bac694d17ae64ddae5af30cfb9b5a0c615/solr/core/src/java/org/apache/solr/cloud/OverseerTaskProcessor.java#L168] in OverseerTaskProcessor, we view items from collection-queue-cancel and decide in Overseer if requested. task cancel should be removed from collection-queue-work and running map. Cons: - not treating cancel task as a normal collection api call, requiring a seperate queue, seperate code path to submit and read Znode - also need code to handle the case where we are running distributed Collection API Approach 2: * submit cancel to collection-queue-work * make a new CollectionApiCommand, CancelCmd, which is going to modify collection-queue-work and running map if nessesary Cons: - [CollectionApiCommand|https://github.com/apache/solr/blob/f5b012912aa9313c801d20835a1de05e0407a6b1/solr/core/src/java/org/apache/solr/cloud/api/collections/CollApiCmds.java#L117] have no direct ways for interacting with overseer queues. And doing it through CollectionApiCommand somewhat break the assumption that those cmd should not care about overseer queue implementation. In my opinion that it should be [OverseerTaskProcesser|https://github.com/apache/solr/blob/f5b012912aa9313c801d20835a1de05e0407a6b1/solr/core/src/java/org/apache/solr/cloud/OverseerTaskProcessor.java#L168] class's responsiblity to handle add/remove item from overseer queue as it currently does, so i am leaning towards apporach 1. > API to cancel an already submitted/running Collections API call > --- > > Key: SOLR-6122 > URL: https://issues.apache.org/jira/browse/SOLR-6122 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Reporter: Anshum Gupta >Priority: Major > > Right now we can trigger a long running task with no way to cancel it > cleanly. > We should have an API that interrupts the already running/submitted > collections API call. -- 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-17482: Change long form of -r to --recursive [solr]
malliaridis commented on PR #2746: URL: https://github.com/apache/solr/pull/2746#issuecomment-2400788124 @epugh please note that `--recurse` may need adaptation for `branch_9x`. There are more references than in `main`. -- 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-17478) ZkTestServer bugs can cause 30sec test pauses
[
https://issues.apache.org/jira/browse/SOLR-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887709#comment-17887709
]
David Smiley commented on SOLR-17478:
-
I like that you thought of a suggestion that doesn't bloat our base test
classes :)
> ZkTestServer bugs can cause 30sec test pauses
> -
>
> Key: SOLR-17478
> URL: https://issues.apache.org/jira/browse/SOLR-17478
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Pop Quiz: which of these two (psuedo-code) ZK based test classes will be
> faster...
> {code:java}
> public class Test_X extends SolrTestCase {
> public void test() throws Exception {
> ZkTestServer zkServer = new ZkTestServer(createTempDir());
> zkServer.run();
> zkServer.shutdown();
> }
> }
> public class Test_Y extends SolrTestCaseJ4 {
> public void test() throws Exception {
> ZkTestServer zkServer = new ZkTestServer(createTempDir());
> zkServer.run();
> zkServer.shutdown();
> }
> }
> {code}
> ...if you guessed "Test_X, because SolrTestCase has less overhead then
> SolrTestCaseJ4" then you are *wrong by ~30 seconds.*
> Actually, that's not _always_ true: if you run both tests in the same JVM
> then they will both take the same amount of time:
> * If Test_Y runs first, they will both take ~1 second each
> * If Test_X runs first, they will both take 30+ seconds *_each_*
> The reason for the dependency comes down to:
> * The {{"zookeeper.4lw.commands.whitelist"}} sysprop is set/cleared in
> SolrTestCaseJ4 (BeforeClass/AfterClass), but _NOT_ in SolrTestCase
> * ZkTestServer depends on the ZK helper methods
> {{ClientBase.waitForServerUp()}} which depends on the 4LW {{"stat"}} being
> whitelisted
> ** If "stat" is not whitelisted, then {{waitForServerUp()}} timesout after
> 30 sec and return a failure
> ** Bonus problem: ZkTestServer never checks of the return value of
> {{waitForServerUp()}} !
> * Zookeeper only checks for the 4LW whitelist sysprop the first time it's
> needed by the {{FourLetterCommands}} class _and then caches it staticly_
> ** So if the first testclass to run a ZK server doesn't extend
> SolrTestCaseJ4, then _every_ test that uses ZkTestServer in that JVM will
> stall for 30 seconds
--
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-16707) Avoid "Recursive update" ISE in non-async cache computeIfAbsent()
[ https://issues.apache.org/jira/browse/SOLR-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16707: -- Labels: pull-request-available (was: ) > Avoid "Recursive update" ISE in non-async cache computeIfAbsent() > - > > Key: SOLR-16707 > URL: https://issues.apache.org/jira/browse/SOLR-16707 > Project: Solr > Issue Type: Test >Reporter: Mikhail Khludnev >Assignee: Michael Gibney >Priority: Minor > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > > 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
Re: [PR] SOLR-16707: Avoid "Recursive update" ISE in non-async cache `computeIfAbsent()` [solr]
dsmiley commented on PR #1481: URL: https://github.com/apache/solr/pull/1481#issuecomment-2400527144 @magibney you seemed so close to this nice change being merged -- 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-16289) [interleaving] transformer does not work in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-16289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16289: -- Labels: pull-request-available (was: ) > [interleaving] transformer does not work in SolrCloud > - > > Key: SOLR-16289 > URL: https://issues.apache.org/jira/browse/SOLR-16289 > Project: Solr > Issue Type: Improvement > Components: contrib - LTR >Affects Versions: 9.0 >Reporter: Naoto Minami >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > In SolrCloud, two-stage shard requests are processed. The first stage is to > execute the query return unique keys and scores of documents. Then, in the > second stage, collect fields’ values of merged top documents. > LTRInterleavingTransformerFactory should be run in the first stage > (ResponseBuilder.STAGE_EXECUTE_QUERY), because the > LTRInterleavingScoringQuery knows which model is used in scoring. However, > it’s run in second stage(ResponseBuilder.STAGE_GET_FIELDS) and > LTRInterleavingRescorer#rescore is skipped in second stage. > LTRInterleavingTransformerFactory cannot handle this case, so thrown > NullPointerException when fl=[interleaving] is specified in SolrCloud. There > is a same problem in LTRFeatureLoggerTransformerFactory. But, if interleaving > is not used, LTRFeatureLoggerTransformerFactory falls back when feature > vector cache is not hit (i.e. in second stage). > I will fix the NullPointerException problem, but the underlying solution > should be discussed. One of the solution of this problem is disable two-stage > request by distrib.singlePass=true parameter. -- 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-15476: Facilitate 'shards.info' content customisation. [solr]
github-actions[bot] commented on PR #176: URL: https://github.com/apache/solr/pull/176#issuecomment-2401012938 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
Re: [PR] SOLR-15450 add PrefetchingFieldValueFeature [solr]
github-actions[bot] closed pull request #166: SOLR-15450 add PrefetchingFieldValueFeature URL: https://github.com/apache/solr/pull/166 -- 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-16286) Topic stream not honoring initialCheckpoint in getPersistedCheckpoints
[ https://issues.apache.org/jira/browse/SOLR-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16286: -- Labels: pull-request-available (was: ) > Topic stream not honoring initialCheckpoint in getPersistedCheckpoints > -- > > Key: SOLR-16286 > URL: https://issues.apache.org/jira/browse/SOLR-16286 > Project: Solr > Issue Type: Bug > Components: streaming expressions >Affects Versions: 9.0 >Reporter: Dan Rosher >Assignee: Eric Pugh >Priority: Minor > Labels: pull-request-available > Time Spent: 3h 40m > Remaining Estimate: 0h > > getCheckpoints() does honor initialCheckpoint, but when stored, > getPersistedCheckpoints which is processed first, does not. The effect is > that initialCheckpoint=0 doesn't work as expected after it's stored. -- 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-15450 add PrefetchingFieldValueFeature [solr]
github-actions[bot] commented on PR #166: URL: https://github.com/apache/solr/pull/166#issuecomment-2401012974 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
[jira] [Updated] (SOLR-16260) Handle JSR310 Date classes in JavaBinCodec
[ https://issues.apache.org/jira/browse/SOLR-16260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16260: -- Labels: pull-request-available (was: ) > Handle JSR310 Date classes in JavaBinCodec > -- > > Key: SOLR-16260 > URL: https://issues.apache.org/jira/browse/SOLR-16260 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 9.0, 8.11.1 >Reporter: Sebastian Gift >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > JavaBinCodec currently only supports java.util.Date as Date input and doesn't > handle JSR310 classes like Instant or LocalDate. As a result adding a > SolrInputDocument which contains a LocalDate will be serialized in SolrJ as > java.time.LocalDate:2022-12-31 using the fallback logic in > JavaBinCodec#writeVal. This value then gets parsed on the server and throws > an exception if the field is defined as a date field in the schema. > I've written a small PR on Github to support ZonedDateTime, LocalDate and > Instant as variants of Date (all get stored in Javabin as epoch millis and > converted to Date on deserializing). I've not added support for LocalDateTime > since it lacks enough information to be converted to epoch millis, but maybe > there should be some warning or error provided to show that it isn't > supported by SolrJ (instead of the generic "Couldn't parse date because: > Improperly formatted datetime:" Exception) > > Note: A user could provide the value either as String (e.g. using > Instant#toString) or ObjectResolver, which gets parsed correctly, but > compared to the handling of java.util.Date that's not very intuitive. -- 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-16287) MapStream - remap tuple value(s)
[
https://issues.apache.org/jira/browse/SOLR-16287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-16287:
--
Labels: pull-request-available (was: )
> MapStream - remap tuple value(s)
> -
>
> Key: SOLR-16287
> URL: https://issues.apache.org/jira/browse/SOLR-16287
> Project: Solr
> Issue Type: Improvement
> Components: streaming expressions
>Affects Versions: 9.0
>Reporter: Dan Rosher
>Assignee: Joel Bernstein
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Remap from (k,v) => k -> newKey -> value
> e.g. with
> map(,"cand_id=add-distinct") , convert stream tuples from
> From
> {code:java}
> {"cand_id":5718,id:123,v_i:345}{code}
> To
> {code:java}
> {
> id:123,
> v_i:345,
> "cand_id": {
> "add-distinct": 5718
> }, {code}
> Useful for update stream for atomic updates.
--
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-15450) Create possibility to prefetch stored fields needed for FieldValueFeatures
[
https://issues.apache.org/jira/browse/SOLR-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-15450:
--
Labels: pull-request-available (was: )
> Create possibility to prefetch stored fields needed for FieldValueFeatures
> --
>
> Key: SOLR-15450
> URL: https://issues.apache.org/jira/browse/SOLR-15450
> Project: Solr
> Issue Type: Sub-task
> Components: contrib - LTR
>Reporter: Tom Gilke
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> The idea for this optimization came up in SOLR-12697 .
> The basic idea is to create a new type of {{FieldValueFeature}}. Named e.g.
> {{PrefetchingFieldValueFeature}}.
> This {{PrefetchingFieldValueFeature}} will prefetch all the stored fields
> that itself and other {{PrefetchingFieldValueFeatures}} need, so that only
> one of these Features has to read the values from disk. The other ones can
> access them from the cache, which would improve the performance.
> The {{PrefetchingFieldValueFeature}} would extend the {{FieldValueFeature}}
> so that the current behavior of the {{FieldValueFeature}} would not be
> affected.
--
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-15437) ReRanking/LTR does not work in combination with custom sort and SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-15437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-15437: -- Labels: pull-request-available (was: ) > ReRanking/LTR does not work in combination with custom sort and SolrCloud > - > > Key: SOLR-15437 > URL: https://issues.apache.org/jira/browse/SOLR-15437 > Project: Solr > Issue Type: Bug > Components: contrib - LTR, query parsers, SolrCloud >Affects Versions: 8.8.2 >Reporter: Tobias Kässmann >Priority: Major > Labels: pull-request-available > Time Spent: 7h 50m > Remaining Estimate: 0h > > [~TomGilke], [~tboeghk] and I are currently working a lot on the Solr LTR > feature. In our setup we're using a custom sort function for a solid base > scoring of the documents. > We found out that a plain SolrCloud will return random sorted docs if you > define a custom sort field or function. This problem is also mentioned > [here|https://lucene.472066.n3.nabble.com/Ranking-issue-when-combining-sorting-and-re-ranking-on-SolrCloud-multiple-shards-td4457723.html] > and is not really fixed. > You can do the following steps to reproduce this issue: > [here|https://gist.github.com/tboeghk/0844d310641b994dac924acaf94fd78f]. > In the meantime we're also investing on this issue and try to debug the > QueryComponent. But if there is any hint or thought available, we're very > happy to hear from you. Maybe [~cpoerschke] can help here a little bit? > What we've found out so far: > * It only happens in SolrCloud mode (shards > 1) > * Maybe is has something to do with the > [MergeStrategy|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L188] > in the QueryComponent. > You can also use the [pull request to reproduce the > problem|https://github.com/apache/solr/pull/151]. -- 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-16243: Compile SQL to a Streaming Expression while visiting the … [solr]
github-actions[bot] closed pull request #899: SOLR-16243: Compile SQL to a Streaming Expression while visiting the … URL: https://github.com/apache/solr/pull/899 -- 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-16243) Compile SQL to a Streaming Expression while visiting the Calcite SQL parse tree
[ https://issues.apache.org/jira/browse/SOLR-16243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16243: -- Labels: RobustSQL pull-request-available (was: RobustSQL) > Compile SQL to a Streaming Expression while visiting the Calcite SQL parse > tree > --- > > Key: SOLR-16243 > URL: https://issues.apache.org/jira/browse/SOLR-16243 > Project: Solr > Issue Type: Improvement > Components: Parallel SQL >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Labels: RobustSQL, pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > We're going to have to up our SQL interpretation game in order to support > more complex query plans that include joins. > This ticket adds an approach that translates the Calcite parse tree into a > tree of "Implementor" nodes. The Implementor.getPhysicalPlan() method can > then be called to traverse the Implementor tree and return a Streaming > Expression which is the executable physical plan. > The approach allows for implementor nodes of different types to handle Join > logic. An example JoinImplementor is included in the PR which holds a left > and right Implementor and returns an InnerJoinStream from the getPhysicalPlan > method. -- 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-16291 : Decay function queries gauss,linear,exponential [solr]
github-actions[bot] commented on PR #939: URL: https://github.com/apache/solr/pull/939#issuecomment-2401012640 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
Re: [PR] SOLR-16289: Null check in transformers of ltr module [solr]
github-actions[bot] commented on PR #937: URL: https://github.com/apache/solr/pull/937#issuecomment-2401012667 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
Re: [PR] SOLR-16289: Null check in transformers of ltr module [solr]
github-actions[bot] closed pull request #937: SOLR-16289: Null check in transformers of ltr module URL: https://github.com/apache/solr/pull/937 -- 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-16291 : Decay function queries gauss,linear,exponential [solr]
github-actions[bot] closed pull request #939: SOLR-16291 : Decay function queries gauss,linear,exponential URL: https://github.com/apache/solr/pull/939 -- 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-16260: Add support for Instant, LocalDate and ZonedDateTime to JavaBinCodec [solr]
github-actions[bot] commented on PR #913: URL: https://github.com/apache/solr/pull/913#issuecomment-2401012752 This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active 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
[jira] [Commented] (SOLR-16503) Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
[
https://issues.apache.org/jira/browse/SOLR-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887561#comment-17887561
]
ASF subversion and git services commented on SOLR-16503:
Commit a883061c8f485a6fdd5ae113684e31f47e61a140 in solr's branch
refs/heads/branch_9x from Sanjay Dutt
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a883061c8f4 ]
SOLR-16503: New home for default http2 client (#2689)
* Introduced `HttpSolrClientProvider` as the new provider for `Http2SolrClient`.
* `UpdateShardHandler#getDefaultHttpClient` has been marked deprecated.
* Updated `IOUtils.closeQuietly` to accept `AutoCloseable` instead of
`Closeable`, enhancing its flexibility.
-
Co-authored-by: David Smiley
(cherry picked from commit 47c4aae0375f6edf82d608147a9d04acf4f42faa)
> Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
> -
>
> Key: SOLR-16503
> URL: https://issues.apache.org/jira/browse/SOLR-16503
> Project: Solr
> Issue Type: Sub-task
>Reporter: David Smiley
>Priority: Major
> Labels: pull-request-available
> Attachments: Screenshot 2024-03-16 at 9.14.36 PM.png
>
> Time Spent: 10h 50m
> Remaining Estimate: 0h
>
> Much of Solr's remaining uses of Apache HttpClient (HTTP 1) is due to
> {{org.apache.solr.update.UpdateShardHandler#getDefaultHttpClient}} which
> underlies most Solr-to-Solr connectivity. This also underlies the
> {{{}CoreContainer.getSolrClientCache{}}}. Lets switch to Jetty (HTTP 2).
>
> In SolrClientCache in particular:
> Switch use of CloudLegacySolrClient.Builder to CloudSolrClient.Builder
> Switch use of HttpSolrClient.Builder to Http2SolrClient.Builder
> Undeprecate all the methods here. They should not have been deprecated in
> the first place.
> The constructor: switch from Apache HttpClient to a Jetty HttpClient.
--
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-17150) Create MemQueryLimit implementation
[
https://issues.apache.org/jira/browse/SOLR-17150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887572#comment-17887572
]
ASF subversion and git services commented on SOLR-17150:
Commit b1a6b8d92f4a6479ebbdd3f86c50717386c9d413 in solr's branch
refs/heads/branch_9x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b1a6b8d92f4 ]
SOLR-17150: Create MemAllowedLimit (#2708) (#2749)
> Create MemQueryLimit implementation
> ---
>
> Key: SOLR-17150
> URL: https://issues.apache.org/jira/browse/SOLR-17150
> Project: Solr
> Issue Type: Sub-task
> Components: Query Limits
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> An implementation of {{QueryTimeout}} that terminates misbehaving queries
> that allocate too much memory for their execution.
> This is a bit more complicated than {{CpuQueryLimits}} because the first time
> a query is submitted it may legitimately allocate many sizeable objects
> (caches, field values, etc). So we want to catch and terminate queries that
> either exceed any reasonable threshold (eg. 2GB), or significantly exceed a
> time-weighted percentile of the recent queries.
--
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
