Apache Сценарий перезапуска Ignite Client - PullRequest
0 голосов
/ 16 апреля 2020

Это сценарий

  1. Я запустил узел сервера.
  2. Я запустил узел Client Ignite, который будет выполнен через приложение Java, скажем «X».
  3. В visor я мог видеть два узла, один из которых является клиентом, а другой - сервером, когда была дана команда "node".
  4. Я убил Java приложение "X", выполнив команду "kill -9 pid".
  5. Теперь, когда я go захожу на терминал и ввожу "узел", он по-прежнему показывает узлы "клиент" и "сервер" в списке. когда его спрашивают о деталях клиентского узла, он, очевидно, выдает ошибку.
  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""}"

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

[10:37:57] Возможный сбой подавлен в соответствии с настроенным обработчиком [hnd = StopNodeOrHaltFailureHandler [tryStop = false, timeout = 0, super = AbstractFailureHandler [ignoredFailureTypes] = UnmodifiableSet [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], faultCtx = FailureContext [тип = SYSTEM_CRITICAL_OPERATION_TIMEOUT, err = класс oaiIgniteException: рабочая точка считывания блокировки 37 получение [получено 57] [SEE] [истекло]: [получено] 57 [ВЫБРАТЬСЯ]: [получено]: [истекло] [истекло]: [было получено] [истекло] [получено: 57,7 []]: из-за того, что [истекло]: [истекло]: [истекло]: время ожидания [истекло] [получено: 57,7 []]: обмен времени: [истекло]: обмен времени: [истекло]: [истекло]: [истекло]: время ожидания [истекло]. 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.persatabaseckhahaCrid.rid GridCacheDatabaseSharedManager. java: 1640) в орг. apache .ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initTopologies (GridDhtPartitionsExchangeFuture. javaite. 10 *. 10. At. 1041 at. 1078). internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init (GridDhtPartitionsExchangeFuture. java: 944) в орг. apache .ignite.internal.processors.cache.GridCachePartitionExchangeManagerP : 3258) в орг. apache .ignite.internal.processors.cache.GridCachePartitionExchangeManager $ ExchangeWorker.body (GridCachePartitionExchangeManager. java: 3104) в орг. apache .ignite.internal.util.worker.GridWorkerrun (GridWorker. java : 119) at java .lang.Thread.run (Thread. java: 748) [10: 39: 21,547] [SEVERE] [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, blockFor = 209s]

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

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

1 Ответ

1 голос
/ 16 апреля 2020

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

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

...