Hi David, Great meeting you at Buzzwords last month!
(Sorry for the late reply -- I was on vacation for weeks.) You can modify maxFullFlushMergeWaitMillis at the IndexWriterConfig level, but that sets it for any caller who tries to open an IndexReader from the IndexWriter. It sounds like you would like an IndexWriter that "normally" merges on getReader calls (with the default 500ms wait), but can also return a reader without merging if explicitly requested (in the getReader call). Adding an overload to IndexWriter.getReader would be pretty easy, but that method is package-private. The hairier part probably involves deciding which open/openIfChanged methods to overload in DirectoryReader, since I think that's where the parameter would ultimately need to be exposed to users. Is that a fair assessment of what you're looking for? Thanks, Froh On Fri, Jul 5, 2024 at 8:00 PM David Smiley <dsmi...@apache.org> wrote: > In the context of looking at NRT search in Solr (the so-called > realtime searcher), I was looking at IndexWriter.getReader to see what > it does, as it seems to be the primary method for opening a new view > quickly. If Lucene has a better entry point for opening a view ASAP, > let me know. I see that getReader writes a segment. A very long time > ago in ~2013, I recall Michael Busch, then at Twitter, was > contributing some amazing features to Lucene to search the index > writing buffers in-place. Do people remember what became of that? > Maybe I'm wrong -- no contribution. I don't see anything in > CHANGES.txt from Michael that's pertinent. I didn't yet look in JIRA. > The presentation I saw (in person) by Michael was at Lucene/Solr > Revolution in Boston, 2013 -- recording: > https://www.youtube.com/watch?v=F2CHE4VyB3c > > getReader may also merge segments (configured to do so by default > since 9.3), thus making this not very NRT friendly for a subset of > use-cases that a search app may have. In my experience these relate > to indexing to do conditional updates based on index state or to > return index statistics per batch. Wouldn't it be useful for > maxFullFlushMergeWaitMillis to be over-rideable as a parameter in case > the caller wishes to get a view without waiting at all for merges but > leaving open other use-cases to use the default/configured time? > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
