lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Solr reload trigger when a configuration file is changed
Date Wed, 22 Jan 2014 15:59:57 GMT
Yonik has brought up this feature a few times as well. I’ve always felt about the same as
Shawn. I’m fine with it being optional, default to off. A cluster reload can be a fairly
heavy operation.

- Mark  



On Jan 22, 2014, 4:36:19 AM, Mohit Jain <mohit@bloomreach.com> wrote: 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 <solr@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message