rmuir commented on issue #13194: URL: https://github.com/apache/lucene/issues/13194#issuecomment-2010295899
I think the Direct-IO solution is hacky and trappy myself. This is a really slow way to do perform IO, with the hope? that it will somehow make some separate NRT search process faster? 1. not every app uses lucene NRT with indexing in this way and not every app wants lucene to take over entire machine. Example would be IDE that just uses lucene for searching: the user is doing plenty of other shit on their machine (e.g. compiling code and stuff). 2. i dont understand the reflection on JDK classes and why we need that 3. direct IO comes with a lot of complexity and downsides: really it isn't geared at what the code is doing here, it is instead geared at "special situations, such as when applications do their own caching". That is straight from the `open(2)` documentation. 4. direct IO hack brings degraded performance, IMO its not the correct solution to the problem but just a hack. why move this into lucene core? a better solution would be something like https://lwn.net/Articles/806980/ 5. better solution with current lucene support, if you dont want merging to disrupt page cache for searches is to use NRT segment replication which allows searchers to be totally separate from indexing/merging. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
