uschindler commented on issue #15054: URL: https://github.com/apache/lucene/issues/15054#issuecomment-3196151981
> > If you are not using the directory for anything else than copying the index to another Lucene, I'd still recommend to disable grouping using mmapDir.setGroupingFunction(MMapDirectory.NO_GROUPING) only for this directory used as input for the replication. > > We use the same local directory (which is also mmapped ) itself to read the indexes and upload to remote store, hence using the `mmapDir.setGroupingFunction(MMapDirectory.NO_GROUPING)` would effectively work for both reading the segments for search and remote upload purpose. For my understanding the effect of `NO_GROUPING` and `maxPermits=1` would have same impact, right ? Would you still recommend it ? If you use the same directory instance for both, I would not recommend neither. I was under the impression that the RemoteDirectory class in OpenSerach is solely used for replication and the indexes are opened separately. If both is going through the same directory instance (a MMapDir behind scenes), then don't change neither the sysprop nor the mmap dir setter. Doing thios slows down under highly concurrent setups and high refresh ratios. This again tells me that the best might really be to use a separate IO layer for replication. Or use something like FileSwitchDirectory to delegate calls from the replication code through NIOFSDirectory insead of MMap. NIOFSDir can reuse the caching done my MMapDir, so you can easily access the same file through both directory implementations in parallel. Just use hybrid FS dir and just short-circuit it to let all replication code be delegated to NIOFSDir, while normal indexing/searching load use the switching based on filename. > > Do you think we can close this issue on the Lucene side as "Not an issue"? > > Yes . Let me close this . Thanks! -- 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
