[
https://issues.apache.org/jira/browse/SOLR-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078891#comment-16078891
]
Hoss Man commented on SOLR-11034:
---------------------------------
The net result of these two watchers is that depending on the order of
execution in the distinct threads that process them, there are (at least) 3
possible outcomes I can think of...
# ZkIndexSchemaReader watcher fires, starts & finishes creating new IndexSchema
and sets it before the SolrCore watche fires. Then the SolrCore watcher fires
and does nothing because it's znode version check shows the current IndexSchema
is not stale.
# The SolrCore watcher fires, starts & finishes reloading the core. Then the
ZkIndexSchemaReader watcher fires and does nothing because the SolrCore is in
the process of shutting down
#* I've never actaully observed this happening in any logs, but AFAICT it's
theoretically possible
# Both the ZkIndexSchemaReader & SolrCore watchers fire at roughly the same
time, While ZkIndexSchemaReader is in the process of creating a new
IndexSchema, the SolrCore watcher checks the zknode version of the current
IndexSchema object and decides it's stale.
It's not clear to me if/why both code paths are needed -- it seems like either:
* ZkIndexSchemaReader creating a new ManagedIndexSchema object and setting it
on the "live" core's ManagedIndexSchemaFactory is sufficient
** in which case doing a core reload is completley unneccessary
...OR...
* changing the ManagedIndexSchema "on the fly" is *not* sufficient and doing a
core reload is always neccessary
** in which case why do we bother having he ZkIndexSchemaReader watcher at all?
** is the existence of this watcher, and the fact that situation #1 (above)
frequently happens causing bugs/corruption in the cores using the new schema
w/o a full reload?
----
Even if both code paths are useful/needed for some indepdent reasons i don't
understand, situation #3 above seems redundent and wasteful of CPU --
particularly since it seems more likely to happen when a system is under heavy
load, and neither watcher can "finish" before the other starts. Shouldn't the
code in SolrCore.getConfListener's watcher to check if
ManagedIndexSchema.getSchemaZkVersion() is stale be synchronized on the same
getSchemaUpdateLock() that ZkIndexSchemaReader uses in order to prevent this?
> Redundent/Unneccessary SolrCore reload when ManagedIndexSchema changes are
> made in cloud mode
> ---------------------------------------------------------------------------------------------
>
> Key: SOLR-11034
> URL: https://issues.apache.org/jira/browse/SOLR-11034
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
>
> When using ManagedIndexSchema in cloud mode, there are 2 distinct code paths
> that create "watchers" looking for changes to the managed-schema resouce file
> in ZK...
> * ZkIndexSchemaReader.createSchemaWatcher
> ** sets a watcher on the managed-schema file
> ** if this watcher fires, it creates a new ManagedIndexSchema and sets it on
> the ManagedIndexSchemaFactory for future requests
> * SolrCore.getConfListener + ZkController.registerConfListenerForCore
> ** sets a watcher on the configset dir
> ** if this watcher fires, it then checks the znode version for the
> solrconfig.xml, configoverlay.json, and managed-schema -- if any are "stale"
> it triggers a core reload
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
