[ 
https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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/<coll>/collectionprops.json}} znode 
for each collection in json format. The properties can be changed via 
{{/solr/admin/collections?action=COLLECTIONPROP?name=<coll>&propertyName=<prop>&value=<val>}}.

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/<coll>/collectionprops.json``` znode 
for each collection in json format. The properties can be changed via 
/solr/admin/collections?action=COLLECTIONPROP?name=<coll>&propertyName=<prop>&value=<val>.

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

Reply via email to