jpountz commented on issue #12347: URL: https://github.com/apache/lucene/issues/12347#issuecomment-1584130071
I wonder if we should make SliceExecutor configurable, or if we should instead fix it? Having both the Executor and the SliceExecutor be user-configurable feels too much to me, we should either make the executor configurable, or if we think that this abstraction is not sophisticated enough then have a more complex abstraction configurable whole concrete implementations would likely wrap an executor? SliceExecutor is based on the assumption that it is sometimes a good idea to run in the current thread instead of delegating to the executor. I have become increasingly doubtful about this because it make it very hard to reason about the total number of threads that may run searches, since the threadpool that would call `IndexSearcher#search` would have part of its threads running searches, and part of its threads joining tasks that are running in the executor threadpool. Should we simplify this and always run searches in the executor threadpool? And the other threadpool (the one that calls `IndexSearcher#search`) would only be joining tasks running in the executor and running cheap operations like `TopDocs#merge` to combine the results of the various slices? -- 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
