Это сценарий

  1. Я запустил серверный узел.
  2. Я запустил узел Client Ignite, который будет выполняться через приложение Java с надписью «X».
  3. В козырьке я мог видеть два узла, один из которых является клиентским, а другой - серверным, когда дана команда «узел».
  4. Я убил Java-приложение «X», выполнив «kill -9 pid».
  5. Теперь, когда я подхожу к терминалу Visor и ввожу «узел», в списке все еще отображаются узлы «клиент» и «сервер». когда его спрашивают о деталях клиентского узла, он явно выдает ошибку.
  6. Теперь, когда я перезапускаю Java-приложение «X», в этом Java-коде снова будет попытка подключиться к серверу Ignite. Но вместо подключения он столько раз печатает эти журналы

"org.apache.ignite.logger.java.JavaLogger" "info" "INFO" "" "284" "Accepted incoming communication connection [locAddr=/0:0:0:0:0:0:0:1:47101, rmtAddr=/0:0:0:0:0:0:0:1:62856]" "" "" "" "" "" "" "1587013526124" "" "" "" "" "" "" "ROOT" "{""service"":"""",""logger_name"":""org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi""}"

  1. Он не подключается и не продолжает выполнение кода на Java. Таким образом, приложение не возобновляется. И я обнаружил, что это журнал сервера Ignite.

[10:37:57] Возможный сбой, подавленный в соответствии с настроенным обработчиком [hnd = StopNodeOrHaltFailureHandler [tryStop = false, timeout = 0, super = AbstractFailureHandler [ignoredFailureTypes = UnmodifiableSet [SYSTEM_WORKER_BLOCKED, SYSTEM_WORKER_BLOCKED, SYSTEM_CRITIME_OPERATION] type] , err = class oaiIgniteException: Истекло время ожидания получения блокировки чтения контрольной точки.]] [10: 37: 57,739] [SEVERE] [exchange-worker- # 46] [GridCacheDatabaseSharedManager] Истекло время ожидания получения блокировки чтения контрольной точки. class org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager $ CheckpointReadLockTimeoutException: время ожидания блокировки чтения контрольной точки истекло. в org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.failCheckpointReadLock (GridCacheDatabaseSharedManager.java:1708) в org.apache.ignite.internal.processors.cache.persistence.cheredCacheDataDatabase.Cache.persistence.haredCacheanDataDataData.cache.persistence.cheredCacheDataDataDataDataBase по адресу org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initTopologies (GridDhtPartitionsExchangeFuture.java:1078) по адресу org.apache.ignite.internal.processors.cache.distributedPartitions.dht. init (GridDhtPartitionsExchangeFuture.java:944) по адресу org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager $ ExchangeWorker.body0 (GridCachePartitionExchangeManager.java:3258) в org.apache.ignagerCacheCache.Exchange.internal. body (GridCachePartitionExchangeManager.java:3104) в org.apache.ignite.internal.util.worker.GridWorker.run (GridW orker.java:119) на java.lang.Thread.run (Thread.java:748) [10: 39: 21,547] [СЕРЬЕЗНЫЙ] [tcp-disco-msg-worker- [693d29cd 0: 0: 0: 0: 0: 0: 0: 1% lo0: 47501 crd] - # 2] [G] Обнаружен заблокированный критически важный для системы поток. Это может привести к неопределенному поведению в масштабе кластера [workerName = db-checkpoint-thread, threadName = db-checkpoint-thread- # 59, blockedFor = 209s]

Я предполагаю, что, поскольку я принудительно закрываю приложение Java, которое запускает узел Ignite Client, возможно, что может произойти некоторый дисбаланс топологии.

Может ли кто-нибудь предложить, если я вообще принудительно убью клиентское приложение, есть ли правильный способ перезапустить клиентское приложение, чтобы оно продолжало восстанавливать соединение с сервером Ignite и продолжало работать?

1
RSSAH 16 Апр 2020 в 08:34

1 ответ

Лучший ответ

Этот сценарий возможен, если у вас очень большие таймауты.

Не следует ожидать, что узел будет отброшен, а новый присоединится до того, как истечет весь тайм-аут, такой как тайм-аут сети, тайм-аут записи в сокет, тайм-аут обнаружения сбоя. Это, если вы не выполните корректное завершение работы.

1
alamar 16 Апр 2020 в 13:13