gus-asf opened a new pull request, #2595: URL: https://github.com/apache/solr/pull/2595
https://issues.apache.org/jira/browse/SOLR-17298 This introduces a version of ThreadCpuTimer class that does not need to depend on the request context or be instantiated to track timing. This approach turns ThreadCpuTimer into a "stopwatch" service that simply answers the question of how long has it been since the last time this thread asked for time... I added an override of beforeExecute() to MDCAwareThreadPoolExecutor and some related methods to ExecutorUtil to allow the "stopwatch" to be reset just before lucene asks the executor to execute a task. Every shouldExit() causes a read operation which returns the time since last read by that thread and resets the timer. An atomic long is used to accumulate the total and test the timeout. Additionally the ThreadCpuTimer also can track multiple timings within the same thread by use of a "context" denoted by a string parameter, this allows it to continue to serve as a timer for cpu usage logging as well. The Tests for this also required some tweaks to ensure that there were multiple segments in the index being searched, and enough segments were generated to ensure more than one task is assigned to the executor by Lucene (It groups segments up to a max total size or a maximum of 5 segments, whichever comes first, see [IndexSearcher#MAX_SEGMENTS_PER_SLICE](https://github.com/apache/lucene/blob/8d4f7a6e99d2da802b7019247b0f8f305d71c024/lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java#L105), and also I added a TestInjection with code mimicking the ExpensiveSearchComponent code to allow us to waste some CPU before each call to shouldExit() for better simulation of actual load. Tests pass including TestCpuAllowedLimit with both multiThreaded=true and multiThreaded=false cases enabled. We should however observe how it behaves in Jenkins/Crave test runs. Also it would be super good to get more eyes on this. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
