Thanks Shawn. I appreciate you sharing the philosophy behind Solr's implementation. I absolutely agree with the design principle and the fact that it helps to debug unknown issues. Moreover it definitely gives more control over the software.
However there are *small* number of applications that might get benefitted from *optional* feature with additional risk of auto-reloads issues. One can think of a scenario where a job generates universal stopwords/porn words at regular intervals, but do not have any idea about the Solr host/collections. Instead of creating one more component to coordinate with generator and reload all the affecting collections, it might be a good idea to let collections take care of it. Thanks Mohit On Fri, Jan 17, 2014 at 10:29 PM, Shawn Heisey <s...@elyograg.org> wrote: > 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 > >
