Ситуация
В настоящее время я пытаюсь настроить SolrCloud в группе автоматического масштабирования AWS, чтобы он мог динамически масштабироваться.
Я также добавил в Solr следующие триггеры, поэтомучто каждый узел будет иметь 1 (и только одну) репликацию каждой коллекции:
{
"set-cluster-policy": [
{"replica": "<2", "shard": "#EACH", "node": "#EACH"}
],
"set-trigger": [{
"name": "node_added_trigger",
"event": "nodeAdded",
"waitFor": "5s",
"preferredOperation": "ADDREPLICA"
},{
"name": "node_lost_trigger",
"event": "nodeLost",
"waitFor": "120s",
"preferredOperation": "DELETENODE"
}]
}
Это работает довольно хорошо.Но моя проблема в том, что когда узел удаляется, он не удаляет все 19 реплик с этого узла, и у меня возникают проблемы при доступе к странице «узлы»:
![enter image description here](https://i.stack.imgur.com/QyJrY.png)
В журналах возникает это исключение:
Operation deletenode failed:java.util.concurrent.RejectedExecutionException: Task org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$45/1104948431@467049e2 rejected from org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor@773563df[Running, pool size = 10, active threads = 10, queued tasks = 0, completed tasks = 1]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.execute(ExecutorUtil.java:194)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
at org.apache.solr.cloud.api.collections.DeleteReplicaCmd.deleteCore(DeleteReplicaCmd.java:276)
at org.apache.solr.cloud.api.collections.DeleteReplicaCmd.deleteReplica(DeleteReplicaCmd.java:95)
at org.apache.solr.cloud.api.collections.DeleteNodeCmd.cleanupReplicas(DeleteNodeCmd.java:109)
at org.apache.solr.cloud.api.collections.DeleteNodeCmd.call(DeleteNodeCmd.java:62)
at org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:292)
at org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:496)
at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Описание проблемы
Итак, проблема в том, что размер пула составляет только 10, из которых 10занят и ничего не ставится в очередь (синхронное выполнение).Фактически, он действительно удалил только 10 реплик, а остальные 9 остались там.При ручной отправке команды API для удаления этого узла все работает нормально, поскольку Solr нужно только удалить оставшиеся 9 реплик, и все снова хорошо.
Вопрос
Как можно увеличить это значение (маленький) размер пула потоков и / или активация постановки в очередь оставшихся задач удаления?Другое решение может заключаться в том, чтобы повторить неудачную задачу, пока она не будет выполнена.
Использование Solr 7.7.1 на Ubuntu Server, установленном с помощью скрипта установки от Solr (так что я предполагаю, что он использует Jetty?).
Спасибо за вашу помощь!
РЕДАКТИРОВАТЬ: Я получил отзыв из списка рассылки группы пользователей Solr.Кажется, это недостаток проекта: https://issues.apache.org/jira/browse/SOLR-11208 Не похоже, чтобы его можно было настраивать прямо сейчас, но если у кого-нибудь есть готовое решение, я был бы рад узнать его.