mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-07 21:48:39 +00:00
The native process can only handle one operation at a time, so in order the protect against multiple operation at a time (e.g. post data and flush or multiple post data operations) there should be protection in place to guarantee that at most only a single thread interacts with the native process. The current protection is broken when a job close is executed, more specifically the wait logic is broken here. This commit changes the threading logic when interacting with the native process by using a custom `ExecutorService` that that uses a single worker thread from `ml_autodetect_process` thread pool to interact with the native process. Requests from the ml apis are initially being queued and this worker thread executes these requests one by one in the order they were specified. Removed the general `ml` threadpool and replaced its usages with `ml_autodetect_process` or `management` threadpool. Added a new threadpool just for (re)normalizer, so that these operations are isolated from other operations. relates elastic/x-pack-elasticsearch#582 Original commit: elastic/x-pack-elasticsearch@ff0c8dce0b