[
https://issues.apache.org/jira/browse/SOLR-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503430#comment-14503430
]
Per Steffensen edited comment on SOLR-7176 at 4/20/15 7:02 PM:
---------------------------------------------------------------
Believe it is referred to as compare-and-swap, but anyway
{{Overseer.handleProp}} does not use that feature (it always uses version=-1
when calling zk.setData). But actually I just realized that it is not true that
{{CollectionsHandler.handleProp}} does the fetch-update and only leaves update
to Overseer (as I claimed above) - it actually does forward the entire
operation to Overseer so that the Overseer does fetch, update and store (just
at I wanted it to). So you are right, that the problem I sketched above is not
a problem in todays code, but it is not due to usage of compare-and-swap - it
is because two threads will never try to do updates at the same time - they
will ask the Overseer to do the updates (single-threaded = primitive
pessimistic lock).
So we cannot "just eliminate the overseer from the picture completely", if we
still want to avoid the (more or less "theoretical") problem I sketched above.
So the bullet-safe command-line solution should take this into consideration -
e.g.
* 1) Take the overseer-lock before performing the operation
* 2) Use compare-and-swap (and make sure Overseer also does)
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.
was (Author: steff1193):
Believe it is referred to as compare-and-swap, but anyway
{{Overseer.handleProp}} does not use that feature (it always uses version=-1
when calling zk.setData). But actually I just realized that it is not true that
{{CollectionsHandler.handleProp}} does the fetch-update and only leaves update
to Overseer (as I claimed above) - it actually does forward the entire
operation to Overseer so that the Overseer does fetch, update and store (just
at I wanted it to). So you are right, that the problem I sketched above is not
a problem in todays code, but it is not due to usage of compare-and-swap - it
is because two threads will never try to do updates at the same time - they
will ask the Overseer to do the updates (single-threaded = primitive
pessimistic lock).
So we cannot "just eliminate the overseer from the picture completely", if we
still want to avoid the (more or less "theoretical") problem I sketched above.
So the bullet-safe command-line solution should take this into consideration -
e.g.
* 1) Take the overseer-lock before performing the operation
* 2) Use compare-and-swap (and make sure Overseer also does)
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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
