[
https://issues.apache.org/jira/browse/SOLR-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039585#comment-14039585
]
Mark Miller commented on SOLR-6180:
-----------------------------------
+1, nice catch! Doesn't seem like a bad idea to add the test to me. Even
without that 10ms sleep (which we could perhaps randomly do?), I wouldn't be
surprised if this doesn't fail sometimes on the jenkins cluster, which is
hammering these tests over and over as fast as it can in a variety of slow envs.
> 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]
