dsmiley commented on issue #13325: URL: https://github.com/apache/lucene/issues/13325#issuecomment-2231607373
Solr already takes care to ensure a SolrCore is closed while nobody is accessing it via its refcount mechanism on the SolrCore. I understand the JVM doesn't know that, and needs to take precautions. That it's O(threads) means the Solr project should prioritize taming its 10k-bounded Jetty thread pool for this new reason. > basically reopening IndexReaders (closing old segments, open new segments). Basically a Solr softcommit, but also applies to commits Woah; per commit! I thought you just meant the equivalent of opening and closing a SolrCore, which has an index -- somewhat rare. Are you saying that, ideally, Solr should close the _previous_ IndexReader (tied to a Searcher that will close) asynchronously? And you suggested by one thread... does it need to be one thread for the whole JVM (this worries me) or one per core? > the JDK maintainers recommend to possibly do the closing of indexes asynchronously in production environments It's okay if closing a SolrCore is a bit slower. In practice, this means a core UNLOAD request would take longer thus deleting a collection takes longer (albeit is already parallelized per replica). Shutting down Solr would take longer; okay. -- 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
