[ 
https://issues.apache.org/jira/browse/SOLR-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503533#comment-14503533
 ] 

Hrishikesh Gadre commented on SOLR-7176:
----------------------------------------

>>I believe I would prefer 1) because it is the most generally useable solution 
>>to the problem. Compare-and-swap (even combined with ZK multi-op feature) 
>>will not always be sufficient for operations that want to update several 
>>znodes atomically - and who knows, maybe some day we also want to that kind 
>>of stuff using command-line. Taking a pessimistic lock (like the 
>>Overseer-lock) always will be sufficient.

The original use-case for this feature is to have an ability to update the 
cluster properties even when Solr cluster is offline. Hence the fix for this 
use-case can not really depend upon the overseer lock. Also as others mentioned 
in the JIRA above, we are trying to address a very specific problem (i.e. 
ability to update contents of /clusterprops.json ZNODE). Typically these 
updates should be very infrequent (e.g. why would user flip between SSL/non-SSL 
mode frequently ?). So I believe using optimistic locking should be fine. 

Thoughts?

 

> allow zkcli to modify JSON
> --------------------------
>
>                 Key: SOLR-7176
>                 URL: https://issues.apache.org/jira/browse/SOLR-7176
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Yonik Seeley
>            Assignee: Noble Paul
>            Priority: Minor
>         Attachments: SOLR-7176.patch, SOLR-7176.patch, SOLR-7176.patch
>
>
> To enable SSL, we have instructions like the following:
> {code}
> server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd put 
> /clusterprops.json '{"urlScheme":"https"}'
> {code}
> Overwriting the value won't work well when we have more properties to put in 
> clusterprops.  We should be able to change individual values or perhaps merge 
> values.



--
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

Reply via email to