lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-7176) allow zkcli to modify JSON
Date Mon, 20 Apr 2015 14:19:59 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message