Solr 7 не удаляет узел полностью из-за слишком маленького пула потоков - PullRequest
0 голосов
/ 29 марта 2019

Ситуация

В настоящее время я пытаюсь настроить 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

В журналах возникает это исключение:

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 Не похоже, чтобы его можно было настраивать прямо сейчас, но если у кого-нибудь есть готовое решение, я был бы рад узнать его.

...