[
https://issues.apache.org/jira/browse/SOLR-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502904#comment-14502904
]
Per Steffensen commented on SOLR-7176:
--------------------------------------
bq. Why can't we just eliminate the overseer from the picture completely?
Not that it is very important in this case, but there is a problem in general
with having several threads doing fetch -> update-locally -> store on state
concurrently without locking (pessimistically or optimistically). Example, two
threads running concurrently
* Thread#1 wants to do the task of setting "urlScheme" to "http":
** fetches {"urlScheme":"https", "autoAddReplicas": "true"}
** changes it to {"urlScheme":"http", "autoAddReplicas": "true"} and stores it
* Thread#2 wants to do the task of setting "autoAddReplicas" to "false":
** fetches {"urlScheme":"https", "autoAddReplicas": "true"}
** changes it to {"urlScheme":"https", "autoAddReplicas": "false"} and stores it
Without locking they can run concurrently and you will end up with a wrong state
* {"urlScheme":"http", "autoAddReplicas": "true"}
* or {"urlScheme":"https", "autoAddReplicas": "false"}
But you actually expected {"urlScheme":"http", "autoAddReplicas": "false"}
I do not know what the initial thought was about the Overseer, but I think of
it as a simple way to get around this locking - making sure that there is never
more than one thread updating state.
When that is said, if the above was the intention with the Overseer, it does
not work today, because CollectionsHandler.handleProp is doing the fetch and
update, and only leaves the storing to Overseer. I would like to see the entire
job handed over to the Overseer, so that it does both fetch, update and store -
so that you can avoid the concurrency scenario above. In general Overseer
should execute entire admin-jobs and not only parts of them.
Anyway, it is a reason not to do this kind of updates without taking locks, and
Overseer is a primitive way of "taking lock", and maybe therefore "do not
eliminate the Overseer". I am not sure it is especially important here.
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
