2015-11-10 3 views
1

Мне нужна помощь в правильной диагностике com.hazelcast.core.OperationTimeoutException.Hazelcast OperationTimeoutException

com.hazelcast.core.OperationTimeoutException: Нет ответа на 120000 мс. Прерывание вызова! Invocation {serviceName = 'hz: impl: mapService', op = GetOperation {TRADES}, partitionId = 87, replicaIndex = 0, tryCount = 250, tryPauseMillis = 500, invoke Count = 1, callTimeout = 60000, target = Адрес [ 10.32.21.170]: 17326, backupsExpected = 0, backupsCompleted = 0}

Не получен ответ был получен! Ожидаемые резервные копии: 0 резервных копий завершено: 0

Кажется, что конфигурация 120 000 мс, но я не думаю, что увеличение этого ответа. Когда это происходит, все вызовы завершаются с ошибкой по той же причине, независимо от операции получения или установки и т. Д.

Может ли кто-нибудь дать рекомендацию о том, какие параметры следует скорректировать для смягчения проблемы? Возможно, на самом деле это проблема с конфликтом потоков, и увеличение потоков событий или подобных может помочь. В настоящее время экземпляр hazelcast не имеет пользовательских параметров. Количество потоков по умолчанию - все по умолчанию. В то же время сервер не находится в избыточной сборке мусора.

+0

P.S. Я не могу легко воспроизвести эту проблему, иначе я бы включил дамп потока. Извини за это. – Pschmeltz

ответ

1

Наиболее вероятной причиной этого исключения является сетевая проблема среди членов кластера. Неповторимый узел (из-за проблем с памятью или GC и т. Д.) Также может вызвать такую ​​проблему. Первое, что может быть, это обеспечить качество/производительность вашей сети. Если вы используете AWS, вы можете предпочесть экземпляр с лучшей производительностью сети.

Если вы хотите быстро избавиться от проблемных узлов; вы можете установить более низкое значение для следующего системного свойства: «hazelcast.max.no.heartbeat.seconds»: Максимальный тайм-аут для биения в секундах, чтобы узел предположил, что он мертв. Значение по умолчанию - 500 секунд.

+0

В моем случае узлы не мертвы, и я сомневаюсь в отключении сети, поскольку они находятся на одном физическом оборудовании в локальной среде VM. Я буду изучать это, чтобы быть уверенным. В случае, если я предпочитаю, чтобы эти вызовы просто повторялись, можно ли увеличить попытки, которые пытается сделать каламбур, увеличивая время и некоторый параметр счетчика попыток? Например: tryCount = 250 означает ли это, что он делал попытку в 250 раз, или если бы 120000 мс не пострадали первым? Или вызовите Count = 1, означает ли это, что на самом деле произошло только 1 попытка. Спасибо еще раз за помощь. – Pschmeltz

+0

Да, существует ограничение на количество повторных попыток с жестким кодом 250. Afaik, API не изменит это. Но если разрешено устанавливать это на бесконечность; то любой проблемный узел заставит кластер бесконечно висеть. – javanes

+0

Спасибо. Я увижу, что можно сделать для повышения производительности кластера. – Pschmeltz

Смежные вопросы