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
