Yes reloading a core can be used. I guess the proposal is a way to update the config and schema files over the network through SOLR rather than by the filesystem. This will make grid computing and schema updates much faster.
On Fri, Sep 19, 2008 at 2:11 AM, Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]> wrote: > why to restart solr ? reloading a core may be sufficient. > SOLR-561 already supports this > - > > > On Thu, Sep 18, 2008 at 5:17 PM, Jason Rutherglen > <[EMAIL PROTECTED]> wrote: >> Servlets is one thing. For SOLR the situation is different. There >> are always small changes people want to make, a new stop word, a small >> tweak to an analyzer. Rebooting the server for these should not be >> necessary. Ideally this is handled via a centralized console and >> deployed over the network (using RMI or XML) so that files do not need >> to be deployed. >> >> On Thu, Sep 18, 2008 at 7:41 AM, Mark Miller <[EMAIL PROTECTED]> wrote: >>> Isnt this done in servlet containers for debugging type work? Maybe an >>> option, but I disagree that this should drive anything in solr. It should >>> really be turned off in production in servelet containers imo as well. >>> >>> This can really be such a pain in the ass on a live site...someone touches >>> web.xml and the app server reboots....*shudder*. Seen it, don't dig it. >>> >>> Jason Rutherglen wrote: >>>> >>>> This should be done. Great idea. >>>> >>>> On Wed, Sep 17, 2008 at 3:41 PM, Lance Norskog <[EMAIL PROTECTED]> wrote: >>>> >>>>> >>>>> My vote is for dynamically scanning a directory of configuration files. >>>>> When >>>>> a new one appears, or an existing file is touched, load it. When a >>>>> configuration disappears, unload it. This model works very well for >>>>> servlet >>>>> containers. >>>>> >>>>> Lance >>>>> >>>>> -----Original Message----- >>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik >>>>> Seeley >>>>> Sent: Wednesday, September 17, 2008 11:21 AM >>>>> To: solr-user@lucene.apache.org >>>>> Subject: Re: Some new SOLR features >>>>> >>>>> On Wed, Sep 17, 2008 at 1:27 PM, Jason Rutherglen >>>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> >>>>>> If the configuration code is going to be rewritten then I would like >>>>>> to see the ability to dynamically update the configuration and schema >>>>>> without needing to reboot the server. >>>>>> >>>>> >>>>> Exactly. Actually, multi-core allows you to instantiate a completely new >>>>> core and swap it for the old one, but it's a bit of a heavyweight >>>>> approach. >>>>> >>>>> The key is finding the right granularity of change. >>>>> My current thought is that a schema object would not be mutable, but that >>>>> one could easily swap in a new schema object for an index at any time. >>>>> That >>>>> would allow a single request to see a stable view of the schema, while >>>>> preventing having to make every aspect of the schema thread-safe. >>>>> >>>>> >>>>>> >>>>>> Also I would like the >>>>>> configuration classes to just contain data and not have so many >>>>>> methods that operate on the filesystem. >>>>>> >>>>> >>>>> That's the plan... completely separate the serialized and in memory >>>>> representations. >>>>> >>>>> >>>>>> >>>>>> This way the configuration >>>>>> object can be serialized, and loaded by the server dynamically. It >>>>>> would be great for the schema to work the same way. >>>>>> >>>>> >>>>> Nothing will stop one from using java serialization for config >>>>> persistence, >>>>> however I am a fan of human readable for config files... >>>>> so much easier to debug and support. Right now, people can cut-n-paste >>>>> relevant parts of their config in email for support, or to a wiki to >>>>> explain >>>>> things, etc. >>>>> >>>>> Of course, if you are talking about being able to have custom filters or >>>>> analyzers (new classes that don't even exist on the server yet), then it >>>>> does start to get interesting. This intersects with deployment in >>>>> general... and I'm not sure what the right answer is. >>>>> What if Lucene or Solr needs an upgrade? It would be nice if that could >>>>> also automatically be handled in a a large cluster... what are the >>>>> options >>>>> for handling that? Is there a role here for OSGi to play? >>>>> It sounds like at least some of that is outside of the Solr domain. >>>>> >>>>> An alternative to serializing everything would be to ship a new schema >>>>> along >>>>> with a new jar file containing the custom components. >>>>> >>>>> -Yonik >>>>> >>>>> >>>>> >>> >>> >> > > > > -- > --Noble Paul >
