[
https://issues.apache.org/jira/browse/SOLR-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory Chanan updated SOLR-6180:
---------------------------------
Attachment: SOLR-6180.patch
Here's a patch that exposes getSchemaUpdateLock at the IndexSchema level, and
moves synchronizing on the lock from ManagedIndexSchema itself to the callers
(this is consistent with how ZkIndexSchemaReader works).
> Callers of ManagedIndexSchema mutators should hold the schemaUpdateLock
> -----------------------------------------------------------------------
>
> Key: SOLR-6180
> URL: https://issues.apache.org/jira/browse/SOLR-6180
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
> Reporter: Gregory Chanan
> Priority: Minor
> Attachments: SOLR-6180.patch, SchemaLockTest.java
>
>
> Consider the code in FieldResource.java:
> {code}
> SchemaField newField = oldSchema.newField(fieldName, fieldType, map);
> IndexSchema newSchema = oldSchema.addField(newField, copyFieldNames);
> if (null != newSchema) {
> getSolrCore().setLatestSchema(newSchema);
> success = true;
> } else {
> throw new SolrException(ErrorCode.SERVER_ERROR, "Failed to add field.");
> }
> {code}
> The schema update lock is only held during the call to addField, so there is
> no guarantee that the schema we are setting later is actually the latest
> schema. This would rarely happen, but it's possible that between the time we
> gave up the lock and the time we set the schema that we got a new schema from
> ZK. We'd end up overwriting the new schema, possibly missing newly added
> fields.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
