Thanks for your support, but I don't think setInfoStream makes any sense either : )
Do we /change/ infoStreams for IW @runtime? Why can't we pass it as constructor argument/IWC field? Ok, just maybe, I can imagine a case, where a certain app runs happily, then misbehaves, and then you, with some clever trickery supply it a fresh infoStream, to capture the problem live, without restarting. So, just maybe, we should leave setInfoStream asis. 2011/3/11 Shai Erera <ser...@gmail.com>: > I agree. After IWC, the only setter left in IW is setInfoStream which makes > sense. But the rest ... assuming these config change don't happen very > often, recreating IW doesn't sound like a big thing to me. The alternative > of complicating IWC to support runtime changes -- we need to be absolutely > sure it's worth it. > > Also, if the solution is to allow changing IWC (runtime) settings, then I > don't think this issue should block 3.1? We can anyway add other runtime > settings following 3.1, and we won't undeprecate anything. So maybe mark > that issue as a non-blocker? > > Shai > > On Fri, Mar 11, 2011 at 2:20 PM, Earwin Burrfoot <ear...@gmail.com> wrote: >> >> Is it really that hard to recreate IndexWriter if you have to change >> the settings?? >> >> Yeah, yeah, you lose all your precious reused buffers, and maybe >> there's a small indexing latency spike, when switching from old IW to >> new one, but people aren't changing their IW configs several times a >> second? >> >> I suggest banning as much runtime-mutable settings as humanely >> possible, and ask people to recreate objects for reconfiguration, be >> it IW, IR, Analyzers, whatnot. >> >> On Thu, Mar 10, 2011 at 23:07, Michael McCandless >> <luc...@mikemccandless.com> wrote: >> > On Thu, Mar 10, 2011 at 7:28 AM, Robert Muir <rcm...@gmail.com> wrote: >> > >> >> This should block the release: if IndexWriterConfig is a broken design >> >> then we need to revert this now before its released, not make users >> >> switch over and then undeprecate/revert in a future release. >> > >> > +1 >> > >> > I think we have to sort this out, one way or another, before releasing >> > 3.1. >> > >> > I really don't like splitting setters across IWC vs IW. That'll just >> > cause confusion, and noise over time as we change our minds about >> > where things belong. >> > >> > Looking through IWC, it seems that most setters can be done "live". >> > In fact, setRAMBufferSizeMB is *almost* live: all places in IW that >> > use this pull it from the config, except for DocumentsWriter. We >> > could just push the config down to DW and have it pull live too... >> > >> > Other settings are not pulled live but for no good reason, eg >> > termsIndexInterval is copied to a private field in IW but could just >> > as easily be pulled when it's time to write a new segment... >> > >> > Maybe we should simply document which settings are live vs only take >> > effect at init time? >> > >> > Mike >> > >> > -- >> > Mike >> > >> > http://blog.mikemccandless.com >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> > >> >> >> >> -- >> Kirill Zakharenko/Кирилл Захаренко >> E-Mail/Jabber: ear...@gmail.com >> Phone: +7 (495) 683-567-4 >> ICQ: 104465785 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
