On 1/17/2014 7:25 AM, Mohit Jain wrote:
Bingo !! Tomcat was the one which was keeping track of changes in his own
config/bin dirs. Once the timestamp of those dirs are changed it issued
reload on all wars, resulting reload of solr cores.
By the way it will be good to have a similar configurable feature in Solr.
When not running in SolrCloud mode, Solr currently doesn't do anything
unless a very definite action triggers it. Typically, this means the
Solr admin, a user, or an application must send a request to Solr.
Debugging problems is easier when you know for sure that the software
cannot decide to do something on its own. This design principle is also
part of why Solr doesn't have a scheduler built into the dataimport handler.
When running in SolrCloud mode, Solr will react to random events like
another Solr server going down, certain changes in zookeeper, or a
problem with zookeeper, but it will not initiate any action on its own.
This is a requirement for a robust cluster.The principle is the same,
but there are additional request sources.
The current behavior with config files (whether on-disk or in zookeeper)
allows you to update the config on a running Solr server and delay the
activation of that config until later, at your own discretion.
I think it's a very bad idea to change this behavior so that it
automatically reloads when a config file is updated. A less evil idea
would be to make auto-reloads *optional*, as long as that feature is not
turned on by default and is not turned on in the example config. If
such a feature is created, the solr log needs to clearly state at
startup that it's enabled (possibly at WARN level), and each time a core
is auto-reloaded due to a config change.
Thanks,
Shawn
