jpountz commented on issue #13883:
URL: https://github.com/apache/lucene/issues/13883#issuecomment-3031906059
Yes, this is the same idea indeed! I had thumbs-up'ed it. :) But then the
discussion went back to iterating on CMS, which feels both more complicated
(N-N feedback loops between the various CMS instances) and less promising
(still cannot use the same thread pool for indexing and merging) to me.
FWIW I think we'll need to evaluate whether we actually need throttling to
be writer-aware, I anticipate writer-agnostic throttling to go a long way. Only
doing simple things such as:
- Using the same thread pool for indexing and merging. This way if the
thread pool gets full of merges, this will naturally push back on indexing.
- If the thread pool cannot accept a new merge, run the smallest queued
merge in the current (indexing) thread like `SerialMergeScheduler` (since merge
schedulers should not ignore merges).
--
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
