[jira] [Commented] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399125#comment-16399125 ] Peter Rusko commented on SOLR-11960: I've updated the patch. Removed the watcher creation/deletion when registering and unregistering the core and I'm also re-registering watchers in createClusterStateWatchersAndUpdate now. > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Assignee: Tomás Fernández Löbbe >Priority: Blocker > Fix For: 7.3 > > Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, > SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-11960: --- Attachment: SOLR-11960_2.patch > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Assignee: Tomás Fernández Löbbe >Priority: Blocker > Fix For: 7.3 > > Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, > SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11960) Add collection level properties
[
https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381323#comment-16381323
]
Peter Rusko commented on SOLR-11960:
{quote}BTW for this issue I personally would have chosen to store collection
properties on the state.json for the collection rather than put this somewhere
else. Consider all the other internal properties which are already in
state.json (e.g. replicationFactor etc.). Was this considered? Why not? Pros
are simplicity of backup and no need to delete with collection deletion, and
using the same watcher mechanism?
{quote}
Yes, I considered it. There are two reasons for choosing a separate json. First
the frequency of the change is different. Collection properties would change
way less frequently than state.json and not parsing out the properties blob on
every state change seemed the right way to go. But more importantly, state.json
changes should go via the overseer, which seemed to be a bit of an overkill
here.
> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch,
> SOLR-11960.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining
> properties that affect a single collection. Collection properties could be
> stored in a single zookeeper node per collection, making it possible to
> trigger zookeeper watchers for only those Solr nodes that have cores of that
> collection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-11960: --- Attachment: SOLR-11960.patch > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Assignee: Tomás Fernández Löbbe >Priority: Major > Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, > SOLR-11960.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-11960: --- Attachment: SOLR-11960.patch > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Assignee: Tomás Fernández Löbbe >Priority: Major > Attachments: SOLR-11960.patch, SOLR-11960.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369607#comment-16369607 ] Peter Rusko commented on SOLR-11960: Thanks for the review, here's the updated patch: [^SOLR-11960.patch] > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Assignee: Tomás Fernández Löbbe >Priority: Major > Attachments: SOLR-11960.patch, SOLR-11960.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-11960: --- Attachment: (was: 0001-SOLR-11960-add-collection-properties-support.patch) > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Priority: Major > Attachments: SOLR-11960.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359068#comment-16359068 ] Peter Rusko commented on SOLR-8389: --- Hi Amrit, You've completely removed all the collection properties code, which could be useful not just for this patch, but some other use cases too. I've created SOLR-11960 to track that feature. I still think storing the properties that way has a lot of value and you could use it for CDCR properties too. It is more generic, and should be easily extendable, should you need to add validation of the property, or a way to set them at collection creation time. > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Attachments: SOLR-8389.patch, SOLR-8389.patch, SOLR-8389.patch, > SOLR-8389.patch, SOLR-8389.patch, SOLR-8389.patch, SOLR-8389.patch, > SOLR-8389.patch, SOLR-8389.patch, SOLR-8389.patch, SOLR-8389.patch, Screen > Shot 2017-12-21 at 5.44.36 PM.png > > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-11960: --- Attachment: SOLR-11960.patch > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Priority: Major > Attachments: 0001-SOLR-11960-add-collection-properties-support.patch, > SOLR-11960.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16357769#comment-16357769 ] Peter Rusko commented on SOLR-11960: Here's a proposed patch for collection properties and a new collection admin command that allows changing those properties: [^SOLR-11960.patch] > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Priority: Major > Attachments: 0001-SOLR-11960-add-collection-properties-support.patch, > SOLR-11960.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-11960: --- Attachment: 0001-SOLR-11960-add-collection-properties-support.patch > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Peter Rusko >Priority: Major > Attachments: 0001-SOLR-11960-add-collection-properties-support.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11960) Add collection level properties
Peter Rusko created SOLR-11960: -- Summary: Add collection level properties Key: SOLR-11960 URL: https://issues.apache.org/jira/browse/SOLR-11960 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Peter Rusko Solr has cluster properties, but no easy and extendable way of defining properties that affect a single collection. Collection properties could be stored in a single zookeeper node per collection, making it possible to trigger zookeeper watchers for only those Solr nodes that have cores of that collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295829#comment-16295829 ] Peter Rusko commented on SOLR-8389: --- This patch above is just providing a way for properties to be assigned to collections. It is pretty generic at the moment, the value can be anything, so you can assign any JSON value you want, it won't require a target collection to be set. The interpretation of the value comes down to the code reading the value. It looks like it's missing two things. None of those seem to be important for the first iteration to me. One is the ability to assign a value at the collection creation time and the other is a support of a property value validator, which could check that the assigned value has certain fields for instance. Is it okay if we merge this patch as it is so far, provided someone can review it? Then I, or someone else with better ideas can add the two missing pieces above later, if they are needed. > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-8389.patch > > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256127#comment-16256127 ] Peter Rusko commented on SOLR-8389: --- Hi Amrit, I didn't have as much time as I wanted, but finally, here's the patch. This doesn't let you set up the properties at the collection creation, but I can add that too if it's needed. Let me know what you think. Thanks, Peter > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-8389.patch > > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-8389: -- Attachment: SOLR-8389.patch > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-8389.patch > > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203842#comment-16203842 ] Peter Rusko commented on SOLR-8389: --- The main concern was exactly the update frequency, that's why I separated this from state.json, to clusterprops.json. It will have its own watcher and won't be affected by clusterstate changes. The intention was to put user-defined properties here, which can be changed without restarting solr. Varun, I'm not sure what you mean by that. Currently unrelated collection property changes still trigger all the listeners, but given that they are all supposed to be rare (though nothing prevents anyone from writing properties from the code I guess), I don't see this as a problem. > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[
https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197742#comment-16197742
]
Peter Rusko edited comment on SOLR-8389 at 10/10/17 12:07 AM:
--
Hi Amrit,
I’m working on something that would solve this problem. I already have a
working prototype and can upload a patch soon.
The idea is to add the concept of collection properties. It’s a key value map
that would be stored in the {{collections//collectionprops.json}} znode
for each collection in json format. The properties can be changed via
{{/solr/admin/collections?action=COLLECTIONPROP?name===}}.
ZkStateReader keeps a set of watchers for each of them (one per collection), in
a similar way to state.json. But on top of caching the values, it provides a
method where you can add listeners, that will be called each time the znode is
changed.
I think this pretty much aligns with your idea, but will be a more scalable
approach for the watchers. It can accommodate the CDCR properties as well as
any other properties that could be needed for the collection. Let me know if
this could work for you or if you have any questions.
was (Author: prusko):
Hi Amrit,
I’m working on something that would solve this problem. I already have a
working prototype and can upload a patch soon.
The idea is to add the concept of collection properties. It’s a key value map
that would be stored in the ```collections//collectionprops.json``` znode
for each collection in json format. The properties can be changed via
/solr/admin/collections?action=COLLECTIONPROP?name===.
ZkStateReader keeps a set of watchers for each of them (one per collection), in
a similar way to state.json. But on top of caching the values, it provides a
method where you can add listeners, that will be called each time the znode is
changed.
I think this pretty much aligns with your idea, but will be a more scalable
approach for the watchers. It can accommodate the CDCR properties as well as
any other properties that could be needed for the collection. Let me know if
this could work for you or if you have any questions.
> Convert CDCR peer cluster and other configurations into collection properties
> modifiable via APIs
> -
>
> Key: SOLR-8389
> URL: https://issues.apache.org/jira/browse/SOLR-8389
> Project: Solr
> Issue Type: Improvement
> Components: CDCR, SolrCloud
>Reporter: Shalin Shekhar Mangar
>
> CDCR configuration is kept inside solrconfig.xml which makes it difficult to
> add or change peer cluster configuration.
> I propose to move all CDCR config to collection level properties in cluster
> state so that they can be modified using the existing modify collection API.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197742#comment-16197742 ] Peter Rusko commented on SOLR-8389: --- Hi Amrit, I’m working on something that would solve this problem. I already have a working prototype and can upload a patch soon. The idea is to add the concept of collection properties. It’s a key value map that would be stored in the ```collections//collectionprops.json``` znode for each collection in json format. The properties can be changed via /solr/admin/collections?action=COLLECTIONPROP?name===. ZkStateReader keeps a set of watchers for each of them (one per collection), in a similar way to state.json. But on top of caching the values, it provides a method where you can add listeners, that will be called each time the znode is changed. I think this pretty much aligns with your idea, but will be a more scalable approach for the watchers. It can accommodate the CDCR properties as well as any other properties that could be needed for the collection. Let me know if this could work for you or if you have any questions. > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9158) Solr returns 500 with "No live SolrServers available to handle this request" for complexphrase queries exceeding maxBooleanClauses
Peter Rusko created SOLR-9158: - Summary: Solr returns 500 with "No live SolrServers available to handle this request" for complexphrase queries exceeding maxBooleanClauses Key: SOLR-9158 URL: https://issues.apache.org/jira/browse/SOLR-9158 Project: Solr Issue Type: Bug Reporter: Peter Rusko Priority: Minor When using complexphrase query parser and passing it a wildcard term, it gets replaced by all possible matching terms. This can result in a boolean query with many clauses. When this happens, The server responds with the error message "org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request" instead of showing the real issue (which can be found in the trace). The error code should also be 400. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
