[
https://issues.apache.org/jira/browse/SOLR-8412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137574#comment-15137574
]
Noble Paul commented on SOLR-8412:
----------------------------------
bq.Changing complex synchronization causes warning bells to go off.
It's a bit complex because of the history of the APIs. It works differently for
standalone and cloud. For cloud, it expects the listeners to do the trick. In
standalone mode , there is no 'listener' . So, the in memory schema object is
updated after persisting the new schema. In Cloud mode no synchronization is
necessary. It is designed to work in a multithreaded mode or even on multiple
nodes. OTOH , in the standalone mode the synchronization should be on the lock
of the managedIndexSchema because that operation happens from multiple places .
So, the current synchronization is fine. No need to change
> SchemaManager should synchronize on performOperations method
> ------------------------------------------------------------
>
> Key: SOLR-8412
> URL: https://issues.apache.org/jira/browse/SOLR-8412
> Project: Solr
> Issue Type: Bug
> Reporter: Varun Thacker
> Priority: Minor
> Attachments: SOLR-8412.patch, SOLR-8412.patch, SOLR-8412.patch
>
>
> Currently SchemaManager synchronizes on {{schema.getSchemaUpdateLock()}} . We
> should synzhronize on {{performOperations}} instead.
> The net affect will be the same but the code will be more clear.
> {{schema.getSchemaUpdateLock()}} is used when you want to edit a schema and
> add one field at a time. But the way SchemaManager works is that it does bulk
> operations i.e performs all operations and then persists the final schema .
> If there were two concurrent operations that took place, the later operation
> will retry by fetching the latest schema .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
