[jira] [Commented] (SOLR-11000) Changes made via AutoScalingHandler should be atomic
[ https://issues.apache.org/jira/browse/SOLR-11000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243467#comment-16243467 ] ASF subversion and git services commented on SOLR-11000: Commit ddf8b57ad656ee3362ba5392fe4310af06dd60d3 in lucene-solr's branch refs/heads/branch_7x from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ddf8b57 ] SOLR-11000: Adding entry to CHANGES.txt in 7.1 section > Changes made via AutoScalingHandler should be atomic > > > Key: SOLR-11000 > URL: https://issues.apache.org/jira/browse/SOLR-11000 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki > Labels: autoscaling > Fix For: 7.0 > > Attachments: SOLR-11000.patch, SOLR-11000.patch, SOLR-11000.patch > > > Currently, AutoScalingHandler writes the result of each command to ZK > individually. So if you send 3 commands in a payload, it will write them > individually. We really should make it atomic so that the result of all the > commands are persisted together or none at all. -- 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
[jira] [Commented] (SOLR-11000) Changes made via AutoScalingHandler should be atomic
[ https://issues.apache.org/jira/browse/SOLR-11000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086654#comment-16086654 ] Shalin Shekhar Mangar commented on SOLR-11000: -- I don't think it is a good idea for the AutoScalingHandler to output intermediate ZK version numbers which are retried. It is just too much internal detail and may be confusing to the user. However, what can be useful is to write out the final ZK version once the write succeeds. Then, perhaps in the future, we can add optimistic concurrency to this API. > Changes made via AutoScalingHandler should be atomic > > > Key: SOLR-11000 > URL: https://issues.apache.org/jira/browse/SOLR-11000 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki > Labels: autoscaling > Fix For: 7.0 > > Attachments: SOLR-11000.patch, SOLR-11000.patch, SOLR-11000.patch > > > Currently, AutoScalingHandler writes the result of each command to ZK > individually. So if you send 3 commands in a payload, it will write them > individually. We really should make it atomic so that the result of all the > commands are persisted together or none at all. -- 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
[jira] [Commented] (SOLR-11000) Changes made via AutoScalingHandler should be atomic
[ https://issues.apache.org/jira/browse/SOLR-11000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16085206#comment-16085206 ] Shalin Shekhar Mangar commented on SOLR-11000: -- Thanks Andrzej. I'm glad you got rid of the json maps. Just a few comments on the latest code on the branch: # minor nit -- AutoScalingHandler.handleRemoveTrigger -- loop for removing all active listeners can be replaced by listeners.keySet().removeAll(activeListeners) # minor nit - Unused listeners variable in handleSetListener # The way zkSetAutoScalingConfig is implemented is no longer correct. The loop used to read the latest from ZK, update it with the result of the operation being performed and then try to write the result using compare-and-set. If there is a BadVersionException, all the steps were tried again. Now it will just loop forever on a BadVersionException because the read from ZK part is never tried again. It'd be nice to add a test to exercise this path. I think it wasn't correct earlier too but it was bad in a different way (infinite loop vs incorrect data) # Is the deep copy of jsonMap in the constructor of AutoScalingConfig still necessary? same for the parseInt call for version > Changes made via AutoScalingHandler should be atomic > > > Key: SOLR-11000 > URL: https://issues.apache.org/jira/browse/SOLR-11000 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki > Labels: autoscaling > Fix For: 7.0 > > Attachments: SOLR-11000.patch, SOLR-11000.patch > > > Currently, AutoScalingHandler writes the result of each command to ZK > individually. So if you send 3 commands in a payload, it will write them > individually. We really should make it atomic so that the result of all the > commands are persisted together or none at all. -- 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
