[jira] [Commented] (LUCENE-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225214#comment-17225214 ] ASF subversion and git services commented on LUCENE-9552: - Commit 8bfbed8d4cd476a008ee85310b1f6535920b4622 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8bfbed8 ] LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries (#1940) > Add a LatLonPoint query that accepts an array of LatLonGeometries > - > > Key: LUCENE-9552 > URL: https://issues.apache.org/jira/browse/LUCENE-9552 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > LatLonPoint currently support three types of queries, against a bound box, an > array of polygons or by distance (circle). Therefore if you currently want to > combine a query with two of those geometries, a user will need to combine the > query with a boolean OR. > It would be a nice addition to have a query that accepts an array of > LatLonGeometries and generates that boolean OR query in a single query. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries
[ https://issues.apache.org/jira/browse/LUCENE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225213#comment-17225213 ] ASF subversion and git services commented on LUCENE-9552: - Commit 8bfbed8d4cd476a008ee85310b1f6535920b4622 in lucene-solr's branch refs/heads/master from Ignacio Vera [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8bfbed8 ] LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries (#1940) > Add a LatLonPoint query that accepts an array of LatLonGeometries > - > > Key: LUCENE-9552 > URL: https://issues.apache.org/jira/browse/LUCENE-9552 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > LatLonPoint currently support three types of queries, against a bound box, an > array of polygons or by distance (circle). Therefore if you currently want to > combine a query with two of those geometries, a user will need to combine the > query with a boolean OR. > It would be a nice addition to have a query that accepts an array of > LatLonGeometries and generates that boolean OR query in a single query. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14980) Improve documentation for json facet methods
[ https://issues.apache.org/jira/browse/SOLR-14980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Gheorghe updated SOLR-14980: - Labels: documentation pull-request-available (was: ) > Improve documentation for json facet methods > > > Key: SOLR-14980 > URL: https://issues.apache.org/jira/browse/SOLR-14980 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Radu Gheorghe >Priority: Minor > Labels: documentation, pull-request-available > > As not all methods can be picked. For example, if I have a multi-valued > string field and I ask for `dvhash`, it still picks `dv`. The corresponding > PR is here: https://github.com/apache/lucene-solr/pull/2057 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14980) Improve documentation for json facet methods
[ https://issues.apache.org/jira/browse/SOLR-14980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radu Gheorghe updated SOLR-14980: - Description: As not all methods can be picked. For example, if I have a multi-valued string field and I ask for `dvhash`, it still picks `dv`. The corresponding PR is here: https://github.com/apache/lucene-solr/pull/2057 (was: As not all methods can be picked. For example, if I have a multi-valued string field and I ask for `dvhash`, it still picks `dv`. A PR will follow shortly.) > Improve documentation for json facet methods > > > Key: SOLR-14980 > URL: https://issues.apache.org/jira/browse/SOLR-14980 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Radu Gheorghe >Priority: Minor > > As not all methods can be picked. For example, if I have a multi-valued > string field and I ask for `dvhash`, it still picks `dv`. The corresponding > PR is here: https://github.com/apache/lucene-solr/pull/2057 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14980) Improve documentation for json facet methods
Radu Gheorghe created SOLR-14980: Summary: Improve documentation for json facet methods Key: SOLR-14980 URL: https://issues.apache.org/jira/browse/SOLR-14980 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Radu Gheorghe As not all methods can be picked. For example, if I have a multi-valued string field and I ask for `dvhash`, it still picks `dv`. A PR will follow shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9319) Clean up Sandbox project by retiring/delete functionality or move it to Lucene core
[
https://issues.apache.org/jira/browse/LUCENE-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225096#comment-17225096
]
ASF subversion and git services commented on LUCENE-9319:
-
Commit 6a7131ee246d700c2436a85ddc537575de2aeacf in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6a7131e ]
LUCENE-9319: Clean up package name conflicts for sandbox module (#2023)
> Clean up Sandbox project by retiring/delete functionality or move it to
> Lucene core
> ---
>
> Key: LUCENE-9319
> URL: https://issues.apache.org/jira/browse/LUCENE-9319
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Affects Versions: master (9.0)
>Reporter: David Ryan
>Priority: Major
> Labels: build, features
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> To allow Lucene to be modularised with Java module system there are a few
> preparatory tasks to be completed prior to this being possible. These are
> detailed by Uwe on the mailing list here:
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3c0a5e01d60ff2$563f9c80$02bed580$@thetaphi.de%3e]
>
> The lucene-sandbox currently shares package names with lucene-core which is
> not allowed in the Java module system. There are two ways to deal with this.
> Either prefix all packages with "sandbox" or retire the lucene-sandbox all
> together. As per the email:
> {quote}Cleanup sandbox to prefix all classes there with “sandbox” package and
> where needed remove package-private access. If it’s needed for internal
> access, WTF: Just move the stuff to core! We have a new version 9.0, so
> either retire/delete Sandbox stuff or make it part of Lucene core.
> {quote}
> The suggested way forward is to move sandbox code to core.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14961) ZkMaintenanceUtils.clean(...) doesn't delete files with same length
[ https://issues.apache.org/jira/browse/SOLR-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225007#comment-17225007 ] ASF subversion and git services commented on SOLR-14961: Commit d2c88e3a912bb3882f01e95de5901298a753f915 in lucene-solr's branch refs/heads/branch_8x from Michael Aleythe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d2c88e3 ] SOLR-14961 ZkMaintenanceUtils.clean doesn't remove zk nodes with same length fixes #2042 > ZkMaintenanceUtils.clean(...) doesn't delete files with same length > --- > > Key: SOLR-14961 > URL: https://issues.apache.org/jira/browse/SOLR-14961 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, SolrJ >Affects Versions: 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6.3 >Reporter: def onion >Assignee: Mike Drob >Priority: Major > Labels: newbie > Fix For: master (9.0), 8.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When trying to delete zookeeper path and all of its subnodes via > [ZkMaintenanceUtils.clean(SolrZkClient zkClient, String path, > Predicate > filter)|[https://github.com/apache/lucene-solr/blob/052efd62aec3262744049a9b6002348df1d6e1c4/solr/solrj/src/java/org/apache/solr/common/cloud/ZkMaintenanceUtils.java#L263]] > the Operation fails silently, when a ZKNode contains more than 1 file with > the same file name length. > This is because of the String.length() comparator used in the Treeset for > storing the paths. Paths with the same length are seen as equal and are not > added to the set. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14961) ZkMaintenanceUtils.clean(...) doesn't delete files with same length
[ https://issues.apache.org/jira/browse/SOLR-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-14961: - Resolution: Fixed Status: Resolved (was: Patch Available) I committed this and back ported to 8.x as well. Thanks for the patch, [~defonion] > ZkMaintenanceUtils.clean(...) doesn't delete files with same length > --- > > Key: SOLR-14961 > URL: https://issues.apache.org/jira/browse/SOLR-14961 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, SolrJ >Affects Versions: 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6.3 >Reporter: def onion >Assignee: Mike Drob >Priority: Major > Labels: newbie > Fix For: master (9.0), 8.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When trying to delete zookeeper path and all of its subnodes via > [ZkMaintenanceUtils.clean(SolrZkClient zkClient, String path, > Predicate > filter)|[https://github.com/apache/lucene-solr/blob/052efd62aec3262744049a9b6002348df1d6e1c4/solr/solrj/src/java/org/apache/solr/common/cloud/ZkMaintenanceUtils.java#L263]] > the Operation fails silently, when a ZKNode contains more than 1 file with > the same file name length. > This is because of the String.length() comparator used in the Treeset for > storing the paths. Paths with the same length are seen as equal and are not > added to the set. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14961) ZkMaintenanceUtils.clean(...) doesn't delete files with same length
[ https://issues.apache.org/jira/browse/SOLR-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-14961: - Fix Version/s: 8.8 master (9.0) > ZkMaintenanceUtils.clean(...) doesn't delete files with same length > --- > > Key: SOLR-14961 > URL: https://issues.apache.org/jira/browse/SOLR-14961 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, SolrJ >Affects Versions: 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6.3 >Reporter: def onion >Assignee: Mike Drob >Priority: Major > Labels: newbie > Fix For: master (9.0), 8.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When trying to delete zookeeper path and all of its subnodes via > [ZkMaintenanceUtils.clean(SolrZkClient zkClient, String path, > Predicate > filter)|[https://github.com/apache/lucene-solr/blob/052efd62aec3262744049a9b6002348df1d6e1c4/solr/solrj/src/java/org/apache/solr/common/cloud/ZkMaintenanceUtils.java#L263]] > the Operation fails silently, when a ZKNode contains more than 1 file with > the same file name length. > This is because of the String.length() comparator used in the Treeset for > storing the paths. Paths with the same length are seen as equal and are not > added to the set. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14961) ZkMaintenanceUtils.clean(...) doesn't delete files with same length
[ https://issues.apache.org/jira/browse/SOLR-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225005#comment-17225005 ] ASF subversion and git services commented on SOLR-14961: Commit e7f0294d85dbdc3d3499245c29bc269774c574e2 in lucene-solr's branch refs/heads/master from Michael Aleythe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e7f0294 ] SOLR-14961 ZkMaintenanceUtils.clean doesn't remove zk nodes with same length fixes #2042 > ZkMaintenanceUtils.clean(...) doesn't delete files with same length > --- > > Key: SOLR-14961 > URL: https://issues.apache.org/jira/browse/SOLR-14961 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, SolrJ >Affects Versions: 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6.3 >Reporter: def onion >Assignee: Mike Drob >Priority: Major > Labels: newbie > Time Spent: 0.5h > Remaining Estimate: 0h > > When trying to delete zookeeper path and all of its subnodes via > [ZkMaintenanceUtils.clean(SolrZkClient zkClient, String path, > Predicate > filter)|[https://github.com/apache/lucene-solr/blob/052efd62aec3262744049a9b6002348df1d6e1c4/solr/solrj/src/java/org/apache/solr/common/cloud/ZkMaintenanceUtils.java#L263]] > the Operation fails silently, when a ZKNode contains more than 1 file with > the same file name length. > This is because of the String.length() comparator used in the Treeset for > storing the paths. Paths with the same length are seen as equal and are not > added to the set. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman resolved SOLR-14907.
---
Fix Version/s: 8.8
Resolution: Fixed
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7, 8.8
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> {code}
> "http://localhost:8983/solr/admin/configs?action=UPLOAD=myConfigSet=solrconfig.xml=true;
> {code}
> V2:
> * Uploading a configSet:
> {code} PUT - /api/cluster/configs/{name}{code}
> * Uploading a file in a configSet:
> {code} PUT - /api/cluster/configs/{name}/{filename}{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224935#comment-17224935
]
ASF subversion and git services commented on SOLR-14907:
Commit 655e019a35b24555734cbdef665b04d01ce9647d in lucene-solr's branch
refs/heads/branch_8x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=655e019 ]
SOLR-14907: Adding V2 API for ConfigSet Upload. (#1996)
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> {code}
> "http://localhost:8983/solr/admin/configs?action=UPLOAD=myConfigSet=solrconfig.xml=true;
> {code}
> V2:
> * Uploading a configSet:
> {code} PUT - /api/cluster/configs/{name}{code}
> * Uploading a file in a configSet:
> {code} PUT - /api/cluster/configs/{name}/{filename}{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8982) Make NativeUnixDirectory pure java now that direct IO is possible
[
https://issues.apache.org/jira/browse/LUCENE-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224914#comment-17224914
]
Mike Drob commented on LUCENE-8982:
---
Sort of related - the class comments currently say to do {{ant
build-native-unix}} which is no longer accurate. Has this been ported to
Gradle? How do I test this?
> Make NativeUnixDirectory pure java now that direct IO is possible
> -
>
> Key: LUCENE-8982
> URL: https://issues.apache.org/jira/browse/LUCENE-8982
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/misc
>Reporter: Michael McCandless
>Priority: Major
>
> {{NativeUnixDirectory}} is a {{Directory}} implementation that uses direct IO
> to write newly merged segments. Direct IO bypasses the kernel's buffer cache
> and write cache, making merge writes "invisible" to the kernel, though the
> reads for merging the N segments are still going through the kernel.
> But today, {{NativeUnixDirectory}} uses a small JNI wrapper to access the
> {{O_DIRECT}} flag to {{open}} ... since JDK9 we can now pass that flag in
> pure java code, so we should now fix {{NativeUnixDirectory}} to not use JNI
> anymore.
> We should also run some more realistic benchmarks seeing if this option
> really helps nodes that are doing concurrent indexing (merging) and searching.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14907) Support single file upload/overwrite in configSet API
[
https://issues.apache.org/jira/browse/SOLR-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224894#comment-17224894
]
ASF subversion and git services commented on SOLR-14907:
Commit 5091e75c9d85eda88c52f5ffb6ab395556c044ae in lucene-solr's branch
refs/heads/master from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5091e75 ]
SOLR-14907: Adding V2 API for ConfigSet Upload. (#1996)
> Support single file upload/overwrite in configSet API
> -
>
> Key: SOLR-14907
> URL: https://issues.apache.org/jira/browse/SOLR-14907
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Major
> Fix For: 8.7
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> After SOLR-10391 was implemented, users are now able to overwrite existing
> configSets using the configSet API. However the files uploaded are still
> required to be zipped and indexed from the base configSet path in ZK. Users
> might want to just update a single file, such as a synonyms list, and not
> have to tar it up first.
> The proposed solution is to add parameters to the UPLOAD configSet action, to
> allow this single-file use case. This would utilize the protections already
> provided by the API, such as maintaining the trustiness of configSets being
> modified.
> This feature is part of the solution to replace managed resources, which is
> planned to be deprecated and removed by 9.0 (SOLR-14766).
> The following APIs are being proposed:
> V1:
> Adding to the configSet upload one urlParam, filePath:
> {code}
> "http://localhost:8983/solr/admin/configs?action=UPLOAD=myConfigSet=solrconfig.xml=true;
> {code}
> V2:
> * Uploading a configSet:
> {code} PUT - /api/cluster/configs/{name}{code}
> * Uploading a file in a configSet:
> {code} PUT - /api/cluster/configs/{name}/{filename}{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14979) 'nodeName' should be configurable as a startup option/system property
[
https://issues.apache.org/jira/browse/SOLR-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224895#comment-17224895
]
Chris M. Hostetter commented on SOLR-14979:
---
Here's what i've confirmed from some investigation in to the feasibility of
this idea...
*Most* "collection" level functionality in solr doesn't care about these
nodeNames -- or the fact that they are derived from the host:port of the node
-- instead the {{state.json}} for the collection is consulted to determine the
{{"base_url" + "core"}} of a replica to determine how to send a request to a
particular replica (ie:
{{"http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr; +
"gettingstarted_shard1_replica_n1" =
"http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr/gettingstarted_shard1_replica_n1"}}
However: a handful of _cluster_ level APIs, rely on the fact that
{{ZkStateReader.getBaseUrlForNodeName(String)}} can be used to "reverse" any
"nodeName" found in live_nodes to compute a URL (by combining it with the
{{URL_SCHEME}} cluster property). in order to send cluster level API requests
for things like metrics, adding new collections/replicas, etc...
Strawman proposal:
* modify solr startup to look for a user specified 'nodeName' on startup,
likely via sytem property (example: {{\-Dsolr.node.name=prd-solr-xyz}}
** similar to discussion in SOLR-14958 & SOLR-14934, this should *ONLY* be read
by SolrDispatchFilter, so that it can be overridden by a servlet-context
specified property, so it can be unique per "node" when running multiple (test)
nodes in a given JVM)
** if this option/property is not specified, then the existing code for
generating a _derived_ nodeName should still be used by each node on startup.
** either way the final nodeName value should (probably) still get the same
basic URL encoding that is currently used in order
* when a solr-node registers itself with ZK under {{/live_nodes}} the
ephemeral-node created should continue to be based on the 'nodeName'
** but the _content_ of the ephemeral ZK node (currently empty) should contain
the URL of the solr node
** ie: if a solr node starts up on
{{http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr}} with a user
specified {{solr.node.name=prd-solr-xyz}} then the ephemeral node name should
be {{/live_nodes/prd-solr-xyz}} and the _content_ of that node should be
{{http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr}}
* {{ZkStateReader.getBaseUrlForNodeName(String)}} should return the content of
the {{/live_nodes}} associated with teh specified nodeName
** for back compat / rolling cluster upgrates, we can continue to compute what
the URL _should_ be if the {{live_node}} has no content by follows the existing
naming convention
** this logic of checking the content of (new) ephemeral nodes could be done as
part of {{refreshLiveNodes(...)}} (ie: when the {{/live_nodes}} watcher fires)
... _OR_ ... ZkStateReader fetch the contents of each ephemeral node on demand
as needed -- either way caching the information in a {{Map
nodeNameToNodeUrl}} (that could be purged by {{refreshLiveNodes(...)}})
*** which approach should be taken would depend largely on wether folks think
it's better to have (every) ZkStateReader _allways_ pay the cost of checking
the ephemeral nodes exactly once when a new node is created, or defer the check
so it's only done _if_ that ZkStateReader needs it for some cluster level
command -- but risk concurrent commands redundently quering ZK for the same
info.
> 'nodeName' should be configurable as a startup option/system property
> -
>
> Key: SOLR-14979
> URL: https://issues.apache.org/jira/browse/SOLR-14979
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Currently solr cloud nodes all use a 'nodeName' generated from the hostname +
> port (+ webapp context) (ie:
> {{prd-solr-xyz.region-aaa.my-company.com:8983_solr}} and then register their
> nodeName as an ephemeral zk nodes in {{/live_nodes}}.
> I think it would be helpful if nodes could optionally be configured to use an
> arbitrary (string) node name - w/o any assumptions that it be based on the
> current host/port - so that it's possible to shutdown a node and migrate it
> to a new host and/or port w/o any adverse impacts on other nodes in the
> cluster, or existing cluster configuration/preferences that might care about
> nodeNames.
> This would not only make it easier to migrate solr nodes between "machines"
> in cloud environments where hostnames may be based on racks/regions/etc...
> but it would also make it much easier to deal with stopping/restarting solr
> nodes in tests - w/o needing brittle code to
[jira] [Created] (SOLR-14979) 'nodeName' should be configurable as a startup option/system property
Chris M. Hostetter created SOLR-14979:
-
Summary: 'nodeName' should be configurable as a startup
option/system property
Key: SOLR-14979
URL: https://issues.apache.org/jira/browse/SOLR-14979
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
Currently solr cloud nodes all use a 'nodeName' generated from the hostname +
port (+ webapp context) (ie:
{{prd-solr-xyz.region-aaa.my-company.com:8983_solr}} and then register their
nodeName as an ephemeral zk nodes in {{/live_nodes}}.
I think it would be helpful if nodes could optionally be configured to use an
arbitrary (string) node name - w/o any assumptions that it be based on the
current host/port - so that it's possible to shutdown a node and migrate it to
a new host and/or port w/o any adverse impacts on other nodes in the cluster,
or existing cluster configuration/preferences that might care about nodeNames.
This would not only make it easier to migrate solr nodes between "machines" in
cloud environments where hostnames may be based on racks/regions/etc... but it
would also make it much easier to deal with stopping/restarting solr nodes in
tests - w/o needing brittle code to hope and pray that we can re-use the same
port on restart (SOLR-13871)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224885#comment-17224885 ] Dawid Weiss commented on LUCENE-8626: - I don't mind at all, Christine. Thank you for picking this up. > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13871) JettySolrRunner should stop trying to re-use ports on re-start
[
https://issues.apache.org/jira/browse/SOLR-13871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224868#comment-17224868
]
Chris M. Hostetter commented on SOLR-13871:
---
FWIW, I've been revisiting this idea as part of the work i've started doing
investigating SOLR-14903.
In some (simple) manual experimentation, solr doesn't seem to care at all if a
node goes down, and then comes back up later with a completley different
nodeName because it's now running on a different port – the collection happily
let's the existing replicas come back online at the new URLs.
This is easy to demonstrate with:
* {{bin/solr -e cloud -noprompt}}
* index some data
* {{bin/solr stop -p 7574}}
** note the (2) "gone" replicas in the solr admin UI
* {{bin/solr start -cloud -p -s "example/cloud/node2/solr" -z
localhost:9983}}
** our replicas are back with the same core & coreNode names – just on on a
new nodeName
the only potential problem i can find skimming the code, is at the "cluster"
level – if there are any autoscaling/shard routing level APIs that might care
about the (computed) 'nodeName' or 'hostname:port' ... i suppose it's also
possible that an overseer command might pick a nodeName to use for a command
(ie: add a core) and then before that command can be executed the node is
restarted on a new port and now... i don't know what happens to that command.
does it sit in the overseer queue forever until that nodeName shows up in live
nodes again?
> JettySolrRunner should stop trying to re-use ports on re-start
> --
>
> Key: SOLR-13871
> URL: https://issues.apache.org/jira/browse/SOLR-13871
> Project: Solr
> Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Priority: Major
>
> JettySolrRunner currently has special logic in it's {{start()}} method that
> will cause it (by default) to try to rebind to the port it was previously
> assigned if it's restarting and configured with port '0'
> ie: the first time it starts the OS assigns the port, after that it tries to
> re-use that same port.
> This is a bad idea in general, and leads to (very slow) BindException
> failures in a lot of jenkins tests where nodes are restarted.
> Example...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=ShardSplitTest
> -Dtests.method=testSplitWithChaosMonkey -Dtests.seed=9097C20E8E9ACC68 -Dtes
> ts.multiplier=2 -Dtests.nightly=true -Dtests.slow=true
> -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test
> -data/enwiki.random.lines.txt -Dtests.locale=so-SO -Dtests.timezone=Etc/GMT+9
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR 81.2s J1 | ShardSplitTest.testSplitWithChaosMonkey <<<
>[junit4]> Throwable #1: java.net.BindException: Address already in use
>[junit4]>at
> __randomizedtesting.SeedInfo.seed([9097C20E8E9ACC68:1BB011DFCF9C67EC]:0)
>[junit4]>at java.base/sun.nio.ch.Net.bind0(Native Method)
>[junit4]>at java.base/sun.nio.ch.Net.bind(Net.java:461)
>[junit4]>at java.base/sun.nio.ch.Net.bind(Net.java:453)
>[junit4]>at
> java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
>[junit4]>at
> java.base/sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:80)
>[junit4]>at
> org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:342)
>[junit4]>at
> org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:308)
>[junit4]>at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
>[junit4]>at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
>[junit4]>at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
>[junit4]>at
> org.eclipse.jetty.server.Server.doStart(Server.java:396)
>[junit4]>at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
>[junit4]>at
> org.apache.solr.client.solrj.embedded.JettySolrRunner.retryOnPortBindFailure(JettySolrRunner.java:569)
>[junit4]>at
> org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:508)
>[junit4]>at
> org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:476)
>[junit4]>at
> org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:499)
> {noformat}
> Ideally JettySolrRunner's default behavior should b to just trust it's config
> – binding to a random port (even on restart, even if diff from
[jira] [Commented] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[
https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224856#comment-17224856
]
Michael McCandless commented on LUCENE-9536:
{quote}Thanks [~jtibshirani]!
{quote}
++
> Optimize OrdinalMap when one segment contains all distinct values?
> --
>
> Key: LUCENE-9536
> URL: https://issues.apache.org/jira/browse/LUCENE-9536
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Julie Tibshirani
>Priority: Minor
> Fix For: 8.8
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> For doc values that are not too high cardinality, it seems common to have
> some large segments that contain all distinct values (plus many small
> segments who are missing some values). In this case, we could check if the
> first segment ords map perfectly to global ords and if so store
> `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save
> a small amount of space.
> I don’t think it would help a huge amount, especially since the optimization
> might only kick in with small/ medium cardinalities, which don’t create huge
> `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14925) CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented
[
https://issues.apache.org/jira/browse/SOLR-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224835#comment-17224835
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14925:
--
Hi Rakesh, The exact steps to reproduce are not typically included in the
description. Make sure to have one or more of the mitigation options in place.
> CVE-2020-13957: The checks added to unauthenticated configset uploads can be
> circumvented
> -
>
> Key: SOLR-14925
> URL: https://issues.apache.org/jira/browse/SOLR-14925
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0,
> 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0,
> 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.6, 8.5.1, 8.5.2,
> 8.6.1, 8.6.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7, 8.6.3
>
>
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> 6.6.0 to 6.6.5
> 7.0.0 to 7.7.3
> 8.0.0 to 8.6.2
> Description:
> Solr prevents some features considered dangerous (which could be used for
> remote code execution) to be configured in a ConfigSet that's uploaded via
> API without authentication/authorization. The checks in place to prevent such
> features can be circumvented by using a combination of UPLOAD/CREATE actions.
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Disable UPLOAD command in ConfigSets API if not used by setting the system
> property: {{configset.upload.enabled}} to {{false}} [1]
> * Use Authentication/Authorization and make sure unknown requests aren't
> allowed [2]
> * Upgrade to Solr 8.6.3 or greater.
> * If upgrading is not an option, consider applying the patch in SOLR-14663
> ([3])
> * No Solr API, including the Admin UI, is designed to be exposed to
> non-trusted parties. Tune your firewall so that only trusted computers and
> people are allowed access
> Credit:
> Tomás Fernández Löbbe, András Salamon
> References:
> [1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
> [2]
> https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
> [3] https://issues.apache.org/jira/browse/SOLR-14663
> [4] https://issues.apache.org/jira/browse/SOLR-14925
> [5] https://wiki.apache.org/solr/SolrSecurity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14925) CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented
[
https://issues.apache.org/jira/browse/SOLR-14925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14925:
-
Description:
Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
6.6.0 to 6.6.6
7.0.0 to 7.7.3
8.0.0 to 8.6.2
Description:
Solr prevents some features considered dangerous (which could be used for
remote code execution) to be configured in a ConfigSet that's uploaded via API
without authentication/authorization. The checks in place to prevent such
features can be circumvented by using a combination of UPLOAD/CREATE actions.
Mitigation:
Any of the following are enough to prevent this vulnerability:
* Disable UPLOAD command in ConfigSets API if not used by setting the system
property: {{configset.upload.enabled}} to {{false}} [1]
* Use Authentication/Authorization and make sure unknown requests aren't
allowed [2]
* Upgrade to Solr 8.6.3 or greater.
* If upgrading is not an option, consider applying the patch in SOLR-14663 ([3])
* No Solr API, including the Admin UI, is designed to be exposed to non-trusted
parties. Tune your firewall so that only trusted computers and people are
allowed access
Credit:
Tomás Fernández Löbbe, András Salamon
References:
[1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
[2]
https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
[3] https://issues.apache.org/jira/browse/SOLR-14663
[4] https://issues.apache.org/jira/browse/SOLR-14925
[5] https://wiki.apache.org/solr/SolrSecurity
was:
Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
6.6.0 to 6.6.5
7.0.0 to 7.7.3
8.0.0 to 8.6.2
Description:
Solr prevents some features considered dangerous (which could be used for
remote code execution) to be configured in a ConfigSet that's uploaded via API
without authentication/authorization. The checks in place to prevent such
features can be circumvented by using a combination of UPLOAD/CREATE actions.
Mitigation:
Any of the following are enough to prevent this vulnerability:
* Disable UPLOAD command in ConfigSets API if not used by setting the system
property: {{configset.upload.enabled}} to {{false}} [1]
* Use Authentication/Authorization and make sure unknown requests aren't
allowed [2]
* Upgrade to Solr 8.6.3 or greater.
* If upgrading is not an option, consider applying the patch in SOLR-14663 ([3])
* No Solr API, including the Admin UI, is designed to be exposed to non-trusted
parties. Tune your firewall so that only trusted computers and people are
allowed access
Credit:
Tomás Fernández Löbbe, András Salamon
References:
[1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
[2]
https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
[3] https://issues.apache.org/jira/browse/SOLR-14663
[4] https://issues.apache.org/jira/browse/SOLR-14925
[5] https://wiki.apache.org/solr/SolrSecurity
> CVE-2020-13957: The checks added to unauthenticated configset uploads can be
> circumvented
> -
>
> Key: SOLR-14925
> URL: https://issues.apache.org/jira/browse/SOLR-14925
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0,
> 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0,
> 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.6, 8.5.1, 8.5.2,
> 8.6.1, 8.6.2
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7, 8.6.3
>
>
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> 6.6.0 to 6.6.6
> 7.0.0 to 7.7.3
> 8.0.0 to 8.6.2
> Description:
> Solr prevents some features considered dangerous (which could be used for
> remote code execution) to be configured in a ConfigSet that's uploaded via
> API without authentication/authorization. The checks in place to prevent such
> features can be circumvented by using a combination of UPLOAD/CREATE actions.
> Mitigation:
> Any of the following are enough to prevent this vulnerability:
> * Disable UPLOAD command in ConfigSets API if not used by setting the system
> property: {{configset.upload.enabled}} to {{false}} [1]
> * Use Authentication/Authorization and make sure unknown requests aren't
> allowed [2]
> * Upgrade to Solr 8.6.3 or greater.
> * If upgrading is not an option, consider applying the patch in SOLR-14663
> ([3])
> * No Solr API, including the Admin UI, is designed to be exposed to
> non-trusted parties. Tune your firewall so that only trusted computers and
> people are allowed access
> Credit:
> Tomás
[jira] [Commented] (LUCENE-8626) standardise test class naming
[
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224800#comment-17224800
]
Christine Poerschke commented on LUCENE-8626:
-
bq. ... the PR which makes it easier to do it in smaller steps (enforces any
new classes to follow the convention though). ...
[~dweiss] - I pushed a commit to your PR --
https://github.com/apache/lucene-solr/pull/1743 -- which aims to avoid the
"both {{TestFooBar.java}} and {{FooBarTest.java}} present" scenario being
reintroduced. Hope you don't mind.
> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch,
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket
> here to start to make it happen?
> History: This ticket was created as
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8626) standardise test class naming
[
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224792#comment-17224792
]
Christine Poerschke commented on LUCENE-8626:
-
bq. Looking for tests where we currently have both {{TestFooBar.java}} and
{{FooBarTest.java}} present ...
These have now been taken care of via one append and three renames:
* https://github.com/apache/lucene-solr/pull/1745
* https://github.com/apache/lucene-solr/pull/1790
* https://github.com/apache/lucene-solr/pull/1890
* https://github.com/apache/lucene-solr/pull/2032
> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch,
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket
> here to start to make it happen?
> History: This ticket was created as
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14978) Run OOM Killer Script in Foreground Solr
Mike Drob created SOLR-14978: Summary: Run OOM Killer Script in Foreground Solr Key: SOLR-14978 URL: https://issues.apache.org/jira/browse/SOLR-14978 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: scripts and tools Reporter: Mike Drob Assignee: Mike Drob As discussed in SOLR-8145 before the advent of Docker containers, Solr did not usually run unattended and in the foreground so there was not much reason to run the OOM killer script in that mode. However, not it makes sense to handle in foreground as well. We should also consider making it easier to configure heap dumps as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14413) allow timeAllowed and cursorMark parameters
[
https://issues.apache.org/jira/browse/SOLR-14413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224785#comment-17224785
]
John Gallagher commented on SOLR-14413:
---
[~mdrob], [~bvd], any thoughts on the updated test and documentation?
> allow timeAllowed and cursorMark parameters
> ---
>
> Key: SOLR-14413
> URL: https://issues.apache.org/jira/browse/SOLR-14413
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: John Gallagher
>Priority: Minor
> Attachments: SOLR-14413-bram.patch, SOLR-14413-jg-update1.patch,
> SOLR-14413-jg-update2.patch, SOLR-14413-jg-update3.patch, SOLR-14413.patch,
> Screen Shot 2020-10-23 at 10.08.26 PM.png, Screen Shot 2020-10-23 at 10.09.11
> PM.png, image-2020-08-18-16-56-41-736.png, image-2020-08-18-16-56-59-178.png,
> image-2020-08-21-14-18-36-229.png, timeallowed_cursormarks_results.txt
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Ever since cursorMarks were introduced in SOLR-5463 in 2014, cursorMark and
> timeAllowed parameters were not allowed in combination ("Can not search using
> both cursorMark and timeAllowed")
> , from [QueryComponent.java|#L359]]:
>
> {code:java}
>
> if (null != rb.getCursorMark() && 0 < timeAllowed) {
> // fundamentally incompatible
> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Can not
> search using both " + CursorMarkParams.CURSOR_MARK_PARAM + " and " +
> CommonParams.TIME_ALLOWED);
> } {code}
> While theoretically impure to use them in combination, it is often desirable
> to support cursormarks-style deep paging and attempt to protect Solr nodes
> from runaway queries using timeAllowed, in the hopes that most of the time,
> the query completes in the allotted time, and there is no conflict.
>
> However if the query takes too long, it may be preferable to end the query
> and protect the Solr node and provide the user with a somewhat inaccurate
> sorted list. As noted in SOLR-6930, SOLR-5986 and others, timeAllowed is
> frequently used to prevent runaway load. In fact, cursorMark and
> shards.tolerant are allowed in combination, so any argument in favor of
> purity would be a bit muddied in my opinion.
>
> This was discussed once in the mailing list that I can find:
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201506.mbox/%3c5591740b.4080...@elyograg.org%3E]
> It did not look like there was strong support for preventing the combination.
>
> I have tested cursorMark and timeAllowed combination together, and even when
> partial results are returned because the timeAllowed is exceeded, the
> cursorMark response value is still valid and reasonable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[ https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224771#comment-17224771 ] Adrien Grand commented on LUCENE-9536: -- Thanks [~jtibshirani]! > Optimize OrdinalMap when one segment contains all distinct values? > -- > > Key: LUCENE-9536 > URL: https://issues.apache.org/jira/browse/LUCENE-9536 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Fix For: 8.8 > > Time Spent: 3h > Remaining Estimate: 0h > > For doc values that are not too high cardinality, it seems common to have > some large segments that contain all distinct values (plus many small > segments who are missing some values). In this case, we could check if the > first segment ords map perfectly to global ords and if so store > `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save > a small amount of space. > I don’t think it would help a huge amount, especially since the optimization > might only kick in with small/ medium cardinalities, which don’t create huge > `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[ https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-9536. -- Fix Version/s: 8.8 Resolution: Fixed > Optimize OrdinalMap when one segment contains all distinct values? > -- > > Key: LUCENE-9536 > URL: https://issues.apache.org/jira/browse/LUCENE-9536 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Fix For: 8.8 > > Time Spent: 3h > Remaining Estimate: 0h > > For doc values that are not too high cardinality, it seems common to have > some large segments that contain all distinct values (plus many small > segments who are missing some values). In this case, we could check if the > first segment ords map perfectly to global ords and if so store > `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save > a small amount of space. > I don’t think it would help a huge amount, especially since the optimization > might only kick in with small/ medium cardinalities, which don’t create huge > `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[ https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224756#comment-17224756 ] ASF subversion and git services commented on LUCENE-9536: - Commit 2a2e612db014c90fe6ea9b212c135d94ba063de6 in lucene-solr's branch refs/heads/master from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2a2e612 ] LUCENE-9536: CHANGES entry. > Optimize OrdinalMap when one segment contains all distinct values? > -- > > Key: LUCENE-9536 > URL: https://issues.apache.org/jira/browse/LUCENE-9536 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Time Spent: 3h > Remaining Estimate: 0h > > For doc values that are not too high cardinality, it seems common to have > some large segments that contain all distinct values (plus many small > segments who are missing some values). In this case, we could check if the > first segment ords map perfectly to global ords and if so store > `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save > a small amount of space. > I don’t think it would help a huge amount, especially since the optimization > might only kick in with small/ medium cardinalities, which don’t create huge > `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[ https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224755#comment-17224755 ] ASF subversion and git services commented on LUCENE-9536: - Commit 9bd28598d62a380504d76096bcfd40bc0c92d5d4 in lucene-solr's branch refs/heads/branch_8x from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9bd2859 ] LUCENE-9536: CHANGES entry. > Optimize OrdinalMap when one segment contains all distinct values? > -- > > Key: LUCENE-9536 > URL: https://issues.apache.org/jira/browse/LUCENE-9536 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Time Spent: 3h > Remaining Estimate: 0h > > For doc values that are not too high cardinality, it seems common to have > some large segments that contain all distinct values (plus many small > segments who are missing some values). In this case, we could check if the > first segment ords map perfectly to global ords and if so store > `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save > a small amount of space. > I don’t think it would help a huge amount, especially since the optimization > might only kick in with small/ medium cardinalities, which don’t create huge > `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[ https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224754#comment-17224754 ] ASF subversion and git services commented on LUCENE-9536: - Commit 169ce0c9581f023fed4c8f2cf7aa25af8d0b192c in lucene-solr's branch refs/heads/branch_8x from Julie Tibshirani [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=169ce0c ] LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values. (#1948) For doc values that are not too high cardinality, it is common for some large segments to contain all distinct values. In this case, we can check if the first segment ords map perfectly to global ords, and if so store the global ord deltas and first segment indices as `LongValues.ZEROES` to save some space. > Optimize OrdinalMap when one segment contains all distinct values? > -- > > Key: LUCENE-9536 > URL: https://issues.apache.org/jira/browse/LUCENE-9536 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Time Spent: 3h > Remaining Estimate: 0h > > For doc values that are not too high cardinality, it seems common to have > some large segments that contain all distinct values (plus many small > segments who are missing some values). In this case, we could check if the > first segment ords map perfectly to global ords and if so store > `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save > a small amount of space. > I don’t think it would help a huge amount, especially since the optimization > might only kick in with small/ medium cardinalities, which don’t create huge > `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[ https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224744#comment-17224744 ] ASF subversion and git services commented on LUCENE-9536: - Commit 8f004f7a38947176eecf9056087311f39d7504d6 in lucene-solr's branch refs/heads/master from Julie Tibshirani [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f004f7 ] LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values. (#1948) LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values. For doc values that are not too high cardinality, it is common for some large segments to contain all distinct values. In this case, we can check if the first segment ords map perfectly to global ords, and if so store the global ord deltas and first segment indices as `LongValues.ZEROES` to save some space. > Optimize OrdinalMap when one segment contains all distinct values? > -- > > Key: LUCENE-9536 > URL: https://issues.apache.org/jira/browse/LUCENE-9536 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Time Spent: 3h > Remaining Estimate: 0h > > For doc values that are not too high cardinality, it seems common to have > some large segments that contain all distinct values (plus many small > segments who are missing some values). In this case, we could check if the > first segment ords map perfectly to global ords and if so store > `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save > a small amount of space. > I don’t think it would help a huge amount, especially since the optimization > might only kick in with small/ medium cardinalities, which don’t create huge > `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9536) Optimize OrdinalMap when one segment contains all distinct values?
[ https://issues.apache.org/jira/browse/LUCENE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224743#comment-17224743 ] ASF subversion and git services commented on LUCENE-9536: - Commit 8f004f7a38947176eecf9056087311f39d7504d6 in lucene-solr's branch refs/heads/master from Julie Tibshirani [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f004f7 ] LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values. (#1948) LUCENE-9536: Optimize OrdinalMap when one segment contains all distinct values. For doc values that are not too high cardinality, it is common for some large segments to contain all distinct values. In this case, we can check if the first segment ords map perfectly to global ords, and if so store the global ord deltas and first segment indices as `LongValues.ZEROES` to save some space. > Optimize OrdinalMap when one segment contains all distinct values? > -- > > Key: LUCENE-9536 > URL: https://issues.apache.org/jira/browse/LUCENE-9536 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Julie Tibshirani >Priority: Minor > Time Spent: 3h > Remaining Estimate: 0h > > For doc values that are not too high cardinality, it seems common to have > some large segments that contain all distinct values (plus many small > segments who are missing some values). In this case, we could check if the > first segment ords map perfectly to global ords and if so store > `globalOrdDeltas` and `firstSegments` as `LongValues.ZEROES`. This could save > a small amount of space. > I don’t think it would help a huge amount, especially since the optimization > might only kick in with small/ medium cardinalities, which don’t create huge > `OrdinalMap` instances anyways? But it is simple and seemed worth mentioning. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14865) clarify index merge metrics configuration documentation
[
https://issues.apache.org/jira/browse/SOLR-14865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-14865.
Fix Version/s: 8.8
master (9.0)
Resolution: Fixed
> clarify index merge metrics configuration documentation
> ---
>
> Key: SOLR-14865
> URL: https://issues.apache.org/jira/browse/SOLR-14865
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The documentation – e.g.
> [https://lucene.apache.org/solr/guide/8_6/metrics-reporting.html#index-merge-metrics]
> – currently mentions that _"Basic metrics are always collected"_ but
> experimentally and from a quick look at the code – e.g.
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/core/src/java/org/apache/solr/update/SolrIndexWriter.java#L146]
> – it appears that a {{metrics}} element needs to be configured and that it
> needs to have either a {{merge}} or a {{mergeDetails}} element configured as
> true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14865) clarify index merge metrics configuration documentation
[
https://issues.apache.org/jira/browse/SOLR-14865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224740#comment-17224740
]
ASF subversion and git services commented on SOLR-14865:
Commit 50e68ee6cd9a74e4986a303044d0708b3681c9f6 in lucene-solr's branch
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=50e68ee ]
SOLR-14865: 'Index Merge Metrics' documentation correction (#1870)
> clarify index merge metrics configuration documentation
> ---
>
> Key: SOLR-14865
> URL: https://issues.apache.org/jira/browse/SOLR-14865
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The documentation – e.g.
> [https://lucene.apache.org/solr/guide/8_6/metrics-reporting.html#index-merge-metrics]
> – currently mentions that _"Basic metrics are always collected"_ but
> experimentally and from a quick look at the code – e.g.
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/core/src/java/org/apache/solr/update/SolrIndexWriter.java#L146]
> – it appears that a {{metrics}} element needs to be configured and that it
> needs to have either a {{merge}} or a {{mergeDetails}} element configured as
> true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14865) clarify index merge metrics configuration documentation
[
https://issues.apache.org/jira/browse/SOLR-14865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224732#comment-17224732
]
ASF subversion and git services commented on SOLR-14865:
Commit da0004875b5dbe59f3c3ff7cdfe03e474f3f165a in lucene-solr's branch
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=da00048 ]
SOLR-14865: 'Index Merge Metrics' documentation correction (#1870)
> clarify index merge metrics configuration documentation
> ---
>
> Key: SOLR-14865
> URL: https://issues.apache.org/jira/browse/SOLR-14865
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The documentation – e.g.
> [https://lucene.apache.org/solr/guide/8_6/metrics-reporting.html#index-merge-metrics]
> – currently mentions that _"Basic metrics are always collected"_ but
> experimentally and from a quick look at the code – e.g.
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/core/src/java/org/apache/solr/update/SolrIndexWriter.java#L146]
> – it appears that a {{metrics}} element needs to be configured and that it
> needs to have either a {{merge}} or a {{mergeDetails}} element configured as
> true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14937) client.queryDefaults().set(...) misunderstanding in JSON facet tests
[
https://issues.apache.org/jira/browse/SOLR-14937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-14937.
Fix Version/s: 8.8
master (9.0)
Resolution: Fixed
> client.queryDefaults().set(...) misunderstanding in JSON facet tests
>
>
> Key: SOLR-14937
> URL: https://issues.apache.org/jira/browse/SOLR-14937
> Project: Solr
> Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I noticed today that we have
> {code:java}
> client.queryDefaults().set("shards", "foo", "debugQuery", "bar");
> {code}
> style usage in some tests and whilst this was likely intended to result in
> {code:java}
> { "shards" : "foo", "debugQuery" : "bar" }
> {code}
> query defaults it actually results in
> {code:java}
> { "shards" : [ "foo", "debugQuery" , "bar" ] }
> {code}
> query defaults based on the {{ModifiableSolrParams.set}} implementation:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.3/solr/solrj/src/java/org/apache/solr/common/params/ModifiableSolrParams.java#L86-L96]
> A possible alternative is
> {code:java}
> client.queryDefaults().set("shards", "foo").set("debugQuery", "bar");
> {code}
> style usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14937) client.queryDefaults().set(...) misunderstanding in JSON facet tests
[
https://issues.apache.org/jira/browse/SOLR-14937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224727#comment-17224727
]
ASF subversion and git services commented on SOLR-14937:
Commit aabbbdc928a1e74510c3526ebb31f2e7a88bdac1 in lucene-solr's branch
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aabbbdc ]
SOLR-14937: Correct client.queryDefaults().set(...) calls in some JSON facet
tests. (#2031)
> client.queryDefaults().set(...) misunderstanding in JSON facet tests
>
>
> Key: SOLR-14937
> URL: https://issues.apache.org/jira/browse/SOLR-14937
> Project: Solr
> Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I noticed today that we have
> {code:java}
> client.queryDefaults().set("shards", "foo", "debugQuery", "bar");
> {code}
> style usage in some tests and whilst this was likely intended to result in
> {code:java}
> { "shards" : "foo", "debugQuery" : "bar" }
> {code}
> query defaults it actually results in
> {code:java}
> { "shards" : [ "foo", "debugQuery" , "bar" ] }
> {code}
> query defaults based on the {{ModifiableSolrParams.set}} implementation:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.3/solr/solrj/src/java/org/apache/solr/common/params/ModifiableSolrParams.java#L86-L96]
> A possible alternative is
> {code:java}
> client.queryDefaults().set("shards", "foo").set("debugQuery", "bar");
> {code}
> style usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14972) Change default port of prometheus exporter
[ https://issues.apache.org/jira/browse/SOLR-14972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-14972. Fix Version/s: master (9.0) Resolution: Fixed > Change default port of prometheus exporter > -- > > Key: SOLR-14972 > URL: https://issues.apache.org/jira/browse/SOLR-14972 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - prometheus-exporter >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > The default port of prometheus exporter is 9983, which is exactly the same > port as the embedded Zookeeper (8983+1000), which would prevent someone from > testing both on their laptop with default settings. > Use e.g. 8989 instead -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14972) Change default port of prometheus exporter
[ https://issues.apache.org/jira/browse/SOLR-14972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224652#comment-17224652 ] ASF subversion and git services commented on SOLR-14972: Commit 0c3f2f4ac817fb4af9aef085cf1aaa5c01db52c7 in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0c3f2f4 ] SOLR-14972: Change default port of prometheus exporter to 8989 (#2046) > Change default port of prometheus exporter > -- > > Key: SOLR-14972 > URL: https://issues.apache.org/jira/browse/SOLR-14972 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - prometheus-exporter >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > The default port of prometheus exporter is 9983, which is exactly the same > port as the embedded Zookeeper (8983+1000), which would prevent someone from > testing both on their laptop with default settings. > Use e.g. 8989 instead -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14977) Container plugins need a way to be configured
Andrzej Bialecki created SOLR-14977:
---
Summary: Container plugins need a way to be configured
Key: SOLR-14977
URL: https://issues.apache.org/jira/browse/SOLR-14977
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: Plugin system
Reporter: Andrzej Bialecki
Container plugins are defined in {{/clusterprops.json:/plugin}} using a simple
{{PluginMeta}} bean. This is sufficient for implementations that don't need any
configuration except for the {{pathPrefix}} but insufficient for anything else
that needs more configuration parameters.
An example would be a {{CollectionsRepairEventListener}} plugin proposed in
PR-1962, which needs parameters such as the list of collections, {{waitFor}},
maximum operations allowed, etc. to properly function.
This issue proposes to extend the {{PluginMeta}} bean to allow a {{Map}} configuration parameters.
There is an interface that we could potentially use ({{MapInitializedPlugin}}
but it works only with {{String}} values. This is not optimal because it
requires additional type-safety validation from the consumers. The existing
{{PluginInfo}} / {{PluginInfoInitialized}} interface is too complex for this
purpose.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8183) HyphenationCompoundWordTokenFilter creates overlapping tokens with onlyLongestMatch enabled
[
https://issues.apache.org/jira/browse/LUCENE-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224604#comment-17224604
]
Martin Demberger commented on LUCENE-8183:
--
Hi Uwe,
is there any way I can fasten the merge. We have a few customer which wait for
this fix because our search very often falls into this pithole.
> HyphenationCompoundWordTokenFilter creates overlapping tokens with
> onlyLongestMatch enabled
> ---
>
> Key: LUCENE-8183
> URL: https://issues.apache.org/jira/browse/LUCENE-8183
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 6.6
> Environment: Configuration of the analyzer:
>
>
> hyphenator="lang/hyph_de_DR.xml" encoding="iso-8859-1"
> dictionary="lang/wordlist_de.txt"
> onlyLongestMatch="true"/>
>
>Reporter: Rupert Westenthaler
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8183_20180223_rwesten.diff,
> LUCENE-8183_20180227_rwesten.diff, lucene-8183.zip
>
>
> The HyphenationCompoundWordTokenFilter creates overlapping tokens even if
> onlyLongestMatch is enabled.
> Example:
> Dictionary: {{gesellschaft}}, {{schaft}}
> Hyphenator: {{de_DR.xml}} //from Apche Offo
> onlyLongestMatch: true
>
> |text|gesellschaft|gesellschaft|schaft|
> |raw_bytes|[67 65 73 65 6c 6c 73 63 68 61 66 74]|[67 65 73 65 6c 6c 73 63 68
> 61 66 74]|[73 63 68 61 66 74]|
> |start|0|0|0|
> |end|12|12|12|
> |positionLength|1|1|1|
> |type|word|word|word|
> |position|1|1|1|
> IMHO this includes 2 unexpected Tokens
> # the 2nd 'gesellschaft' as it duplicates the original token
> # the 'schaft' as it is a sub-token 'gesellschaft' that is present in the
> dictionary
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
