[jira] [Updated] (SOLR-17367) org.apache.solr.cli.PostTool is ignoring -params option
[ https://issues.apache.org/jira/browse/SOLR-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17367: -- Labels: easyfix pull-request-available (was: easyfix) > org.apache.solr.cli.PostTool is ignoring -params option > --- > > Key: SOLR-17367 > URL: https://issues.apache.org/jira/browse/SOLR-17367 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: cli >Affects Versions: 9.6.1 > Environment: I encountered the issue using docker solr version 9.6.1 >Reporter: Bogdan Stoica >Assignee: Eric Pugh >Priority: Minor > Labels: easyfix, pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > org.apache.solr.cli.PostTool is ignoring the -params option. > According to the documentation here > [https://solr.apache.org/guide/solr/latest/indexing-guide/post-tool.html,] > the -params option is to be used when specifying a different separator (for > example the tab separator) > However, looking through the code > ([https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cli/PostTool.java#L244]) > it seems that even if the option is mentioned, it is never used afterwards. -- 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-16824) Adopt Linux Command line tool pattern of -- for multi character commands.
[ https://issues.apache.org/jira/browse/SOLR-16824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16824: -- Labels: pull-request-available (was: ) > Adopt Linux Command line tool pattern of -- for multi character commands. > - > > Key: SOLR-16824 > URL: https://issues.apache.org/jira/browse/SOLR-16824 > Project: Solr > Issue Type: Sub-task > Components: cli > Environment: sweep through and have --get instead of -get etc through > all our command options. >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > Labels: pull-request-available > Time Spent: 8h 50m > Remaining Estimate: 0h > -- 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-10255) Large psuedo-stored fields via BinaryDocValuesField
[
https://issues.apache.org/jira/browse/SOLR-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-10255:
--
Labels: pull-request-available (was: )
> Large psuedo-stored fields via BinaryDocValuesField
> ---
>
> Key: SOLR-10255
> URL: https://issues.apache.org/jira/browse/SOLR-10255
> Project: Solr
> Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-10255.patch, SOLR-10255.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> (sub-issue of SOLR-10117) This is a proposal for a better way for Solr to
> handle "large" text fields. Large docs that are in Lucene StoredFields slow
> requests that don't involve access to such fields. This is fundamental to
> the fact that StoredFields are row-stored. Worse, the Solr documentCache
> will wind up holding onto massive Strings. While the latter could be tackled
> on it's own somehow as it's the most serious issue, nevertheless it seems
> wrong that such large fields are in row-stored storage to begin with. After
> all, relational DBs seemed to have figured this out and put CLOBs/BLOBs in a
> separate place. Here, we do similarly by using, Lucene
> {{BinaryDocValuesField}}. BDVF isn't well known in the DocValues family as
> it's not for typical DocValues purposes like sorting/faceting etc. The
> default DocValuesFormat doesn't compress these but we could write one that
> does.
--
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-17357) Improve default --help formatting for CLI Tools, make configurable
[
https://issues.apache.org/jira/browse/SOLR-17357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17357:
--
Labels: pull-request-available (was: )
> Improve default --help formatting for CLI Tools, make configurable
> --
>
> Key: SOLR-17357
> URL: https://issues.apache.org/jira/browse/SOLR-17357
> Project: Solr
> Issue Type: Sub-task
> Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In 9.6 the Usage help text for each tool is covered by {{{}bin/solr[.cmd]{}}}.
> On main branch many of the Usage strings were moved to RefGuide in
> SOLR-16797. That leaves the tool {{--help}} print somewhat amputatet, e.g.
> {code:java}
> $ bin/solr create -h
> usage: create
> -c,--name Name of collection or core to create.
> -d,--confdir Configuration directory to copy when
> creating the new collection; default is
> _default.
> -help Print this message
> -n,--confname Configuration name; default is the
> collection name.
> -rf,--replicationFactor <#> Number of copies of each document across
> the collection (replicas per shard);
> default is 1.
> -s,--shards <#> Number of shards; default is 1.
> -solrUrl Base Solr URL, which can be used to
> determine the zkHost if that's not
> known; defaults to:
> http://localhost:8983.
> -u,--credentials Credentials in the format
> username:password. Example:
> --credentials solr:SolrRocks
> -verbose Enable more verbose command output.
> -z,--zkHost Zookeeper connection string; unnecessary
> if ZK_HOST is defined in solr.in.sh;
> otherwise, defaults to localhost:9983.
> {code}
> This Jira is to make this a bit better.
> The {{Tool}} interface provides {{{}getName{}}}, {{getOptions}} and
> {{{}runTool{}}}. The {{printHelp}} interface of commons-cli has the ability
> of also printing a {{{}Usage{}}}, header and footer:
> {code:java}
> /**
> * Prints the help for {@code options} with the specified command line
> syntax. This method prints help information
> * to {@link System#out} by default.
> *
> * @param cmdLineSyntax the syntax for this application
> * @param header the banner to display at the beginning of the help
> * @param options the Options instance
> * @param footer the banner to display at the end of the help
> * @param autoUsage whether to print an automatically generated usage
> statement
> */
> public void printHelp(final String cmdLineSyntax, final String header, final
> Options options, final String footer, final boolean autoUsage) {
> printHelp(getWidth(), cmdLineSyntax, header, options, footer, autoUsage);
> } {code}
> I propose the addition of three methods to our {{Tool}} interface:
> {code:java}
> String getUsage();
> String getHeader();
> String getFooter();{code}
> The default behavior will be to auto generate usage string, and use "List of
> options:" as header and a link to Reference guide as footer, e.g for assert
> tool:
> {code:java}
> $ bin/solr assert -h
> usage: bin/solr assert [-c ] [-C ] [-e] [-m ] [-R] [-r]
> [-S ] [-s ] [--same-user ] [-t ] [-u ]
> [-x ] [-X ]
> List of options:
> -c,--cloud Asserts that Solr is running in cloud mode.
> Also fails if Solr not running. URL
> should be for root Solr path.
> -C,--not-cloud Asserts that Solr is not running in cloud
> mode. Also fails if Solr not running. URL
> should be for root Solr path.
> -e,--exitcode Return an exit code instead of printing
> error message on assert fail.
> -m,--message Exception message to be used in place of
> the default error message.
> -R,--not-root Asserts that we are NOT the root user.
> -r,--root Asserts that we are the root user.
> -S,--not-started Asserts that Solr is NOT running on a
> certain URL. Default timeout is 1000ms.
> -s,--started Asserts that Solr is running on a certain
> URL. Default timeout is 1000ms.
> --same-user Asserts that we run as same user that owns
>
[jira] [Updated] (SOLR-17146) Add DelegatingBackupRepository and alternative checksum verification
[ https://issues.apache.org/jira/browse/SOLR-17146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17146: -- Labels: pull-request-available (was: ) > Add DelegatingBackupRepository and alternative checksum verification > > > Key: SOLR-17146 > URL: https://issues.apache.org/jira/browse/SOLR-17146 > Project: Solr > Issue Type: Improvement >Reporter: Bruno Roustant >Priority: Major > Labels: pull-request-available > Fix For: 9.6 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently all BackupRepository copy methods systematically verify the > checksum of the index file to copy before copying it to the repository. > This poses a problem when the file to copy cannot be verified with the > standard Lucene checksum check. For example if the file was encrypted, the > checkum would need to be verified in a different manner. > We propose to > 1- Add an optional initialization argument to disable the checksum > verification (enabled by default) in each BackupRepository implementation. > 2- Introduce an abstract DelegatingBackupDirectory to extend when we need to > perform different/additional logic on top of a delegate BackupDirectory. For > example, verify the checksum differently. Also, the DelegatingBackupDirectory > could inject some initialization arguments when the BackupRepositoryFactory > creates its delegate. > Also make the existing TrackingBackupRepository (for tests) extend > DelegatingBackupDirectory. > 3- Add a test case to AbstractBackupRepositoryTest to ensure all > implementations support disabling the checksum verification. And add a test > for LocalFileSystemDirectory (not tested currently) that also extends > AbstractBackupRepositoryTest. -- 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-13350) Explore collector managers for multi-threaded search
[ https://issues.apache.org/jira/browse/SOLR-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-13350: -- Labels: pull-request-available (was: ) > Explore collector managers for multi-threaded search > > > Key: SOLR-13350 > URL: https://issues.apache.org/jira/browse/SOLR-13350 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Labels: pull-request-available > Fix For: 9.7 > > Attachments: SOLR-13350-pre-PR-2508.patch, SOLR-13350.patch, > SOLR-13350.patch, SOLR-13350.patch > > Time Spent: 12h 20m > Remaining Estimate: 0h > > AFAICT, SolrIndexSearcher can be used only to search all the segments of an > index in series. However, using CollectorManagers, segments can be searched > concurrently and result in reduced latency. Opening this issue to explore the > effectiveness of using CollectorManagers in SolrIndexSearcher from latency > and throughput perspective. -- 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-14985) Slow indexing and search performance when using HttpClusterStateProvider
[ https://issues.apache.org/jira/browse/SOLR-14985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-14985: -- Labels: pull-request-available (was: ) > Slow indexing and search performance when using HttpClusterStateProvider > > > Key: SOLR-14985 > URL: https://issues.apache.org/jira/browse/SOLR-14985 > Project: Solr > Issue Type: Bug > Components: SolrJ >Reporter: Shalin Shekhar Mangar >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > HttpClusterStateProvider fetches and caches Aliases and Live Nodes for 5 > seconds. > The BaseSolrCloudClient caches DocCollection for 60 seconds but only if the > DocCollection is not lazy and all collections returned by > HttpClusterStateProvider are not lazy which means they are never cached. > The BaseSolrCloudClient has a method for resolving aliases which fetches > DocCollection for each input collection. This is an HTTP call with no caching > when using HttpClusterStateProvider. This resolveAliases method is called > twice for each update. > So overall, at least 3 HTTP calls are made to fetch cluster state for each > update request when using HttpClusterStateProvider. There may be more if > aliases are involved or if more than one collection is specified in the > request. Similar problems exist on the query path as well. > Due to these reasons, using HttpClusterStateProvider causes horrible > latencies and throughput for update and search requests. -- 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-15689) PeerSync inconsistently handles 'delete' highest versions
[
https://issues.apache.org/jira/browse/SOLR-15689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-15689:
--
Labels: pull-request-available (was: )
> PeerSync inconsistently handles 'delete' highest versions
> -
>
> Key: SOLR-15689
> URL: https://issues.apache.org/jira/browse/SOLR-15689
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Noticed whilst code reading that the
> {code}
> ...
> if (ourLowThreshold > otherHigh && ourHighest >= otherHighest) {
> ...
> {code}
> comparison e.g.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.10.0/solr/core/src/java/org/apache/solr/update/PeerSync.java#L792
> presumes that the {{Highest}} values are positive.
--
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-17330) Default value for 'loadOnStartup' is fuzzy
[
https://issues.apache.org/jira/browse/SOLR-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17330:
--
Labels: pull-request-available (was: )
> Default value for 'loadOnStartup' is fuzzy
> --
>
> Key: SOLR-17330
> URL: https://issues.apache.org/jira/browse/SOLR-17330
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.6
>Reporter: Pierre Salagnac
>Assignee: Eric Pugh
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 9.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Each core has property {{loadOnStartup}} to decide if the core is opened at
> start-up or delayed until first access.
> When creating a new core and *not* specifying the property in the request, we
> take the default value from {{CoreDescriptor.defaultProperties}} which is
> {{true}}.
> {code:java|title= defaultProperties}
> private static final Map defaultProperties = Map.of(,
> CORE_LOADONSTARTUP, "true");
> {code}
> Then, when we retrieve the value of the property in
> {{CoreDescriptor.isLoadOnStartup()}}, if the property is not the core stored
> properties, default value is {{false}}.
> {code:java|title=isLoadOnStartup()}
> String tmp = coreProperties.getProperty(CORE_LOADONSTARTUP, "false");
> {code}
> Impact is low since all cores are created with value {{"true"}} when not
> explicitly created, using value from the default properties. This just makes
> the code confusing to read.
--
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-17336) Merge windows and linux examples in ref guide for post tool
[ https://issues.apache.org/jira/browse/SOLR-17336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17336: -- Labels: pull-request-available (was: ) > Merge windows and linux examples in ref guide for post tool > --- > > Key: SOLR-17336 > URL: https://issues.apache.org/jira/browse/SOLR-17336 > Project: Solr > Issue Type: Sub-task > Components: documentation >Reporter: Eric Pugh >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Per email thread, we'll just use a single example because java deals with > windows and linux filesystem slashes. -- 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-15831) Refactor bin/solr and bin/solr.cmd to delegate args parsing and usage help to SolrCLI
[
https://issues.apache.org/jira/browse/SOLR-15831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-15831:
--
Labels: pull-request-available (was: )
> Refactor bin/solr and bin/solr.cmd to delegate args parsing and usage help to
> SolrCLI
> -
>
> Key: SOLR-15831
> URL: https://issues.apache.org/jira/browse/SOLR-15831
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Timothy Potter
>Assignee: Timothy Potter
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Having recently touched {{bin/solr}} for SOLR-15199, it looks like we can
> remove a lot of OS specific scripting by having SolrCLI parse the args and
> report usage instructions for every command that is implemented by SolrCLI.
> This will also make it easier for devs to add new commands as needed, as they
> likely won't need to touch the bin/solr or bin/solr.cmd scripts (which should
> be a goal of the improvements made in this ticket)
--
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-17321) Bump minimum required Java version to 21
[ https://issues.apache.org/jira/browse/SOLR-17321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17321: -- Labels: pull-request-available (was: ) > Bump minimum required Java version to 21 > > > Key: SOLR-17321 > URL: https://issues.apache.org/jira/browse/SOLR-17321 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Sanjay Dutt >Priority: Major > Labels: pull-request-available > Time Spent: 9h 10m > Remaining Estimate: 0h > > We are upgrading the minimum Java version for Solr main branch to 21. > However, at the same, It has been suggested to be not so aggressive with > SolrJ (and thus solr-api, a dependency) Java version – setting it to 17. -- 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-17160) Bulk admin operations may fail because of max tracked requests
[
https://issues.apache.org/jira/browse/SOLR-17160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17160:
--
Labels: pull-request-available (was: )
> Bulk admin operations may fail because of max tracked requests
> --
>
> Key: SOLR-17160
> URL: https://issues.apache.org/jira/browse/SOLR-17160
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
>Affects Versions: 8.11, 9.5
>Reporter: Pierre Salagnac
>Priority: Minor
> Labels: pull-request-available
> Fix For: 9.7
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> In {{{}CoreAdminHandler{}}}, we maintain in-memory the list of in-flight
> requests and completed/failed request.
> _Note they are core/replica level async requests, and not top level requests
> which mostly at the collection level. Top level requests are tracked by
> storing the async ID in a Zookeeper node, which is not related to this
> ticket._
>
> For completed/failed requests, we only track a maximum of 100 requests by
> dropping the oldest ones. The typical client in
> {{CollectionHandlingUtils.waitForCoreAdminAsyncCallToComplete()}} polls
> status of the submitted requests, with a retry loop until requests are
> completed. If for some reason we have more than 100 requests that complete or
> fail on a node before all statuses are polled by the client, the statuses are
> lost and the client will fail with an unexpected error similar to:
> {{Invalid status request for requestId: '{_}{_}' - 'notfound'. Retried
> __ times}}
>
> Instead of having a hard limit for the number of requests we track, we could
> have time based eviction. I think it makes sense to keep status of a request
> until a given timeout, and then drop it ignoring how many requests we
> currently track.
--
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-17340) Call to /solr/admin/info/system is abnormally slow
[
https://issues.apache.org/jira/browse/SOLR-17340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17340:
--
Labels: pull-request-available (was: )
> Call to /solr/admin/info/system is abnormally slow
> --
>
> Key: SOLR-17340
> URL: https://issues.apache.org/jira/browse/SOLR-17340
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.6
>Reporter: Pierre Salagnac
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Solr endpoint {{/solr/admin/info/system}} is used to return some generic
> system metrics (memory, JVM...)
> This endpoint is also used by {{solr-operator}} by default for start-up probe
> and liveness probe. (details
> [here|https://github.com/apache/solr-operator/blob/5fec11f8ef181a58b1f72123b44ae6532c49b62d/controllers/util/solr_security_util.go#L44]).
> Very long runtime can cause failures of the probes.
> Runtime is abnormally slow because of the time spent in introspecting beans
> to create {{BeanInfo}} instances. Most of the time is spent here:
> {code}
> java.lang.Exception: Stack trace
> at
> java.desktop/java.beans.Introspector.getBeanInfo(Introspector.java:279)
> at
> org.apache.solr.util.stats.MetricUtils.addMXBeanMetrics(MetricUtils.java:777)
> at
> org.apache.solr.util.stats.MetricUtils.addMXBeanMetrics(MetricUtils.java:841)
> at
> org.apache.solr.handler.admin.SystemInfoHandler.getSystemInfo(SystemInfoHandler.java:223)
> at
> org.apache.solr.handler.admin.SystemInfoHandler.handleRequestBody(SystemInfoHandler.java:156)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:248)
> at org.apache.solr.handler.admin.InfoHandler.handle(InfoHandler.java:96)
> at
> org.apache.solr.handler.admin.InfoHandler.handleRequestBody(InfoHandler.java:84)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:248)
> {code}
> There is no need to execute the bean introspection at each call. We could
> lazily instantiate them and keep them in memory for efficiency.
> Note: I haven't been able to figure out the exact cause, but the runtime can
> exponentially increase under heady querying load.
--
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-17322) Make RankQuery.getTopDocsCollector use covariant generic types
[
https://issues.apache.org/jira/browse/SOLR-17322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17322:
--
Labels: pull-request-available (was: )
> Make RankQuery.getTopDocsCollector use covariant generic types
> --
>
> Key: SOLR-17322
> URL: https://issues.apache.org/jira/browse/SOLR-17322
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 9.0, 9.1, 9.2, 9.1.1, 9.3, 9.2.1, 9.4, 9.5, 9.4.1, 9.6,
> 9.6.1
>Reporter: Stephen Woods
>Assignee: Christine Poerschke
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 9.7
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently, rank queries can only use TopDocsCollectors that operate on
> ScoreDocs.
> TopDocsCollector has a class signature of:
> {code:java}
> public abstract class TopDocsCollector implements
> Collector {code}
> It contains a single covariant generic type T, which allows the collection of
> not only ScoreDocs, but subclasses of ScoreDocs as well (in the event
> additional information needs to be collected per document during the
> collection process).
> SOLR-15385 involved a large commit that removed raw types from much of the
> Solr code base. As part of that work, RankQuery was modified so that the
> getTopDocsCollector method no longer returns a raw TopDocsCollector but
> instead returns a TopDocsCollector of invariant ScoreDocs. Unfortunately, by
> doing so, it is no longer possible to use custom TopDocsCollectors that
> operate on types that extend ScoreDoc in rank queries; they _only_ work with
> ScoreDocs. Any attempt to use a class other than ScoreDoc will result in a
> compilation error.
> The fix for this issue is very simple: Modify the method signature from:
> {code:java}
> public abstract TopDocsCollector getTopDocsCollector(
> int len, QueryCommand cmd, IndexSearcher searcher) throws IOException;
> {code}
> to
> {code:java}
> public abstract TopDocsCollector getTopDocsCollector(
> int len, QueryCommand cmd, IndexSearcher searcher) throws IOException;
> {code}
> The call site for this method, within
> SolrIndexSearcher.buildTopDocsCollector, already uses this type signature.
--
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-17106) LBSolrClient: Make it configurable to remove zombie ping checks
[ https://issues.apache.org/jira/browse/SOLR-17106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17106: -- Labels: pull-request-available (was: ) > LBSolrClient: Make it configurable to remove zombie ping checks > --- > > Key: SOLR-17106 > URL: https://issues.apache.org/jira/browse/SOLR-17106 > Project: Solr > Issue Type: Improvement >Reporter: Aparna Suresh >Priority: Minor > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Following discussion from a dev list discussion here: > [https://lists.apache.org/thread/f0zfmpg0t48xrtppyfsmfc5ltzsq2qqh] > The issue involves scalability challenges in SolrJ's *LBSolrClient* when a > pod with numerous cores experiences connectivity problems. The "zombie" > tracking mechanism, operating on a core basis, becomes a bottleneck during > distributed search on a massive multi shard collection. Threads attempting to > reach unhealthy cores contribute to a high computational load, causing > performance issues. > As suggested by Chris Hostetter: LBSolrClient could be configured to disable > zombie "ping" checks, but retain zombie tracking. Once a replica/endpoint is > identified as a zombie, it could be held in zombie jail for X seconds, before > being released - hoping that by this timeframe ZK would be updated to mark > this endpoint DOWN or the pod is back up and CloudSolrClient would avoid > querying it. In any event, only 1 failed query would be needed to send the > server back to zombie jail. > > There are benefits in doing this change: > * Eliminate the zombie ping requests, which would otherwise overload pod(s) > coming up after a restart > * Avoid memory leaks, in case a node/replica goes away permanently, but it > stays as zombie forever, with a background thread in LBSolrClient constantly > pinging it -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17337) Display all custom distributed stages in debug output
[
https://issues.apache.org/jira/browse/SOLR-17337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17337:
--
Labels: pull-request-available (was: )
> Display all custom distributed stages in debug output
> -
>
> Key: SOLR-17337
> URL: https://issues.apache.org/jira/browse/SOLR-17337
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 9.6.1
>Reporter: Torsten Bøgh Köster
>Priority: Major
> Labels: pull-request-available
> Attachments: solr_debug_custom_stage.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When showing {{track}} debug for custom stages in distributed requests, the
> stage id is not translated into a meaningful string. It is displayed as an
> empty string (see attachment). Furthermore, if you have multiple custom
> stages, the details for the most recent stage is displayed. The details for
> other stages is omitted.
> !solr_debug_custom_stage.png!
> We'll provide a GitHub PRs to address both issues.
--
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-14673) Add CLI for Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-14673:
--
Labels: pull-request-available (was: )
> Add CLI for Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-14673.patch, SOLR-14673.patch, SOLR-14673.patch,
> SOLR-14673.patch, SOLR-14673.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This ticket will provide a simple CLI that will run a Streaming Expression
> from the command line and return the results as a delimited result set. This
> will allow Streaming Expressions to be used from the command line to extract
> data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr expr_file{code}
> This will run the expression in _expr_file_.
> Output will be to standard out as delimited records.
> *Standard-In, Standard-out and Pipe Composition.*
> The CLI can read from *standard-in* and write to *standard-out* in delimited
> records. This allows Streaming Expressions to be composed using unix pipes
> with other command line tools and other streaming expressions. Example syntax:
> {code:java}
> cat data.csv | ./bin/expr load.expr {code}
> The load.expr file uses the *stndin()* function to read from standard-in and
> load date to Solr. Here is a sample load.expr
> {code:java}
> let(cli-zkhost="localhost:9983",
>
> update(collection1,
>parseCSV(stndin()))
> {code}
> In the example above the *let* expression is used to set the *cli-zkhost* and
> then run the Streaming Expression:
> {code:java}
> update(collection1,
>parseCSV(stndin()){code}
> The *stndin* function reads the data from standard-in. The *parseCSV*
> function parses the lines into tuples and the *update* function sends the
> data to collection1 for indexing.
>
> *Querying Solr and Pipe Composition*
> The CLI can also be used to query Solr and pipe the result to other
> applications on the command line. This can automate activities like alerting,
> data backup, replication etc...
>
>
>
>
--
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-17368) TestPrometheusResponseWriter redesign
[ https://issues.apache.org/jira/browse/SOLR-17368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17368: -- Labels: pull-request-available (was: ) > TestPrometheusResponseWriter redesign > - > > Key: SOLR-17368 > URL: https://issues.apache.org/jira/browse/SOLR-17368 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Chris M. Hostetter >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > TestPrometheusResponseWriter currently fails in 100% of all jenkins builds > due to how it is designed, and depending on what other tests may run before > it in the same JVM. > This problem only affects the test, not the functionality of the underlying > code. > See SOLR-10654 for background discussions of the problems with this test, and > options for improving it's design relative to it's purpose. -- 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-17285) Move RemoteSolrException to SolrClient in v10
[ https://issues.apache.org/jira/browse/SOLR-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17285: -- Labels: newdev pull-request-available (was: newdev) > Move RemoteSolrException to SolrClient in v10 > - > > Key: SOLR-17285 > URL: https://issues.apache.org/jira/browse/SOLR-17285 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Reporter: David Smiley >Priority: Major > Labels: newdev, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > RemoteSolrException lives in BaseHttpSolrClient. BaseHttpSolrClient should > be deprecated; it's sort of replaced by HttpSolrClientBase. Even though this > exception is only for Http, SolrClient is a decent parent class. Or make top > level. > To make this transition from 9x to 10x better, we could simply add new > classes without removing the old ones in 9x. The old can subclass the new. > Eventually all of BaseHttpSolrClient will be removed. -- 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-17298) Multithreaded search breaks limits, and possibly other things
[
https://issues.apache.org/jira/browse/SOLR-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17298:
--
Labels: pull-request-available (was: )
> Multithreaded search breaks limits, and possibly other things
> -
>
> Key: SOLR-17298
> URL: https://issues.apache.org/jira/browse/SOLR-17298
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: main (10.0), 9.7, 9x
>Reporter: Gus Heck
>Priority: Blocker
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://issues.apache.org/jira/browse/SOLR-13350 was merged to main somewhat
> unexpectedly, and then back-ported to 9x without any response to feedback
> from multiple committers, including feedback that
> * By turning it on by default, it breaks the recently released CPU limits
> (as shown by changes to unit tests).
> * Incompatibility with timeAllowed, cpuTimeAllowed, segmentTerminateEarly,
> GraphQuery, RankQuery and JoinQuery was not clearly documented
> * The code presents a possibility for users to receive a non-numeric max
> score ("NaN").
> I have not verified it yet, but I would also be worried about the health of
> CPU time logging to be added in
> https://issues.apache.org/jira/browse/SOLR-16986 after this change.
> Given that:
> * Some of the above issues represent back compatibility breaks or potential
> back compatibility breaks for released features
> * The decision to break compatibility within the 9x release series deserves
> a formal vote (or a fix).
> * There has been no communication/response from the committer who merged
> these changes since May 6 (aside from the backport to 9x on May 13) it seems
> that this state may persist for some time.
> Therefore it appears necessary to file this issue to ensure anything but a
> 9.6.1 is blocked until the above issues are sorted out. This ticket can serve
> as a parent ticket to whatever various solutions are agreed upon.
> Multi-threaded search is an awesome feature that has taken a very long time
> to be realized and is obviously desirable, but we have now placed ourselves
> in an awkward position by not resolving these last few issues before back
> porting.
--
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-17378) Add a RequestHandler metric for "number of outstanding concurrent requests"
[ https://issues.apache.org/jira/browse/SOLR-17378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17378: -- Labels: pull-request-available (was: ) > Add a RequestHandler metric for "number of outstanding concurrent requests" > --- > > Key: SOLR-17378 > URL: https://issues.apache.org/jira/browse/SOLR-17378 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Michael Gibney >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > "number of outstanding concurrent requests" is an important metric to track, > and can have a significant impact on resource usage and throughput. Existing > metrics provide a window into request count and request latency, but neither > of these is sufficient to supply the desired "concurrency" metric. > Leveraging request latency and completed request timestamp, it's possible to > retroactively compute outstanding concurrent requests, but existing metrics > are incapable of capturing this information directly or presenting it in an > aggregate format. > In addition to the implications for performance, it is important to have a > window into request concurrency to complement the solr rate limiting feature, > whose "slot acquisition" design really limits request concurrency, _not_ (as > the name implies) request count/throughput. -- 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-17359) Make SolrCLI handle arg parsing of zk sub commands
[
https://issues.apache.org/jira/browse/SOLR-17359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17359:
--
Labels: pull-request-available (was: )
> Make SolrCLI handle arg parsing of zk sub commands
> --
>
> Key: SOLR-17359
> URL: https://issues.apache.org/jira/browse/SOLR-17359
> Project: Solr
> Issue Type: Sub-task
> Components: scripts and tools
>Reporter: Jan Høydahl
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Both bin/solr and bin/solr.cmd have lots of shell code to parse the zk sub
> commands, and to print the usage text. We have both a short zk uage text and
> the full one.
> {code:java}
> Usage: solr zk upconfig|downconfig -d -n [-z zkHost]
> [-s solrUrl]"
>solr zk cp [-r] [-z zkHost] [-s solrUrl]"
>solr zk rm [-r] [-z zkHost] [-s solrUrl]"
>solr zk mv [-z zkHost] [-s solrUrl]"
>solr zk ls [-r] [-z zkHost] [-s solrUrl]"
>solr zk mkroot [-z zkHost] [-s solrUrl]"
>solr zk linkconfig --conf-name -c [-z zkHost]
> [-s solrUrl]"
>solr zk updateacls [-z zkHost] [-s solrUrl]" {code}
> Extend SolrCLI and tools API to handle sub commands more natively so that
> doing {{solr zk -h}} shows a list of sub commands, while `solr zk cp -h`
> shows usage for that sub command.
> I think commons-cli does not have native subcommand support like e.g.
> picocli, but it should be possible to implement..
--
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-17334) Minor bugs in Solr dedicated coordinator mode
[
https://issues.apache.org/jira/browse/SOLR-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17334:
--
Labels: pull-request-available (was: )
> Minor bugs in Solr dedicated coordinator mode
> -
>
> Key: SOLR-17334
> URL: https://issues.apache.org/jira/browse/SOLR-17334
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 9.6
>Reporter: Torsten Bøgh Köster
>Assignee: Noble Paul
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We recently put dedicated Solr coordinator nodes into production and stumbled
> upon some minor bugs/improvements:
> - The Solr root resource cannot be requested on a coordinator node
> - Coordinator requests are enabled for the {{/select}} handler only
> - From outside proxied and coordinator requests cannot be distinguished
> h3. Solr root resource
> We adopted a general fix from the {{HttpSolrCall}} to check whether the given
> {{collectionName}} is {{{}null{}}}. This fixes requesting the root resource
> (and maybe other similar requests)
> h3. {{/select}} handler only
> Coordinator requests are limited to the {{/select}} handler. In our
> environment we make heavy usage of pre-configured Solr handlers. We could not
> find any reason to limit coordinator calls to the {{/select}} handler and
> removed the limitation.
> h3. Coordinator requests cannot be identified by Solr response
> With any Solr response you cannot distinguish coordinator from proxied (or
> regular) requests. While this is great for consistency it makes testing extra
> hard. We added an extra Solr header field with the coordinator node name
> called {{requestCoordinatorNode}} when debug is enabled. This eases testing
> and debugging a lot.
>
> A Pull Request is in the making!
--
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-17319) Introduce support for Reciprocal Rank Fusion (combining queries)
[
https://issues.apache.org/jira/browse/SOLR-17319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17319:
--
Labels: pull-request-available (was: )
> Introduce support for Reciprocal Rank Fusion (combining queries)
>
>
> Key: SOLR-17319
> URL: https://issues.apache.org/jira/browse/SOLR-17319
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 9.6.1
>Reporter: Alessandro Benedetti
>Assignee: Alessandro Benedetti
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reciprocal Rank Fusion (RRF) is an algorithm that takes in input multiple
> ranked lists to produce a unified result set.
> Examples of use cases where RRF can be used include hybrid search and
> multiple Knn vector queries executed concurrently.
> RRF is based on the concept of reciprocal rank, which is the inverse of the
> rank of a document in a ranked list of search results.
> The combination of search results happens taking into account the position of
> the items in the original rankings, and giving higher score to items that
> are ranked higher in multiple lists. RRF was introduced the first time by
> Cormack et al. in [1].
> The syntax proposed:
> JSON Request
> {code:json}
> {
> "queries": {
> "lexical1": {
> "lucene": {
> "query": "id:(10^=2 OR 2^=1 OR 4^=0.5)"
> }
> },
> "lexical2": {
> "lucene": {
> "query": "id:(2^=2 OR 4^=1 OR 3^=0.5)"
> }
> }
> },
> "limit": 10,
> "fields": "[id,score]",
> "params": {
> "combiner": true,
> "combiner.upTo": 5,
> "facet": true,
> "facet.field": "id",
> "facet.mincount": 1
> }
> }
> {code}
> [1] Cormack, Gordon V. et al. “Reciprocal rank fusion outperforms condorcet
> and individual rank learning methods.” Proceedings of the 32nd international
> ACM SIGIR conference on Research and development in information retrieval
> (2009)
--
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-10808) Enable DocValues by default for all string/numeric/date fields, unless explicitly disabled
[ https://issues.apache.org/jira/browse/SOLR-10808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-10808: -- Labels: pull-request-available (was: ) > Enable DocValues by default for all string/numeric/date fields, unless > explicitly disabled > -- > > Key: SOLR-10808 > URL: https://issues.apache.org/jira/browse/SOLR-10808 > Project: Solr > Issue Type: Task >Reporter: Chris M. Hostetter >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > Spinning this idea off of SOLR-10803 where Uwe suggested it... > bq. I'd suggest to also enable DocValues by default for all > string/numeric/date fields, unless explicitly disabled. > This would be fairly easy to do -- we just bump up the "schema version" and > change the default for docValues in the affected FieldTypes (or perhaps in > PrimitiveFieldType? Just like OMIT_NORMS ? ... Need to think about that a bit > more.) -- 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-12963) change default for 'uninvertible' to 'false' (dependent on new schema 'version')
[
https://issues.apache.org/jira/browse/SOLR-12963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-12963:
--
Labels: pull-request-available (was: )
> change default for 'uninvertible' to 'false' (dependent on new schema
> 'version')
>
>
> Key: SOLR-12963
> URL: https://issues.apache.org/jira/browse/SOLR-12963
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-12963.patch
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> We should consider changing the default behavior of the {{uninvertible}}
> field option to be dependnt on the schema {{version}} property, such that
> moving forward the fields/fieldtypes will default to {{uninvertible ==
> false}} unless an explicit {{uninvertible=true}} is specified by the user.
> There are a lot of considerations regarding the existing behavior of
> functionality (like faceting) when the (effective) value of {{uninvertible}}
> is false because we move forward with changing this in a way that could
> suprise/confuse new users or existing users w/ long heald expectations that
> certain behavior would just "work" w/o understanding that was because of
> FieldCache/uninversion.
> See parent issue for more background/discussion.
--
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-16996) Move Prometheus CLI to commons-cli
[ https://issues.apache.org/jira/browse/SOLR-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16996: -- Labels: pull-request-available (was: ) > Move Prometheus CLI to commons-cli > -- > > Key: SOLR-16996 > URL: https://issues.apache.org/jira/browse/SOLR-16996 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: Alex Deparvu >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > During review of SOLR-16980 we found out that the prometheus CLI is based on > argparse4j library. > Ror consistency across all CLI code it would be much better if this would be > based on commons-cli. -- 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-17381) Make CLUSTERSTATUS request configurable
[
https://issues.apache.org/jira/browse/SOLR-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17381:
--
Labels: pull-request-available (was: )
> Make CLUSTERSTATUS request configurable
> ---
>
> Key: SOLR-17381
> URL: https://issues.apache.org/jira/browse/SOLR-17381
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Aparna Suresh
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Fetching {{CLUSTERSTATUS}} remotely is resource-intensive and should be done
> with caution. Currently, if no parameters are specified, the call returns all
> information, including collections, shards, replicas, aliases, cluster
> properties, roles, and more. This can have significant performance
> implications for clients using a Solr cluster with thousands of collections.
> Several performance [issues|https://issues.apache.org/jira/browse/SOLR-14985]
> have been identified when switching {{CloudSolrClient}} to use HTTP-based
> CSP, particularly in two instances where the entire cluster state is fetched
> unnecessarily.
> *Proposal:* Modify the requests to retrieve only the necessary information,
> such as the cluster status for a specific collection, live nodes, or cluster
> properties. Ensure these changes maintain backward compatibility.
> Additionally, update the HTTP CSP to reflect these optimizations.
--
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-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-14414:
--
Labels: pull-request-available (was: )
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Affects Versions: 9.0
>Reporter: Marcus Eagan
>Priority: Major
> Labels: pull-request-available
> Attachments: QueryUX-SolrAdminUIReboot.mov
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
> Discussion in mailing list:
> https://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAF76exK-EB_tyFx0B4fBiA%3DJj8gH%3Divn2Uo6cWvMwhvzRdA3KA%40mail.gmail.com%3E
--
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-17386) it's now impossible to update solrconfig for coordinators after core creation
[ https://issues.apache.org/jira/browse/SOLR-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17386: -- Labels: pull-request-available (was: ) > it's now impossible to update solrconfig for coordinators after core creation > - > > Key: SOLR-17386 > URL: https://issues.apache.org/jira/browse/SOLR-17386 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 9.7 >Reporter: ella eln >Priority: Critical > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > since solr-17269 the coordinators are not managed by a collection and it's > impossible to update their configuration after core creation. (before the > change, it was possible to reload the synthetic collection, but not > anymore...) > I've been working on solr-17385 trying to add a feature to solr's > coordinators, and i'm pretty sure if found a bug > > It's relatively easy to recreate: * run 2 solr nodes, one coordinator and one > data. > * create a collection on one the data node and add a coordinator to it by > running a /select request. you can index a document to make it easyer to see > the issue. > * then make a change to your configuration and reload the collection (for > example add a costume fl for testing to /select. I added name="fl">id,test_s:[value v="test2"]) > * then make a few /select requests from the coordinator and see that the > configuration changes are not applied. If you do the same request from the > data node it will work as expected > > I'm pretty sure it was added in SOLR-17269, there was an improvement made to > the coordinator query answering flow that inadvertently lead to a state in > which the configuration on the coordinators could never be updated/changed > through reload/requests. This happened because it's not verifying it's > configuration against the zookeeper anymore after the core has been created, > it used to be managed by a synthetic collection but that was removed. But i > might be wrong about that. > > It's about to be added to solr 9.7, so I hope to save some time and energy > for everyone involved by reporting this as early as possible -- 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-17320) HttpShardHandler should obey `timeAllowed` parameter in query
[ https://issues.apache.org/jira/browse/SOLR-17320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17320: -- Labels: pull-request-available (was: ) > HttpShardHandler should obey `timeAllowed` parameter in query > - > > Key: SOLR-17320 > URL: https://issues.apache.org/jira/browse/SOLR-17320 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: query, SolrCloud >Affects Versions: main (10.0), 9.6.1 >Reporter: Hitesh Khamesra >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > HttpShardHandler should use `timeAllowed` param in query to timeout for any > shard response. We have observed that sometime different shard takes > different time to process the query. In those cases, if user has specify > timeAllowed, then solr should use that time to return any partial response. > i have added the patch for it. [https://github.com/apache/solr/pull/2493] -- 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-17158) Terminate distributed processing quickly when query limit is reached
[ https://issues.apache.org/jira/browse/SOLR-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17158: -- Labels: pull-request-available (was: ) > Terminate distributed processing quickly when query limit is reached > > > Key: SOLR-17158 > URL: https://issues.apache.org/jira/browse/SOLR-17158 > Project: Solr > Issue Type: Sub-task > Components: Query Limits >Reporter: Andrzej Bialecki >Assignee: Gus Heck >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Solr should make sure that when query limits are reached and partial results > are not needed (and not wanted) then both the processing in shards and in the > query coordinator should be terminated as quickly as possible, and Solr > should minimize wasted resources spent on eg. returning data from the > remaining shards, merging responses in the coordinator, or returning any data > back to the user. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17102) VersionBucket not needed
[ https://issues.apache.org/jira/browse/SOLR-17102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17102: -- Labels: pull-request-available (was: ) > VersionBucket not needed > > > Key: SOLR-17102 > URL: https://issues.apache.org/jira/browse/SOLR-17102 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > > SolrCloud ensures that updates for the same document ID are done in the > correct order internally in the face of possible re-orders during replication > / log replay. In order to ensure the updates are applied consecutively, a > lock is held on a hash of the ID for the doc. A hash is used to limit the > number of total locks because the locks are pre-created in advance for the > core (numVersionBuckets == 65k by default). The memory is non-negligible > with many cores, and it introduces the possibility of collisions, especially > at lower bucket counts if you configure it much lower. > Here I propose doing away with a pre-created hashed bucket strategy. > Instead, I propose more simply creating and GC'ing a lock per update being > processed, and using a ConcurrentHashMap to hold those in-flight. This > strategy is already used in > org.apache.solr.util.OrderedExecutor.SparseStripedLock, more or less. > Doing this is more tractable now that VersionBucket only holds a lock, not a > version anymore – SOLR-17036 > The biggest challenge is that the code calls for the ability to use a > Condition to away/notify, which means the solution can't just re-use > SparseStripedLock above nor be quite so simple. -- 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-17276) Use fixed rate instead of fixed delay in prometheus-exporter
[ https://issues.apache.org/jira/browse/SOLR-17276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17276: -- Labels: pull-request-available (was: ) > Use fixed rate instead of fixed delay in prometheus-exporter > > > Key: SOLR-17276 > URL: https://issues.apache.org/jira/browse/SOLR-17276 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Reporter: Rafał Harabień >Priority: Minor > Labels: pull-request-available > Attachments: image-2024-05-06-18-10-30-739.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Prometheus-exporter is supposed to read metrics from Solr servers every 60 > seconds (scrape interval can be changed using --scrape-interval argument). > But the truth is it does it every 60+X seconds where X is the time needed to > read metrics from all Solr servers. In my case X is 1-2 s. If Prometheus > scrapes the exporter every 60 seconds it can lead to duplicated samples (e.g. > metrics will stay the same for 2 minutes). > !image-2024-05-06-18-10-30-739.png! > It's result of using > [scheduler.scheduleWithFixedDelay|https://github.com/apache/solr/blob/2bb2ada0a372f4d101b78df8d43e0fc44c8edbf3/solr/prometheus-exporter/src/java/org/apache/solr/prometheus/collector/SchedulerMetricsCollector.java#L77] > instead of > scheduler.scheduleAtFixedRate. > Note: function scheduled with scheduleAtFixedRate can still be started late > if previous execution has not finished. There is no risk of overlapping > executions. > I am going to prepare a PR. -- 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-17187) Make replica poll interval configurable
[ https://issues.apache.org/jira/browse/SOLR-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17187: -- Labels: pull-request-available (was: ) > Make replica poll interval configurable > --- > > Key: SOLR-17187 > URL: https://issues.apache.org/jira/browse/SOLR-17187 > Project: Solr > Issue Type: Improvement > Components: replication (java), SolrCloud >Reporter: Torsten Bøgh Köster >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > In TLOG/PULL replica setups with longer commit intervals it would be great to > configure the interval to check for new commits manually to tune to your > setup. > Currently on the PULL replica the interval to check for new commits is > computed using the commit / soft commit settings [1] > [1] > https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cloud/ReplicateFromLeader.java#L83-L87 -- 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-10654) Expose Metrics in Prometheus format DIRECTLY from Solr
[
https://issues.apache.org/jira/browse/SOLR-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-10654:
--
Labels: pull-request-available (was: )
> Expose Metrics in Prometheus format DIRECTLY from Solr
> --
>
> Key: SOLR-10654
> URL: https://issues.apache.org/jira/browse/SOLR-10654
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Keith Laban
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.7
>
> Attachments: prometheus_metrics.txt
>
> Time Spent: 7.5h
> Remaining Estimate: 0h
>
> Expose metrics via a `wt=prometheus` response type.
> Example scape_config in prometheus.yml:
> {code:java}
> scrape_configs:
> - job_name: 'solr'
> metrics_path: '/solr/admin/metrics'
> params:
> wt: ["prometheus"]
> static_configs:
> - targets: ['localhost:8983']
> {code}
> [Rationale|https://issues.apache.org/jira/browse/SOLR-11795?focusedCommentId=17261423&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17261423]
> for having this despite the "Prometheus Exporter". They have different
> strengths and weaknesses.
--
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-17391) Optimize Backup/Restore Operations for Large Collections
[
https://issues.apache.org/jira/browse/SOLR-17391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17391:
--
Labels: pull-request-available (was: )
> Optimize Backup/Restore Operations for Large Collections
>
>
> Key: SOLR-17391
> URL: https://issues.apache.org/jira/browse/SOLR-17391
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 9.4, 9.5, 9.4.1, 9.6, 9.6.1
>Reporter: Hakan Özler
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The backup/restore performance issue was first reported on [the users
> mailing|https://lists.apache.org/thread/ssmzg5nhhxdhgz4980opn1vzxs81o9pk]
> list.
>
> We're experiencing performance issues in the recent Solr versions — 9.5.0 and
> 9.6.1 — regarding backup and restore. In 9.2.1, we could take a backup of
> 10TB data in just 1 and a half hours. Currently, as of 9.5.0, taking a backup
> of the collection takes 7 hours! We're unable to make use of disaster
> recovery effectively and reliably in Solr. Therefore, Solr 9.2.1 still
> remains the most effective choice among the other 9.x versions for our use.
> It seems that this is the ticket causing this issue:
> 1. https://issues.apache.org/jira/browse/SOLR-16879
> Interestingly, we never encountered a throttling problem during operations
> when this was introduced to be solved based on this argument on 9.2.1. From a
> devops perspective, we have some details and metrics on these tasks to
> distinguish the difference between two versions. The overall IOPS was 150MB
> on 9.6.1, while IOPS was 500MB on 9.2.1 during the same backup and restore
> tasks. In the first below, the peak on the left represents a backup, in
> contrast, in the 2nd image, the same backup operation in 9.5.0 uses less
> resource. As you may spot, 9.5.0 seems to be using a fifth of the resources
> of 9.2.1.
>
> !https://i.imgur.com/aSrs8OM.png!
> Image 1.
> !https://i.imgur.com/aSrs8OM.png!
> Image 2.
>
> Apart from that, monitoring some relevant metrics during the operations, I
> had some difficulty interpreting the following metrics:
> {code:java}
> ADMIN./admin/cores.threadPool.parallelCoreExpensiveAdminExecutor.pool.core: 0,
> ADMIN./admin/cores.threadPool.parallelCoreExpensiveAdminExecutor.pool.max: 5,
> ADMIN./admin/cores.threadPool.parallelCoreExpensiveAdminExecutor.pool.size: 1,
> ADMIN./admin/cores.threadPool.parallelCoreExpensiveAdminExecutor.running:
> 1,{code}
> The pool size was 1 although the pool max size is 5. Shouldn't the pool size
> be 5, instead? However, there is always one task running on a single node,
> not 5 concurrently, if I'm not mistaken.
> I was also wondering if the max thread size, which is currently 5 in 9.4+,
> could be configurable with either an environment variable or Java parameter?
> The part that needs to be changed seems to be in CoreAdminHandler.java on
> line 446 [1] I've made a small adjustment to add a Solr parameter called
> `solr.maxExpensiveTaskThreads` for those who want to set a different thread
> size for expensive tasks. The number given in this parameter must meet the
> criteria of ThreadPoolExecutor, otherwise IllegalArgumentException will
> occur. I've generated a patch [2] and I would love to see if someone from the
> Solr committers would take on this and apply for the upcoming release. Do you
> think our observation is accurate and would this patch be feasible to
> implement?
>
> 1.
> [https://github.com/apache/solr/commit/82a847f0f9af18d6eceee18743d636db7a879f3e#diff-5bc3d44ca8b189f44fe9e6f75af8a5510463bdba79ff72a7d0ed190973a32533L446]
> 2. [https://gist.github.com/ozlerhakan/e4d11bddae6a2f89d2c212c220f4c965]
>
> Follow up on this, we managed to backup a data of 3TB in 50 minutes with the
> patch using `solr.maxExpensiveTaskThreads=5` :
>
> !https://i.imgur.com/oeCrhLn.png|width=626,height=239!
>
> I also answered the questions from @Kevin Liang ,
> {quote}Was this change tested on a cloud that was also taking active
> ingest/query requests as the same time as the backup?
> {quote}
> The test is completed in a SolrCloud 9.6.1 + the patch cluster managed by the
> official Solr operator on Amazon EKS. The backup strategy is not intended to
> happen frequently. Instead, we plan to take some backups for a certain period
> of time, therefore we won't expect intense search traffic in and out during
> backups.
>
> {quote}This performance is really exciting, but I'm curious how much burden
> it puts on CPU and memory.
> {quote}
> I'd say that Solr was pretty relaxed during the test based on the CPU usage.
> It looks like backup and
[jira] [Updated] (SOLR-17394) IndexFetcher should inspect HTTP status codes on its requests
[ https://issues.apache.org/jira/browse/SOLR-17394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17394: -- Labels: pull-request-available (was: ) > IndexFetcher should inspect HTTP status codes on its requests > - > > Key: SOLR-17394 > URL: https://issues.apache.org/jira/browse/SOLR-17394 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) >Affects Versions: main (10.0), 9.6.1 >Reporter: Jason Gerlowski >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Typically, SolrJ will look at the HTTP status code of a response and it will > throw exceptions as appropriate (see > [here|https://github.com/apache/solr/blob/988e9e3c2666784638475f4cd4827bc2fe77c707/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClientBase.java#L187-L217]). > But it skips this logic if users have elected to parse the response > themselves by use of an "InputStreamResponseParser". > Solr's IndexFetcher uses this "InputStreamResponseParser" so that it can > access the binary index data in the HTTP response. But it doesn't check the > status code of responses as it should. > IndexFetcher will typically notice that the response is unexpected and can > retry and ultimately succeed, but this happens relatively late in the > process. And that delay can be very expensive in many cases. For instance: > When IndexFetcher gets a "filecontent" response, it expects the first few > bytes to indicate the size of the binary response. So it [reads these bytes > and instantiates a byte-array of the indicated > size|https://github.com/apache/solr/blob/988e9e3c2666784638475f4cd4827bc2fe77c707/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L1836C1-L1847]. > But if IndexFetcher happens to be reading a 404 response, the first few > bytes of the response will be the '*<*', '*h*', '*e*', and '*a*' characters > from the "*" tag that Solr uses to begin all its HTML errors. This > leads to IndexFetcher allocating a massive > 1GB byte-array! This can cause > GC churn in production and (for me at least) was causing test runs to > frequently OOM on certain machines. > We should have IndexFetcher (and other places that use > InputStreamResponseParser) check the response status code as soon as its > available and handle errors accordingly. -- 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-17253) Release wizard suggests wrong minor version for jira
[ https://issues.apache.org/jira/browse/SOLR-17253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17253: -- Labels: pull-request-available (was: ) > Release wizard suggests wrong minor version for jira > > > Key: SOLR-17253 > URL: https://issues.apache.org/jira/browse/SOLR-17253 > Project: Solr > Issue Type: Bug > Components: release-scripts >Reporter: Gus Heck >Priority: Trivial > Labels: pull-request-available > Attachments: image-2024-04-22-22-50-48-502.png > > Time Spent: 10m > Remaining Estimate: 0h > > Our convention is normally to use M.N not M.N.0 for minor releases in jira, > yet this is the advice the release wizard gives: > !image-2024-04-22-22-50-48-502.png! -- 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-17245) Use downloads rather than archive for checking KEYS file in release wizard
[ https://issues.apache.org/jira/browse/SOLR-17245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17245: -- Labels: pull-request-available (was: ) > Use downloads rather than archive for checking KEYS file in release wizard > -- > > Key: SOLR-17245 > URL: https://issues.apache.org/jira/browse/SOLR-17245 > Project: Solr > Issue Type: Improvement > Components: release-scripts >Reporter: Gus Heck >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Archives are synced from downloads, but only daily, so a new release manager > that needs to update KEYS is unnecessarily delayed. The presence of a key in > the KEYS file on downloads.apache.org prior to uploading release ensures that > the key will exist on the archives no later than the release since both will > get synchronized at the same time (worst case) -- 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-17249) Lack of clarity in branch protection instructions in releaseWizard
[
https://issues.apache.org/jira/browse/SOLR-17249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17249:
--
Labels: pull-request-available (was: )
> Lack of clarity in branch protection instructions in releaseWizard
> --
>
> Key: SOLR-17249
> URL: https://issues.apache.org/jira/browse/SOLR-17249
> Project: Solr
> Issue Type: Improvement
> Components: release-scripts
>Reporter: Gus Heck
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since the branch is already made for 9.6 that step in checklist 3 has to be
> manually walked through (omitting the actual branch creation command). At the
> end it indicates that the branch should be protected, but he branch_9x (and
> 9_6) don't have a branch protection section in .asf.yml and I somewhat
> suspect that it's the main branch one that needs to be edited, but that's
> unclear from the instructions:
> {code:java}
> In our case we'll create branch_9_6.
> Also edit `.asf.yaml` to add the new branch under `protected_branches`.
> Run these commands to create a release branch
> cd ~/.solr-releases/9.6.0/solr
> git checkout branch_9x
> git pull --ff-only
> # This command should fail with exit code 2 to verify branch branch_9_6
> does not already exist
> git ls-remote --exit-code --heads origin branch_9_6
> git checkout -b branch_9_6
> git push --set-upstream origin branch_9_6
> # Add the new branch branch_9_6 under `protected_branches` in `.asf.yaml`.
> An editor will open.
> /usr/bin/nano .asf.yaml
> git add .asf.yaml && git commit -m "Add branch protection for branch_9_6"
> && git push
> {code}
> Either this is simply not yet available in 9_x or... there's an undocumented
> branch switch necessary here
> Compare
> [https://github.com/apache/solr/blob/main/.asf.yaml]
> ([https://github.com/apache/solr/blob/3cc92cf7fecffe45c727f26fc299e1ab3d1b3f20/.asf.yaml)]
> vs
> [https://github.com/apache/solr/blob/branch_9_6/.asf.yaml]
> ([https://github.com/apache/solr/blob/6a2294db8ec1f4ecf21ec0f5b9bb3430ce6825e6/.asf.yaml])
>
> Not sure the solution or even 100% sure this is an actual problem because
> I've got an exceptional case from the branch already existing... but I'm
> filing this so it can be investigated.
--
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-17295) The downloads page should link to our OpenAPI spec artifact
[ https://issues.apache.org/jira/browse/SOLR-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17295: -- Labels: good-first-issue newdev pull-request-available (was: good-first-issue newdev) > The downloads page should link to our OpenAPI spec artifact > --- > > Key: SOLR-17295 > URL: https://issues.apache.org/jira/browse/SOLR-17295 > Project: Solr > Issue Type: Improvement > Components: website >Reporter: Jan Høydahl >Priority: Major > Labels: good-first-issue, newdev, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We now publish OpenAPI spec in our downloads section: > [https://downloads.apache.org/solr/solr/9.6.0/openApi/] > > We should link to this on the website download page at > [https://solr.apache.org/downloads] > PR will be done against [https://github.com/apache/solr-site] -- 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-17396) Reduce thread contention in ZkStateReader.getCollectionProperties()
[
https://issues.apache.org/jira/browse/SOLR-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17396:
--
Labels: pull-request-available (was: )
> Reduce thread contention in ZkStateReader.getCollectionProperties()
> ---
>
> Key: SOLR-17396
> URL: https://issues.apache.org/jira/browse/SOLR-17396
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Aparna Suresh
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Building on
> [https://github.com/apache/solr/pull/2585|PR|https://github.com/apache/solr/pull/2585%7CPR]
> which delegated Collection Properties Management to
> {{{}CollectionPropertiesZkStateReader{}}}, this PR seeks to minimize thread
> contention within {{{}CollectionPropertiesZkStateReader{}}}.
> Proposal:
> * Use collection level locking where relevant instead of synchronizing on
> "watchedCollectionProperties"
> * With the double checked locking implemented in
> CollectionPropertiesZkStateReader, the scope of the synchronized (this) will
> be reduced to collection property operations, and no longer be in contention
> with the synchronization of unrelated operations on ZkStateReader.
>
--
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-17397) Skip atomic updates for non-existent child documents
[
https://issues.apache.org/jira/browse/SOLR-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17397:
--
Labels: pull-request-available (was: )
> Skip atomic updates for non-existent child documents
>
>
> Key: SOLR-17397
> URL: https://issues.apache.org/jira/browse/SOLR-17397
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Tim Owen
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have an update processor that allows skipping updates for non-existent
> documents, {{SkipExistingDocumentsUpdateProcessor}} but this does not
> currently handle atomic updates to child documents. So the update is passed
> through and then fails because {{AtomicUpdateDocumentMerger}} throws an
> exception if it cannot find the child document (leading to a 500 response
> from Solr)
--
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-17399) Replace the use of the deprecated java.util.Locale constructor with Locale Builder API
[
https://issues.apache.org/jira/browse/SOLR-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17399:
--
Labels: pull-request-available (was: )
> Replace the use of the deprecated java.util.Locale constructor with Locale
> Builder API
> --
>
> Key: SOLR-17399
> URL: https://issues.apache.org/jira/browse/SOLR-17399
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.8
>Reporter: Sanjay Dutt
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Replace the usage of {{Locale}} constructors with the {{Locale.Builder}} API,
> as we are upgrading to Java 21 where {{Locale}} constructors are deprecated
> starting from JDK 19. This change is motivated by the discussion in
> [https://github.com/apache/lucene/pull/12761]
>
--
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-15152) Export Tool should export nested docs cleanly in .json, .jsonl, and javabin
[ https://issues.apache.org/jira/browse/SOLR-15152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-15152: -- Labels: NestedDocuments pull-request-available (was: NestedDocuments) > Export Tool should export nested docs cleanly in .json, .jsonl, and javabin > --- > > Key: SOLR-15152 > URL: https://issues.apache.org/jira/browse/SOLR-15152 > Project: Solr > Issue Type: Improvement > Components: SolrCLI >Affects Versions: 8.8 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > Labels: NestedDocuments, pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > ExportTool doesn't properly handle anonymous child docs or nested docs. It > also confuses the JSONL format with the JSON format. > I'd like to have the JSON Lines format output as .jsonl, which is the > standard, and have the JSON format to be a .json, which is the same output as > if you wanted to post a Solr doc as a JSON to upload the data... This will > let us round trip the data. -- 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-17405) Zookeeper session can be re-established by multiple threads concurrently
[
https://issues.apache.org/jira/browse/SOLR-17405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17405:
--
Labels: pull-request-available (was: )
> Zookeeper session can be re-established by multiple threads concurrently
>
>
> Key: SOLR-17405
> URL: https://issues.apache.org/jira/browse/SOLR-17405
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.11, 9.6
>Reporter: Pierre Salagnac
>Priority: Major
> Labels: pull-request-available
> Attachments: stack.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Because of a bug in SolrCloud, the Zookeeper session can be re-established by
> multiple threads concurrently when an expiration occurs.
> This portion of the code assumes it is mono-threaded. Because of the bug, the
> last thread re-establishing the session can waif for 30 seconds per core,
> waiting for it to be marked {{DOWN}} while it was previously marked
> {{ACTIVE}} by another thread. With a high number of cores, the Solr server
> can hang for hours before taking traffic again.
> Following exception shows two threads were reestablishing the session
> concurrently. {{ZkController.createEphemeralLiveNode()}} should never be
> invoked twice for the same Zookeeper session.
> {code:java}
> thrown: java. lang.RuntimeException:
> org.apache.solr.common.cloud.ZooKeeperException:
> at
> org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:178)
> at org.apache.solr. common.cloud.DefaultConnectionStrategy.
> reconnect(DefaultConnectionStrategy.java:57)
> at
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:152)
> at org.apache.
> zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:535)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:510)
> Caused by: org.apache.solr.common.cloud.ZooKeeperException:
> at
> org.apache.solr.cloud.ZkController$1.command(ZkController.java:462)
> at
> org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:170)
> ... 4 more
> Caused by: org.apache. zookeeper.KeeperException$NodeExistsException.
> KeeperErrorCode = NodeExists
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:
> 126)
> at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1925)
> at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:1830)
> at
> org.apache.solr.common.cloud.SolrZkClient.lambda$multi$11(SolrZkClient.java:666)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retry0peration(ZkCmdExecutor.java:71)
> at
> org.apache.solr.common.cloud.SolrZkClient.multi(SolrZkClient.java:666)
> at org.apache.sol.cloud.ZkController
> CreateEphemeralLiveNode(ZkController.java:1086)
> at
> org.apache.solr.cloud.ZkController$1.command(ZkController.java:411)
> ... 5 more {code}
> h2. Root cause
> This bug occurs because several threads can re-establish the session
> concurrently.
> It cannot happen at the first expiration of the session, thanks to a thread
> pool with a single thread to execute the zookeeper Watcher.
> Bellow is a code snippet from class {{SolrZkClient.ProcessWatchWithExecutor}}
> {code:java}
> if (watcher instanceof ConnectionManager) {
> zkConnManagerCallbackExecutor.submit(() -> watcher.process(event));
> } else {
>...
> }
> {code}
> Using this dedicated thread pool (with a single thread) is supposed to ensure
> we don’t handle watches for connection related events with multiple threads.
> This works well for the first session expiration.
> Now, when we re-establish the session after the first expiration, we don’t
> use this wrapper to register the watch.
> It is done directly in {{ConnectionManager}} without wrapping the ZK watch.
> In the following snippet, _“this”_ is the ZK watcher instance, but it is not
> wrapper to use a {{{}ProcessWatchWithExecutor{}}}. This means the next events
> will directly be handled by any ZK callback thread.
> {code:java}
> connectionStrategy.reconnect(zkServerAddress,client.getZkClientTimeout(),
> this,
> {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] [Updated] (SOLR-17408) Calls to COLSTATUS are not optimized
[ https://issues.apache.org/jira/browse/SOLR-17408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17408: -- Labels: pull-request-available (was: ) > Calls to COLSTATUS are not optimized > > > Key: SOLR-17408 > URL: https://issues.apache.org/jira/browse/SOLR-17408 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: main (10.0) >Reporter: Mathieu Marie >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > all versions are affected (I would guess). > I found out about it in solr 9.4.1 and is still present in main. > When calling COLSTATUS, by default, Solr will fetch segment information and > return it even if no flag requested that information. > When there is a huge amount of shards, this can lead to delays and > unnecessary traffic (as well as extra information in the returned payload > that was not requested/necessary). > > And extra check would be sufficient to prevent that extra work and have a > better response time > -- 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-17406) Introduce Gradle Version Catalogs
[ https://issues.apache.org/jira/browse/SOLR-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17406: -- Labels: dependencies gradle pull-request-available (was: dependencies gradle) > Introduce Gradle Version Catalogs > - > > Key: SOLR-17406 > URL: https://issues.apache.org/jira/browse/SOLR-17406 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Gradle >Affects Versions: main (10.0) >Reporter: Christos Malliaridis >Priority: Minor > Labels: dependencies, gradle, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > With Gradle it is possible to manage versions and dependencies in gradle > files via version catalogs. This allows us to cleanup dependency resolution > and move various versions from across the project to a single file. > Dawid Weiss demonstrated in [Lucene PR > #13484|https://github.com/apache/lucene/pull/13484/] such a migration > together with a few improvements in the gradle build files that could be > addressed in this ticket aswell. > The migration include the removal of palantir's consistent versions plugin. > Dev list thread: > [https://lists.apache.org/thread/wh6c0x2ncbpd61pwwddtv3l256lv9kr5] -- 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-15469) start/stop script fails on multiple instance
[ https://issues.apache.org/jira/browse/SOLR-15469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-15469: -- Labels: cluster instances pull-request-available (was: cluster instances) > start/stop script fails on multiple instance > > > Key: SOLR-15469 > URL: https://issues.apache.org/jira/browse/SOLR-15469 > Project: Solr > Issue Type: Bug > Components: scripts and tools, SolrCLI >Reporter: Danilo >Priority: Minor > Labels: cluster, instances, pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > When more instances of solr run on the same machine. The bash script solr > fail to get correct pid of process. This cause problems to get status > information or when stop/restart solr instance. > In optical to use solr like a cluster service this is essential for the > cluster to know the healt of service. -- 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-12429) ZK upconfig throws confusing error when it encounters a symlink
[
https://issues.apache.org/jira/browse/SOLR-12429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-12429:
--
Labels: pull-request-available (was: )
> ZK upconfig throws confusing error when it encounters a symlink
> ---
>
> Key: SOLR-12429
> URL: https://issues.apache.org/jira/browse/SOLR-12429
> Project: Solr
> Issue Type: Bug
> Components: SolrCLI
>Affects Versions: 7.3.1
>Reporter: Shawn Heisey
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a configset being uploaded to ZK contains a symlink pointing at a
> directory, an error is thrown, but it doesn't explain the real problem. The
> upconfig should detect symlinks and throw an error indicating that they
> aren't supported. If we can detect any other type of file that upconfig
> can't use (sockets, device files, etc), the error message should be relevant.
> {noformat}
> Exception in thread "main" java.io.IOException: File
> '/var/solr/mbs/artist/conf/common' exists but is a directory
> at org.apache.commons.io.FileUtils.openInputStream(FileUtils.java:286)
> at
> org.apache.commons.io.FileUtils.readFileToByteArray(FileUtils.java:1815)
> at
> org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:391)
> at
> org.apache.solr.common.cloud.ZkMaintenanceUtils$1.visitFile(ZkMaintenanceUtils.java:305)
> at
> org.apache.solr.common.cloud.ZkMaintenanceUtils$1.visitFile(ZkMaintenanceUtils.java:291)
> at java.nio.file.Files.walkFileTree(Files.java:2670)
> at java.nio.file.Files.walkFileTree(Files.java:2742)
> at
> org.apache.solr.common.cloud.ZkMaintenanceUtils.uploadToZK(ZkMaintenanceUtils.java:291)
> at
> org.apache.solr.common.cloud.SolrZkClient.uploadToZK(SolrZkClient.java:793)
> at
> org.apache.solr.common.cloud.ZkConfigManager.uploadConfigDir(ZkConfigManager.java:78)
> at org.apache.solr.cloud.ZkCLI.main(ZkCLI.java:236)
> {noformat}
> I have not tested whether a symlink pointing at a file works, but I think
> that an error should be thrown for ANY symlink.
--
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-17412) Skip nested atomic updates for non-existent child docs
[
https://issues.apache.org/jira/browse/SOLR-17412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17412:
--
Labels: patch-with-test pull-request-available (was: patch-with-test)
> Skip nested atomic updates for non-existent child docs
> --
>
> Key: SOLR-17412
> URL: https://issues.apache.org/jira/browse/SOLR-17412
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Tim Owen
>Priority: Minor
> Labels: patch-with-test, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new functionality introduced in SOLR-15213 for atomic updates allows a
> nested atomic update for a child document i.e. you can do an atomic update
> for a root document which also contains child documents and do atomic updates
> on those. This is really useful, however the current behaviour for cases
> where the child document doesn't exist is to throw a Bad Request exception.
> There is an update processor {{SkipExistingDocumentsProcessor}} which allows
> you to skip atomic updates to documents if they don't exist, quietly. However
> this doesn't identify nested atomic updates because the logic for merging
> nested atomic updates based on the actual block of documents in the index is
> done inside {{AtomicUpdateDocumentMerger}}.
--
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-17044) Improve API path specifying in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17044: -- Labels: pull-request-available (was: ) > Improve API path specifying in SolrJ > > > Key: SOLR-17044 > URL: https://issues.apache.org/jira/browse/SOLR-17044 > Project: Solr > Issue Type: Improvement > Components: SolrJ, v2 API >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently, URL-driven SolrClients receive a URL that typically ends in > "/solr". Requiring users to specify this context-root in their URLs has made > sense historically, since all v1 paths start with "/solr". But this has > become limiting as Solr's v2 APIs (which use the "/api" context root) become > more mature. > SolrJ has some string manipulation in a few spots to try to accomodate this, > but it's patchy and relatively brittle (relying on overly specific > 'instanceof' checks, etc.). We should come up with a more reliable way to > ensure that SolrClient's can make both v1 and v2 requests. > Here's one idea for how we could approach this: > # Create a new SolrRequest method to specify the initial path segment (i.e. > /solr vs /api) on a per-request basis. We could either do this directly > (e.g. "getRootPath()"), or indirectly (e.g. "isV2()"). > # Modify SolrClients to consider both the new method and the existing > "getPath" when sending requests. > # Add logic to SolrJ to strip "/solr" from any provided base URLs, and > document that SolrClient URLs no longer require the "/solr" context-root > suffix. -- 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-17223) Port renderJavadoc task fix from Lucene
[ https://issues.apache.org/jira/browse/SOLR-17223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17223: -- Labels: pull-request-available (was: ) > Port renderJavadoc task fix from Lucene > --- > > Key: SOLR-17223 > URL: https://issues.apache.org/jira/browse/SOLR-17223 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Port [https://github.com/apache/lucene/pull/13132] to solr > Spinoff from SOLR-17205 -- 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-16503) Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
[
https://issues.apache.org/jira/browse/SOLR-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-16503:
--
Labels: pull-request-available (was: )
> 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: 1h 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-17240) Http2SolrClient uses too few requests per host for http2
[
https://issues.apache.org/jira/browse/SOLR-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17240:
--
Labels: pull-request-available (was: )
> Http2SolrClient uses too few requests per host for http2
>
>
> Key: SOLR-17240
> URL: https://issues.apache.org/jira/browse/SOLR-17240
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 8.0
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Ever since the Http2SolrClient was introduced, if the client was set up to
> use http2, then the {{maxConnectionsPerDestination}} was hardcoded to 4 and
> could not be overridden.
> This may have been due to a mis-reading of the
> {{setMaxConnectionsPerDestination}} javadocs whichs states that browsers
> generally use 2-6 requests per destination, and links to an RFC. However the
> RFC linked to covers HTTP 1.1 and obviously Solr is not a browser.
> A number of users have seen issues around slowness when using http2, and I
> think this is a likely cause. Http2 will multiplex requests on a single
> connection, however by default the number of requests that Jetty will
> multiplex is somewhere around 300. (This is a very hard value to track down,
> as the way it is determined is via a web of indirection)
> So, for example, the HttpShardHandler defaults to 100,000
> maxConnectionsPerDestination. So the users using http1 will be able to get
> that throughput. The users using http2 will have a max of roughly 1,200 (4 *
> 300). Obviously there is going to be a massive performance implication.
> So I think we should just use the same {{maxConnectionsPerDestination}} for
> both http2 and http1. The http2 client will have the added benefit of using
> multiplexing, and Jetty will likely do the right thing and not create tons of
> connections when multiplexing can be used 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] [Updated] (SOLR-10059) In SolrCloud, every fq added via is computed twice.
[
https://issues.apache.org/jira/browse/SOLR-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-10059:
--
Labels: performance pull-request-available (was: performance)
> In SolrCloud, every fq added via is computed twice.
>
>
> Key: SOLR-10059
> URL: https://issues.apache.org/jira/browse/SOLR-10059
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 6.4
>Reporter: Marc Morissette
>Assignee: Eric Pugh
>Priority: Major
> Labels: performance, pull-request-available
> Attachments:
> SOLR-10059-RequestHandlerBase-prepareRequestParams.patch, SOLR-10059_7x.patch
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> While researching another issue, I noticed that parameters appended to a
> query via SearchHandler's are added to the query twice
> in SolrCloud: once on the aggregator and again on the shard.
> The FacetComponent corrects this automatically by removing duplicates. Field
> queries added in this fashion are however computed twice and that hinders
> performance on filter queries that aren't simple bitsets such as those
> produced by the CollapsingQueryParser.
> To reproduce the issue, simply test this handler on a large enough
> collection, then replace "appends" with "defaults". You'll notice significant
> performance improvements.
> {code}
>
>
> {!collapse field=routingKey hint=top_fc}
>
>
> {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] [Updated] (SOLR-17037) LTR Queries don't use queryResultCache
[ https://issues.apache.org/jira/browse/SOLR-17037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17037: -- Labels: pull-request-available (was: ) > LTR Queries don't use queryResultCache > -- > > Key: SOLR-17037 > URL: https://issues.apache.org/jira/browse/SOLR-17037 > Project: Solr > Issue Type: Bug > Components: contrib - LTR, ltr >Affects Versions: 9.4 >Reporter: Doug Turnbull >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Before queries are placed in the query result cache, they get rewritten. > Sometimes this rewriting happens in-place. The key used for the query result > cache, has as one element, the query. > For LTRQuery -> LTRScoringQuery, rewriting will change the cache key's > original query. Thus when we insert using this key, it's not the same as > subsequent queries that perform a lookup. So LTRQueries never benefit from > the cache. > A similar issue was resolved with general reranking queries by [~jbernste] > SOLR-7689 - https://issues.apache.org/jira/browse/SOLR-7689 > -- 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-17180) Migrate snapshotscli.sh code into bin/solr and hdfs module code
[ https://issues.apache.org/jira/browse/SOLR-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17180: -- Labels: pull-request-available (was: ) > Migrate snapshotscli.sh code into bin/solr and hdfs module code > --- > > Key: SOLR-17180 > URL: https://issues.apache.org/jira/browse/SOLR-17180 > Project: Solr > Issue Type: Sub-task > Components: cli, hdfs >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There is a file in ./server/scripts/cloud-scripts/ called snapshotscli.sh. > We have no documentation about it in the ref guide, and it appears to expose > the class > org.apache.solr.hdfs.snapshots.SolrSnapshotsTool.java > > Seems like this should be distributed as part of the hdfs Module, not buried > way down deep inside of the core of Solr. > Maybe it should be in ./modules/hdfs/bin directory? Or > ./modules/hdfs/scripts directory in the Solr distribution? -- 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-17400) Remove deprecated snapshotscli.sh from main
[ https://issues.apache.org/jira/browse/SOLR-17400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17400: -- Labels: pull-request-available (was: ) > Remove deprecated snapshotscli.sh from main > --- > > Key: SOLR-17400 > URL: https://issues.apache.org/jira/browse/SOLR-17400 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: main (10.0) >Reporter: Eric Pugh >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Post SOLR-17180 being completed, remove deprecated code from 10.x -- 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-17310) Configurable LeafSorter to customize segment search order
[ https://issues.apache.org/jira/browse/SOLR-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17310: -- Labels: pull-request-available (was: ) > Configurable LeafSorter to customize segment search order > - > > Key: SOLR-17310 > URL: https://issues.apache.org/jira/browse/SOLR-17310 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: wei wang >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Lucene's IndexWriterConfig provides the option to sort leaf readers when a > custom LeafSorter is provided. > [https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/index/IndexWriterConfig.java#L494] > > The functionality is currently not directly exposed in Solr. One use case is > in early termination, we would like to search the more recent updated > segments first. The SegmentTimeLeafSorter sorts the LeafReaders by time > stamp, so that recent NRT segments can be traversed first. The feature is > enabled by adding the *segmentSort* config in solrconfig.xml. Without the > config, no sorting is applied by default. -- 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-17421) With overseer node role enabled, overseer may be stopped without giving-up leadership
[
https://issues.apache.org/jira/browse/SOLR-17421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17421:
--
Labels: pull-request-available (was: )
> With overseer node role enabled, overseer may be stopped without giving-up
> leadership
> -
>
> Key: SOLR-17421
> URL: https://issues.apache.org/jira/browse/SOLR-17421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.11, 9.6
>Reporter: Pierre Salagnac
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Overseer may retain the leadership status while the thread pool that is
> supposed to consume the collection state mutator queue was already shut down.
> Occurrences of this but are probably not frequent. But when it happens, it
> has a huge impact. The overseer cluster state updater is stuck and all
> collection admin requests are very likely to fail. Because of the stuck
> overseer, all the enqueued operations (collection creation, deletion...) fail
> and remain in the collection API queue.
> h2. Root cause
> Root cause is the {{QUIT}} command does not cancel overseer election if any
> error happens while shutting down the state updater thread pool.
> {code:java}
> level: ERROR
> logger: org.apache.solr.cloud.Overseer
> message: Overseer could not process the current clusterstate state
> update message, skipping the message: {
> "operation":"quit",
> "id":"72073405485023239-_solr-n_000948"}
> node_name: :8983_solr
> threadId: 281272
> threadName:
> OverseerStateUpdate-72073405485023239-_solr-n_000948
> thrown: java.lang.RuntimeException: Timeout waiting for pool
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor@2c1da18d[Shutting
> down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks =
> 0] to shutdown.
> at
> org.apache.solr.common.util.ExecutorUtil.awaitTermination(ExecutorUtil.java:142)
> at
> org.apache.solr.common.util.ExecutorUtil.awaitTermination(ExecutorUtil.java:129)
> at
> org.apache.solr.common.util.ExecutorUtil.shutdownAndAwaitTermination(ExecutorUtil.java:112)
> at
> org.apache.solr.cloud.OverseerTaskProcessor.close(OverseerTaskProcessor.java:431)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processMessage(Overseer.java:601)
> at
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:450)
> at org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:377)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> {code}
> h2. Proximate cause
> It seems to me long running operations in the collection API could trigger
> the bug more frequently. Because of a long running operation, we get an
> exception when shutting down the thread pool. This has a 60 seconds timeout.
--
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-15981) Also support parameter 'notLogParamsList' besides 'logParamsList'
[ https://issues.apache.org/jira/browse/SOLR-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-15981: -- Labels: pull-request-available (was: ) > Also support parameter 'notLogParamsList' besides 'logParamsList' > - > > Key: SOLR-15981 > URL: https://issues.apache.org/jira/browse/SOLR-15981 > Project: Solr > Issue Type: Improvement > Components: logging >Reporter: samuel ma >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently Solr has a parameter 'logParamsList' to specify which parameter is > to be logged, most of the time it is not easy to add a full set of > logParamsList. Can solr add another parameter 'notLogParamsList', then in > our application better to control which parameter is not be logged. -- 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-3913) SimplePostTool optimize does a redundant commit
[
https://issues.apache.org/jira/browse/SOLR-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-3913:
-
Labels: pull-request-available (was: )
> SimplePostTool optimize does a redundant commit
> ---
>
> Key: SOLR-3913
> URL: https://issues.apache.org/jira/browse/SOLR-3913
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: David Smiley
>Assignee: Eric Pugh
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the end of SimplePostTool.execute() there is:
> {code}
> if (commit) commit();
> if (optimize) optimize();
> {code}
> Each of these calls involves a separate request to Solr. The thing is, an
> optimize internally commits, and so the logic should forgo committing is
> optimize is true.
> And as an aside, I think the 1kb pipe() buffer on line 893 is too small; it
> should be around 8kb (8192) bytes which is the same value as
> BufferedInputStream's default.
--
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-14370) Refactor bin/solr to allow external override of Jetty modules
[
https://issues.apache.org/jira/browse/SOLR-14370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-14370:
--
Labels: pull-request-available (was: )
> Refactor bin/solr to allow external override of Jetty modules
> -
>
> Key: SOLR-14370
> URL: https://issues.apache.org/jira/browse/SOLR-14370
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Andy Throgmorton
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The bin/solr script currently does not allow for externally overriding the
> modules passed to Jetty on startup.
> This PR adds the ability to override the Jetty modules on startup by setting
> {{JETTY_MODULES}} as an environment variable; when passed, bin/solr will pass
> through (and not clobber) the string verbatim into {{SOLR_JETTY_CONFIG}}. For
> example, you can now run:
> {{JETTY_MODULES=--module=foo bin/solr start}}
> We've added some custom Jetty modules that can be optionally enabled; this
> change allows us to keep our logic (regarding which modules to use) in a
> separate script, rather than maintaining a forked bin/solr.
--
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-11640) bin/post should obey fileType list in all modes
[
https://issues.apache.org/jira/browse/SOLR-11640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-11640:
--
Labels: pull-request-available (was: )
> bin/post should obey fileType list in all modes
> ---
>
> Key: SOLR-11640
> URL: https://issues.apache.org/jira/browse/SOLR-11640
> Project: Solr
> Issue Type: Bug
> Components: documentation, scripts and tools
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Eric Pugh
>Priority: Trivial
> Labels: pull-request-available
> Attachments: SOLR-11640.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the QuickStart tutorial included in the ref guide involves running
> the following command to index some example documents: {{bin/post -c
> techproducts example/exampledocs/*}}
> This ends up attempting to index _all_ the files in that directory, which
> includes the expected example files, but also as bash script called
> {{test_utf8.sh}} and the {{post.jar}} JAR file itself.
> The subsequent tutorial step involves searching results, which can bring up
> the ugly result:
> {code}
> {
>
> "id":"/home/jason/checkouts/lucene-solr/solr/example/exampledocs/post.jar",
>
> "resourcename":"/home/jason/checkouts/lucene-solr/solr/example/exampledocs/post.jar",
> "content_type":["application/java-archive"],
> "content":[" \n \n \n \n \n \n \n \n \n \n \n
> META-INF/MANIFEST.MF \n Manifest-Version: 1.0\r\nAnt-Version: Apache Ant
> 1.9.6\r\nCreated-By: 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12 (Oracle Corp
> orati\r\n on)\r\nMain-Class: org.apache.solr.util.SimplePostTool\r\n\r\n \n\n
> \n \n org/apache/solr/util/RTimer$1.class \n package
> org.apache.solr.util;\n synchronized class RTimer$1 {\n}\n \n\n \n \n o
> rg/apache/solr/util/RTimer$NanoTimeTimerImpl.class \n package
> org.apache.solr.util;\n synchronized class RTimer$NanoTimeTimerImpl
> implements RTimer$TimerImpl {\n private long start ;\n private
> void RTimer$NanoTimeTimerImpl();\n public void start ();\n public
> double elapsed ();\n}\n \n\n \n \n
> org/apache/solr/util/RTimer$TimerImpl.class \n package
> org.apache.solr.util;\n public abstra
> ct interface RTimer$TimerImpl {\n public abstract void start ();\n
> public abstract double elapsed ();\n}\n \n\n \n \n
> org/apache/solr/util/RTimer.class \n package org.apache.solr.util;\n p
> ublic synchronized class RTimer {\n public static final int
> STARTED = 0;\n public static final int STOPPED = 1;\n public
> static final int PAUSED = 2;\n protected int s
> ..[remaining code skipped for brevity]"],
> "_version_":1583971861929132032},
> {code}
> It's honestly pretty cool that TIKA can extract code from our post.jar file.
> It makes sense, but I didn't expect it. But it's probably not what we
> intended to show to new users. Especially considering that the bin/post
> invocation in the quick-start tutorial claims to be choosy about what
> filetypes it will index:
> {code}
> Entering auto mode. File endings considered are
> xml,json,jsonl,csv,pdf,doc,docx,ppt,pptx,xls,xlsx,odt,odp,ods,ott,otp,ots,rtf,htm,html,txt,log
> {code}
> From a quick glance at things, it looks like {{bin/post}} does pass a list of
> permissible filetypes to the underlying {{SimplePostTool}}, but that
> SimplePostTool doesn't follow this extension whitelist in the particular mode
> being invoked by the quickstart tutorial. So this is probably a wider bug,
> that the quickstart/tutorial just happens to expose.
--
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-17422) Remove CLUSTERSTATE from v2; redundant
[ https://issues.apache.org/jira/browse/SOLR-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17422: -- Labels: pull-request-available (was: ) > Remove CLUSTERSTATE from v2; redundant > -- > > Key: SOLR-17422 > URL: https://issues.apache.org/jira/browse/SOLR-17422 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: David Smiley >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Revert SOLR-15748 – remove v2 /api/cluster being a CLUSTERSTATUS call > The information (e.g. aliases, or the status of one collection, live nodes, > etc.) should be made available via V2 but we don't need a macro API to return > a bunch of these things at once, which is what CLUSTERSTATUS is. I suspect > CLUSTERSTATUS may have been one of the original SolrCloud level APIs so it > became a kitchen sink of all things about the state/status. In hindsight, I > don't agree with it. It ends up blowing up in size for clients that only > need a subset of it, leading to decomposing it – SOLR-17381. -- 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-6962) bin/solr stop -a should complain about missing parameter
[ https://issues.apache.org/jira/browse/SOLR-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-6962: - Labels: pull-request-available (was: ) > bin/solr stop -a should complain about missing parameter > > > Key: SOLR-6962 > URL: https://issues.apache.org/jira/browse/SOLR-6962 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > Labels: pull-request-available > Attachments: SOLR-6962.patch, SOLR-6962v2.patch > > Time Spent: 10m > Remaining Estimate: 0h > > *bin/solr* has a *-a* option that expects a second parameter. If one is not > provided, it hangs. It should complain and exit just like *-e* option does. > The most common time I hit this is when I try to do *bin/solr stop \-all* and > instead just type *bin/solr stop \-a* as I am more used to give full name > options with double-dash prefix (Unix conventions, I guess). -- 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-17423) CLI: Resolve -h argument conflict (help/host)
[
https://issues.apache.org/jira/browse/SOLR-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17423:
--
Labels: cli pull-request-available (was: cli)
> CLI: Resolve -h argument conflict (help/host)
> -
>
> Key: SOLR-17423
> URL: https://issues.apache.org/jira/browse/SOLR-17423
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: cli, examples
>Affects Versions: main (10.0), 9.7
>Reporter: Christos Malliaridis
>Priority: Major
> Labels: cli, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment RunExampleTool uses -h for providing the hostname. -h is
> commonly known for printing the help / usage. To avoid any confusion for
> beginners and improve the learnability of the CLI, we should deprecate -h in
> RunExampleTool for future 9.X releases and remove it in 10.0 (two PRs
> expected). -h should only be used for printing the help information.
> Note that -h is used via Option.builder("h") and in a raw string as "-h"
> inside RunExampleTool, and deprecation would require both to be updated.
> Please review for any documentation references as well.
> Once the conflict is resolved, the tracking table in [Solr Arguments -
> Migration
> Overview|https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing]
> can be updated.
--
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-17142) clear and repeatable unreferenced license file detection
[ https://issues.apache.org/jira/browse/SOLR-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17142: -- Labels: newdev pull-request-available (was: newdev) > clear and repeatable unreferenced license file detection > > > Key: SOLR-17142 > URL: https://issues.apache.org/jira/browse/SOLR-17142 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Christine Poerschke >Assignee: Uwe Schindler >Priority: Minor > Labels: newdev, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Observationally currently it can be unclear (i.e. warning but not failing) > and inconsistent in repeat runs (more detections on second run) e.g. > https://lists.apache.org/thread/hlh1bmtgnmp55q8knhjtltf8t57pbl5q and > https://github.com/apache/solr/pull/2178#issuecomment-1917513343 reports. -- 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-17427) ApiTool regressions after cli pattern change
[
https://issues.apache.org/jira/browse/SOLR-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17427:
--
Labels: pull-request-available (was: )
> ApiTool regressions after cli pattern change
>
>
> Key: SOLR-17427
> URL: https://issues.apache.org/jira/browse/SOLR-17427
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: cli
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the CLI changes, the ApiTool cannot be used with urls that do not
> contain a port. This is because {{url.getAuthority()}} is used to build the
> host+port section of the URL, but it will return a "-1" if a port is not
> included in the URL. We should be very careful about using
> {{url.getAuthority()}} in our 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] [Updated] (SOLR-17149) Cannot backup/restore large collection.
[
https://issues.apache.org/jira/browse/SOLR-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17149:
--
Labels: pull-request-available (was: )
> Cannot backup/restore large collection.
> ---
>
> Key: SOLR-17149
> URL: https://issues.apache.org/jira/browse/SOLR-17149
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.4
>Reporter: Pierre Salagnac
>Assignee: Jason Gerlowski
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.5
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
>
> There is a regression introduced in version 9.4 with SOLR-16879.
>
> We cannot backup collections with more than 10 shards per node. The thread
> pool is rejecting new tasks with following error:
> {noformat}
> SolrException: Could not backup all shards
> Task
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda...
> rejected from
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor[Running,
> pool size = 5, active threads = 5, queued tasks = 5, completed tasks = 30]"
> {noformat}
> {{expensiveExecutor}} thread pool executor is
> [created|https://github.com/apache/solr/blob/releases/solr/9.4.1/solr/solrj/src/java/org/apache/solr/common/util/ExecutorUtil.java#L170-L174]
> with 5 max threads and bounded queue of the same size (5), so the total
> number of tasks is limited to 10 and all the other tasks are immediately
> rejected.
--
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-17382) CLI: Deprecate addlopts in RunExampleTool.java
[
https://issues.apache.org/jira/browse/SOLR-17382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17382:
--
Labels: pull-request-available (was: )
> CLI: Deprecate addlopts in RunExampleTool.java
> --
>
> Key: SOLR-17382
> URL: https://issues.apache.org/jira/browse/SOLR-17382
> Project: Solr
> Issue Type: Sub-task
>Reporter: Christos Malliaridis
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [RunExampleTool.java|https://github.com/apache/solr/blob/661b1dac2284ab556573605ae81a4951a5703c49/solr/core/src/java/org/apache/solr/cli/RunExampleTool.java#L190]
> uses "\-\-addlopts" for {_}additional options{_}, which should be deprecated
> and replaced with "\-\-additional-options" to follow the naming conventions
> for long arguments.
--
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-17429) Find more permanent solution to Deprecated SolrCLI logging
[
https://issues.apache.org/jira/browse/SOLR-17429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17429:
--
Labels: pull-request-available (was: )
> Find more permanent solution to Deprecated SolrCLI logging
> --
>
> Key: SOLR-17429
> URL: https://issues.apache.org/jira/browse/SOLR-17429
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: cli
>Affects Versions: 9.7
>Reporter: Houston Putman
>Assignee: Eric Pugh
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Commons CLI now supports deprecated options, and when those options are used,
> they print a log to the user warning them. Unfortunately, by default, the
> logging is done to stdout. Tools that use the SolrCLI and parse the output
> will be broken by this change since they generally always read from stdout.
> If the logging was done to stderr, there would be no problem since the tools
> would not read the deprecation logs with the CLI output.
> Either
> * Commons CLI should log deprecations to stderr by default
> * Commons CLI should make {{Option.toDeprecatedString()}} public, so that we
> can more easily make our own DeprecationHandler that merely prints the same
> thing to stderr. As it is, we have to copy the whole method ourselves since
> it is package private.
--
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-17432) Enable use of OTEL Agent
[
https://issues.apache.org/jira/browse/SOLR-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17432:
--
Labels: pull-request-available (was: )
> Enable use of OTEL Agent
>
>
> Key: SOLR-17432
> URL: https://issues.apache.org/jira/browse/SOLR-17432
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: tracing
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The [OpenTelemetry Java Agent
> |https://opentelemetry.io/docs/zero-code/java/agent/]is really powerful,
> supporting {{WithSpan}} annotations and auto-instrumentation of many
> libraries like the AWS SDK. It also isolates its transitive dependencies in
> another classloader so as not to conflict with Solr's choices. Solr
> currently only supports OTEL via Solr itself calling into OTEL to initialize.
> This ticket proposes _also_ supporting recognizing that the OTEL agent is
> loaded, and if so then using that without any change to solr.xml.
> Without this, someone can write a trivial TracerConfigurator and configure it
> in solr.xml but ideally Solr should detect the situation. If you want to run
> tests with tracing (an overlooked use of tracing!), it's annoying to go touch
> the pertinent solr.xml.
--
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-17343) Live-updating Global Circuit Breakers via ClusterProperties
[ https://issues.apache.org/jira/browse/SOLR-17343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17343: -- Labels: pull-request-available (was: ) > Live-updating Global Circuit Breakers via ClusterProperties > --- > > Key: SOLR-17343 > URL: https://issues.apache.org/jira/browse/SOLR-17343 > Project: Solr > Issue Type: New Feature >Affects Versions: 9.6.1 >Reporter: Nick Ginther >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Global rate limiting was added via environment variables and system > properties in SOLR-16974. This was implemented via environment variables that > are evaluated at Solr startup. The implementation results in global circuit > breakers that are static until the Solr process restarts. It would be useful > to be able to dynamically update circuit breakers while Solr is running for > two reasons. > # Cluster load may change in such a way that it is useful to raise or lower > circuit breaker thresholds, or add/remove circuit breakers > # Experimenting with circuit breaker thresholds and types is much easier > For these reasons, this issue proposes the following changes: > # Add a ClusterProps field that describes cluster-level global circuit > breakers > ## One global circuit breaker per-class, with a query and update threshold > ## The ability to override these values at the node level > # Add a ClusterProps command `set-circuit-breakers` to set this ClusterProps > field via the v2 API > # Implement a global circuit breaker manager that handles ClusterProps > changes by updating / adding / removing circuit breakers based on changes in > configuration > # ClusterProps-based circuit breakers override any environment-variable > based global circuit breakers for ease of circuit breaker management -- 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-16036) Race condition in SolrJmxReporterTest.testClosedCore
[ https://issues.apache.org/jira/browse/SOLR-16036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16036: -- Labels: pull-request-available (was: ) > Race condition in SolrJmxReporterTest.testClosedCore > > > Key: SOLR-16036 > URL: https://issues.apache.org/jira/browse/SOLR-16036 > Project: Solr > Issue Type: Test > Components: JMX, Tests >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Labels: pull-request-available > Fix For: 9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > [https://jenkins.thetaphi.de/view/Solr/job/Solr-main-MacOSX/666/testReport/org.apache.solr.metrics.reporters/SolrJmxReporterTest/testClosedCore/] > > There's a race condition in our test where the core can be unloaded, causing > the MBean to deregister before the loop has been instructed to stop checking. > It doesn't reproduce for me at all locally, so I can't verify this, but > that's my best guess from visual inspection. -- 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-17431) CLI: Resolve -p flag conflict (port, property, param, params)
[ https://issues.apache.org/jira/browse/SOLR-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17431: -- Labels: cli newdev pull-request-available (was: cli newdev) > CLI: Resolve -p flag conflict (port, property, param, params) > - > > Key: SOLR-17431 > URL: https://issues.apache.org/jira/browse/SOLR-17431 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: cli >Affects Versions: 9.7, 9.6.1 >Reporter: Christos Malliaridis >Priority: Major > Labels: cli, newdev, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In the CLI analysis we found that -p is used for "port", "property", "param" > and "params", in different CLI classes. Due to the potential confusion and > mistakes new users may run into, we should remove the short variant for the > less significant flags and keep the -p option only for the port flag (–port, > currently used in RunExampleTool and SolrExporter). > This is means that we have to deprecate for 9.8 the -p option for "property" > in ConfigTool, for "param" in PackageTool and for "params" in PostTool, and > remove the option completely in main / 10.0. *Do not* depricate the > full-length flags though. > When updating, make sure bin/solr, bin/solr.cmd and the documentation are all > updated accordingly. The changes will be reflected afterwards in [Solr > Arguments - Migration > Overview|https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing]. -- 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-16295) Modernize and Standardize Solr description across all platforms
[ https://issues.apache.org/jira/browse/SOLR-16295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-16295: -- Labels: pull-request-available (was: ) > Modernize and Standardize Solr description across all platforms > --- > > Key: SOLR-16295 > URL: https://issues.apache.org/jira/browse/SOLR-16295 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Houston Putman >Assignee: Eric Pugh >Priority: Major > Labels: pull-request-available > > Currently everywhere we have a page on "Solr", we have a short description on > what the project/product is. They are all roughly the same, but we should try > to improve this language and standardize it everywhere. > The places I can think of currently are: > * [solr.apache.org|https://solr.apache.org/] > * [Ref Guide|https://solr.apache.org/guide/solr/latest/] > * [Github - Solr|https://github.com/apache/solr] > * [DockerHub - Solr|https://hub.docker.com/_/solr] > * [ArtifactHub - Solr|https://artifacthub.io/packages/helm/apache-solr/solr] > The Solr Operator pages don't really give a Solr description, which is fine. > Please comment if I forgot any, so that we can have a comprehensive list. > Once we agree on the standardized language, we can then update it everywhere > it needs to go (since the above list are managed in a variety of places). -- 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-17434) Jetty relativeRedirectAllowed should be true
[ https://issues.apache.org/jira/browse/SOLR-17434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17434: -- Labels: pull-request-available (was: ) > Jetty relativeRedirectAllowed should be true > > > Key: SOLR-17434 > URL: https://issues.apache.org/jira/browse/SOLR-17434 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > For a minor security benefit, avoiding exposing Solr's host & port number in > an obscure case: > [https://github.com/jetty/jetty.project/issues/11014] > Assuming Solr main/10 moves on to Jetty 12, this configuration change is only > applicable to Solr 9. -- 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-15685) Add Devcontainer to make building easier
[
https://issues.apache.org/jira/browse/SOLR-15685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-15685:
--
Labels: build-tools pull-request-available (was: build-tools)
> Add Devcontainer to make building easier
>
>
> Key: SOLR-15685
> URL: https://issues.apache.org/jira/browse/SOLR-15685
> Project: Solr
> Issue Type: Wish
> Components: Build
>Affects Versions: 9.0
>Reporter: Jonathan J Senchyna
>Priority: Minor
> Labels: build-tools, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I would like to propose the addition of a {{.devcontainer}} to make it easier
> for developers to pull down the repo and get a build going. Currently,
> running the build requires installing a JDK and Perl. Although not a
> terrible amount of prerequisites, adding a {{.devcontainer}} will allow any
> developer with Docker installed to simply open the project within the
> container and have a fully-functional build environment.
--
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-17105) Require a location for LocalFileSystemRepository Backups
[ https://issues.apache.org/jira/browse/SOLR-17105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17105: -- Labels: pull-request-available (was: ) > Require a location for LocalFileSystemRepository Backups > > > Key: SOLR-17105 > URL: https://issues.apache.org/jira/browse/SOLR-17105 > Project: Solr > Issue Type: Improvement > Components: Backup/Restore >Reporter: Houston Putman >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Starting with Solr 10, a location parameter should be required for the > LocalFileSystemRepository. This will limit the backup repository so that it > can only save/read backups from inside of that directory (or any > subdirectory). > This is back-compat breaking, so it's likely not a change that we would want > to make for 9x. But in -- 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-17439) jattach does not work with Solr in Docker
[
https://issues.apache.org/jira/browse/SOLR-17439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17439:
--
Labels: pull-request-available (was: )
> jattach does not work with Solr in Docker
> -
>
> Key: SOLR-17439
> URL: https://issues.apache.org/jira/browse/SOLR-17439
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: 9.6.1
>Reporter: Roland Müller
>Assignee: Jan Høydahl
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am running the solr:9.6.1 Docker image and want to create a heap dump.
> According to the documentation this should be possible using jattach:
> [https://solr.apache.org/guide/solr/latest/deployment-guide/solr-in-docker.html#debugging-with-jattach]
> If I open a shell in the container and enter the sample command from the
> documentation, this is what I get:
> {noformat}
> $ jattach 10 threaddump
> Process 10 not found{noformat}
> using the default PID 1, there is a different error:
> {noformat}
> $ jattach 1 threaddump
> Could not start attach mechanism: No such file or directory {noformat}
--
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-17448) Audit usage of ExecutorService#submit in Solr codebase
[ https://issues.apache.org/jira/browse/SOLR-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17448: -- Labels: pull-request-available (was: ) > Audit usage of ExecutorService#submit in Solr codebase > -- > > Key: SOLR-17448 > URL: https://issues.apache.org/jira/browse/SOLR-17448 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 9.7 >Reporter: Andrey Bozhko >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There are quite a few places in Solr codebase where the background task is > created by invoking `ExecutorService#submit(...)` method - but where the > reference to the returned future is not retained. > So if the background task fails for any reason, and the task doesn't itself > have a try-catch block to log the failure, - the failure will go completely > unnoticed. > > This ticket is to review the usage of ExecutorService#submit method in the > codebase, and replace those with Executor#execute where appropriate. > > Originally brought up in the dev mailing list: > [https://lists.apache.org/thread/5f1965rltcspgw0j8nzcn2qnz9l4s8qm] -- 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-17150) Create MemQueryLimit implementation
[
https://issues.apache.org/jira/browse/SOLR-17150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17150:
--
Labels: pull-request-available (was: )
> 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: 1h 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
[jira] [Updated] (SOLR-17450) Port all 'solr status' features to StatusTool
[ https://issues.apache.org/jira/browse/SOLR-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17450: -- Labels: pull-request-available (was: ) > Port all 'solr status' features to StatusTool > - > > Key: SOLR-17450 > URL: https://issues.apache.org/jira/browse/SOLR-17450 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently there is quite some custom script logic in bin/solr[.cmd], which > e.g. lists java processes, finds what port they are listening to etc. > We can port that to Java using the [https://github.com/oshi/oshi] library. -- 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-13360) StringIndexOutOfBoundsException: String index out of range: -3
[
https://issues.apache.org/jira/browse/SOLR-13360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-13360:
--
Labels: pull-request-available (was: )
> StringIndexOutOfBoundsException: String index out of range: -3
> --
>
> Key: SOLR-13360
> URL: https://issues.apache.org/jira/browse/SOLR-13360
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.2.1
> Environment: Solr 7.2.1 - SAP Hybris 6.7.0.8
>Reporter: Ahmed Ghoneim
>Priority: Critical
> Labels: pull-request-available
> Attachments: managed-schema, managed-schema, resources.json,
> solr-config.zip
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> *{color:#ff}I cannot execute the following query:{color}*
> {noformat}
> http://localhost:8983/solr/master_Project_Product_flip/suggest?q=duotop&spellcheck.q=duotop&qt=/suggest&spellcheck.dictionary=de&spellcheck.collate=true{noformat}
> 4/1/2019, 1:16:07 PM ERROR true RequestHandlerBase
> java.lang.StringIndexOutOfBoundsException: String index out of range: -3
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -3
> at
> java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:851)
> at java.lang.StringBuilder.replace(StringBuilder.java:262)
> at
> org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:252)
> at
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:94)
> at
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:297)
> at
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:209)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:710)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:
[jira] [Updated] (SOLR-17256) Remove SolrRequest.getBasePath setBasePath
[ https://issues.apache.org/jira/browse/SOLR-17256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17256: -- Labels: newdev pull-request-available (was: newdev) > Remove SolrRequest.getBasePath setBasePath > -- > > Key: SOLR-17256 > URL: https://issues.apache.org/jira/browse/SOLR-17256 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Priority: Minor > Labels: newdev, pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > SolrRequest has a getBasePath & setBasePath. The naming is poor; it's the > URL base to the Solr node like "http://localhost:8983/solr";. It's only > recognized by HttpSolrClient; LBSolrClient (used by CloudSolrClient) ignores > it and will in fact mutate the passed in request to its liking, which is > rather ugly because it means a request cannot be used concurrently if the > user wants to. But moreover I think there's a conceptual discordance of > placing this concept on SolrRequest given that some clients want to route > requests to nodes *they* choose. I propose removing this from SolrRequest > and instead adding a method specific to HttpSolrClient. Almost all existing > usages of setBasePath immediately execute the request on an HttpSolrClient, > so should be easy to change. -- 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-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-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-17485) Remove Slf4j ClassNotFoundException avoidance checks
[ https://issues.apache.org/jira/browse/SOLR-17485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17485: -- Labels: pull-request-available (was: ) > 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 >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Updated] (SOLR-17456) TransactionLog NPE
[ https://issues.apache.org/jira/browse/SOLR-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17456: -- Labels: pull-request-available (was: ) > TransactionLog NPE > -- > > Key: SOLR-17456 > URL: https://issues.apache.org/jira/browse/SOLR-17456 > Project: Solr > Issue Type: Bug >Reporter: David Smiley >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In an erroneous case, a TransactionLog should throw an exception if an > unexpected log file exists instead of merely log a warning in its > constructor. The latter leaves the file in a partially constructed state > that leads to NPEs when it's used later. -- 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-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
]
ASF GitHub Bot updated SOLR-16645:
--
Labels: pull-request-available (was: )
> 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
> Labels: pull-request-available
> Time Spent: 2h 40m
> 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] [Updated] (SOLR-17413) UpdateLog Replay can throw ConcurrentModificationException from sharing the request
[
https://issues.apache.org/jira/browse/SOLR-17413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17413:
--
Labels: newdev pull-request-available (was: newdev)
> UpdateLog Replay can throw ConcurrentModificationException from sharing the
> request
> ---
>
> Key: SOLR-17413
> URL: https://issues.apache.org/jira/browse/SOLR-17413
> Project: Solr
> Issue Type: Bug
>Reporter: David Smiley
>Priority: Major
> Labels: newdev, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I saw org.apache.solr.cloud.BasicDistributedZkTest fail with a stack trace
> revealing we have a real issue with UpdateLog replay. Essentially, a
> SolrQueryRequest is not threadsafe but we replay logs in parallel sharing the
> same request instance. Creating DistributedUpdateProcessor ends up adding to
> a shared HashMap in req.getContext() that should not be shared.
> {noformat}
> 2> WARNING: Uncaught exception in thread:
> Thread[replayUpdatesExecutor-590-thread-2,5,TGRP-BasicDistributedZkTest]
> 2> java.util.ConcurrentModificationException
> 2> at __randomizedtesting.SeedInfo.seed([F2227B12A8FC234]:0)
> 2> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1135)
> 2> at
> org.apache.solr.update.processor.DistributedUpdateProcessorFactory.addParamToDistributedRequestWhitelist(DistributedUpdateProcessorFactory.java:46)
> 2> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.(DistributedUpdateProcessor.java:190)
> 2> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.(DistributedUpdateProcessor.java:160)
> 2> at
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.(DistributedZkUpdateProcessor.java:114)
> 2> at
> org.apache.solr.update.processor.DistributedUpdateProcessorFactory.getInstance(DistributedUpdateProcessorFactory.java:59)
> 2> at
> org.apache.solr.update.processor.UpdateRequestProcessorChain.createProcessor(UpdateRequestProcessorChain.java:242)
> 2> at
> org.apache.solr.update.processor.UpdateRequestProcessorChain.createProcessor(UpdateRequestProcessorChain.java:214)
> 2> at
> org.apache.solr.update.UpdateLog$LogReplayer.lambda$doReplay$0(UpdateLog.java:2103)
> 2> at
> java.base/java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:305)
> 2> at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:195)
> 2> at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:172)
> 2> at
> org.apache.solr.update.UpdateLog$LogReplayer.lambda$execute$2(UpdateLog.java:2342)
> 2> at
> org.apache.solr.util.OrderedExecutor.lambda$execute$0(OrderedExecutor.java:68)
> 2> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$1(ExecutorUtil.java:449)
> 2> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> 2> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 2> at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
--
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-11191) Shard Split doesn't work on indexes that have nested documents
[ https://issues.apache.org/jira/browse/SOLR-11191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-11191: -- Labels: NestedDocuments pull-request-available (was: NestedDocuments) > Shard Split doesn't work on indexes that have nested documents > -- > > Key: SOLR-11191 > URL: https://issues.apache.org/jira/browse/SOLR-11191 > Project: Solr > Issue Type: Bug >Reporter: Varun Thacker >Assignee: David Smiley >Priority: Major > Labels: NestedDocuments, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The split shard command doesn't split a shard correctly when the index has > parent-child documents. > The way split shard works is it goes through all documents id's in that shard > and then decides which sub-shard would it belong in . It is not aware of the > parent child relationship during this process > So the parent-child documents could be orphaned and end up in different shard > Secondly, even with the routing of parent and child documents were the same > split shards needs to re-index them as a block -- 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-17495) Change CLI DeleteTool deleting of configs to opt in instead of default behavior
[ https://issues.apache.org/jira/browse/SOLR-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17495: -- Labels: pull-request-available (was: ) > Change CLI DeleteTool deleting of configs to opt in instead of default > behavior > --- > > Key: SOLR-17495 > URL: https://issues.apache.org/jira/browse/SOLR-17495 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: main (10.0) >Reporter: Eric Pugh >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In discussion on SOLR-17488 we identified that the --delete-config option, > which by default is true, is an odd user experience. You need to do a > --delete-config false to not delete a config. > > However, i think deleting a collection and deleting a config are two seperate > conceptual things in reality. > > So in 10, lets make --delete-config something you opt into otherwise configs > are NOT deleted. -- 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-14765) optimize DocList creation by skipping sort for sort-irrelevant cases
[
https://issues.apache.org/jira/browse/SOLR-14765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-14765:
--
Labels: pull-request-available (was: )
> optimize DocList creation by skipping sort for sort-irrelevant cases
>
>
> Key: SOLR-14765
> URL: https://issues.apache.org/jira/browse/SOLR-14765
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.0
>Reporter: Michael Gibney
>Assignee: Michael Gibney
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.1
>
> Attachments: SOLR-16585-reproducer.patch
>
> Time Spent: 15h
> Remaining Estimate: 0h
>
> When {{rows=0}}, and for {{MatchAllDocsQuery}} and {{ConstantScoreQuery}}
> (and possibly others?), it is possible for
> {{SolrIndexSearcher.getDocListC(QueryResult, QueryCommand)}} to create a
> DocList directly from {{filterCache}} DocSets -- similar to
> {{useFilterForSortedQuery}}, but without actually sorting.
> This results in significant benefits for high-recall domains, including the
> common (and commonly-cached) use-case of {{q=\*:*}} and {{fq}}, facets, etc.
--
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-17479) CLI: Resolve flag conflicts from AssertTool
[
https://issues.apache.org/jira/browse/SOLR-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-17479:
--
Labels: cli pull-request-available (was: cli)
> CLI: Resolve flag conflicts from AssertTool
> ---
>
> Key: SOLR-17479
> URL: https://issues.apache.org/jira/browse/SOLR-17479
> 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 {{AssertTool}} is used via the same CLI entrypoint {{bin/solr}} and
> {{bin/solr.cmd}}, which supports multiple other flags depending on the
> arguments passed.
> Almost all single-letter names from the options available in the
> {{AssertTool}} are used in options of other tools. Additionally, the
> {{AssertTool}} uses case-sensitive naming which does not follow the current
> CLI conventions.
> Since its main use is in testing, and for the above reasons, the
> single-letter names in all {{AssertTool}} options can be deprecated (9.X) and
> removed (10.0) to avoid confusion and potential conflicts in future.
--
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
