Необходим ли Zookeeper для одного узла XD?

Этот вопрос относится к выпуску XD 1.1.2.RELEASE. Я новичок в XD, поэтому, пожалуйста, простите, если это глупый вопрос.

В документации сказано только, что XD не поставляется с Zookeeper, и я понял, что это будет необходимо только тогда, когда я буду готов перейти на несколько узлов.

При этом я получаю нежелательное поведение при попытке развернуть поток: 1. Каждый раз, когда я добавляю поток, он не сохраняется при перезапусках XD. 2. Время ожидания настройки потока истекло. В режиме отладки он застревает в ModuleDeploymentWriter в spring-dirt. Если я правильно читаю этот класс, кажется, что он записывает файл для чтения Zookeeper, а затем истекает время ожидания, когда ответ так и не получен.

Сначала я подумал, что истекло время ожидания моего пользовательского подключения к приемнику Cassandra XD, но, похоже, этот код никогда не был достигнут.

Любая помощь приветствуется!


apache-zookeeper spring-xd
person Will Milligan    schedule 14.05.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

В документации сказано только, что XD не поставляется с Zookeeper, и я понял, что это будет необходимо только тогда, когда я буду готов перейти на несколько узлов.

Вот так. Но в одном узле XD используется встроенный ZooKeeper.

  1. Каждый раз, когда я добавляю поток, он не сохраняется при перезапусках XD.

Вы используете один узел или распределенный режим? Если вы используете одиночный узел, каждый раз, когда XD перезапускается, он использует другой экземпляр ZooKeeper. Следовательно, в одиночном узле вы не можете сохранить потоки между перезапусками сервера. Вы по-прежнему можете переопределить эту функцию, предоставив внешнюю конфигурацию ZK для одного узла, установив zk.client.connect в server.yml.

  1. Настройка потока истекает по тайм-ауту.

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

В случае, если вы работаете в режиме отладки, как упоминалось @dturanski, вы можете попробовать увеличить свойство времени ожидания развертывания xd.admin.deploymentTimeout в server.yml. По умолчанию 30 с.

person Ilayaperumal Gopinathan    schedule 14.05.2015
comment
Я увеличил тайм-аут до 3000 с, и все равно он истекает. Я хотел бы, чтобы были какие-нибудь полезные сообщения журнала или трассировка стека, но я ничего не получаю здесь. Я работаю в одномодовом режиме. Похоже, что, возможно, мне все равно следует запустить Zk, но пока я озадачен тем, чего ждет модуль записи потока. - person Will Milligan; 15.05.2015
comment
хм, на какой строке застрял ModuleDeploymentWriter? - person Ilayaperumal Gopinathan; 15.05.2015
comment
Он застрял на 471, в режиме ожидания(). Непосредственная причина, по которой он застрял, заключается в том, что addResult() не вызывается вовремя для тайм-аута. Сумасшествие в том, что в конечном итоге вызывается addResult . Чем дольше я устанавливаю тайм-аут, тем больше времени требуется для копирования addResult. Теперь время ожидания развертывания потока установлено примерно на час, и это, кажется, только замедляет процесс. Должно быть что-то еще, что я упускаю, я рву на себе волосы. В конце концов я установил Zk, и он работает нормально. - person Will Milligan; 15.05.2015
comment
ModuleDeploymentWriter использует ResultCollector, который является CuratorWatch. Он устанавливается на module deployments status path в ZK для каждого модуля в потоке. Этот путь состояния (со статусом «развернуто» или «сбой») в конечном итоге будет обновлен контейнером, когда он развернет модуль или истечет время ожидания. В вашем случае, кажется, есть некоторые проблемы со встроенным ZK, который использует singlenode. Вы можете проверить, правильно ли заданы пути ZK на встроенном ZK. При запуске сервера с одним узлом в журнале будет отображаться встроенный URL-адрес подключения ZK. - person Ilayaperumal Gopinathan; 15.05.2015
comment
Я больше не использую встроенный ZK, но все еще сталкиваюсь с похожими проблемами. Автономный ZK создает путь xd и даже развертывает мои пользовательские модули. Согласно автономному ZK, мои модули источника и приемника развертываются, но не поток. А в логе почти ничего полезного нет. - person Will Milligan; 15.05.2015
comment
› Согласно автономному ZK, мои модули источника и приемника развертываются, но не поток. А в логе почти ничего полезного нет. - Я не понимаю, что вы имеете в виду, говоря, что ваши модули развернуты, а не поток. Stream будет иметь общий статус развертывания для содержащихся в нем модулей. Вы имеете в виду, что статус потока не обновляется? а по логу ничего полезного не находишь даже после активации DEBUG лога? Я думал, что журнал отладки, по крайней мере, перечислит все шаги развертывания. - person Ilayaperumal Gopinathan; 15.05.2015
comment
После включения DEBUG все равно нет. Я вижу много таких: - person Will Milligan; 15.05.2015
comment
Но поскольку ничто из того, что я использую, не использует JPA, я не совсем уверен, почему xd говорит мне об этом около 20 раз. После шквала сообщений в журнале в журнале больше нет никакой активности. - person Will Milligan; 15.05.2015
comment
Наконец, я не уверен, что делать с тем, что ZK показывает мне. Может быть, я неправильно прочитал это раньше. Я тоже новичок в этой технике. Вот статус: - person Will Milligan; 15.05.2015
comment
хорошо, да, статус потока установлен на deploying и возникают проблемы, когда соответствующие модули развертываются в контейнере. что показывают команды оболочки stream list и runtime modules? - person Ilayaperumal Gopinathan; 15.05.2015
comment
список потоков показывает, что мои попытки потоков развертываются, по крайней мере, до тех пор, пока не будет достигнуто время ожидания в один час. Потом говорят, что они провалились. Модули среды выполнения показывают пустой список. - person Will Milligan; 15.05.2015
comment
хорошо, более длительный тайм-аут не имеет смысла, если вы не отлаживаете и вам не нужно некоторое время. Как правило, если ZK работает, вы должны быстро его развернуть. Более длительный тайм-аут (5 с) установлен для использования в большом кластере, а также для того, чтобы все контейнеры могли отвечать, если у вас есть больше модулей в данном потоке. В вашем случае развертывание завершается неудачно из-за тайм-аута, и я считаю, что в этом случае 5 секунд должно быть достаточно. Вы пробовали простой поток, такой как time | журнал. Если вы развертываете пользовательский модуль, проверьте, что с самим модулем что-то не так. - person Ilayaperumal Gopinathan; 15.05.2015
comment
Хм. время | лог развернулся почти моментально. У меня есть собственный модуль, который я создал (cassandra, как это бывает), но в моих последних тестах я пытался сделать что-то простое, просто указав http --port=9020 | журнал. Остальная часть http-модуля должна быть прямо из коробки, и единственное, что я добавляю, это этот порт. Может ли это как-то испортить ситуацию? - person Will Milligan; 15.05.2015
comment
И теперь, после перезапуска, все (включая новое время | потоки журналов) ВСЕ застревает в статусе развертывания. - person Will Milligan; 15.05.2015
comment
Странно, что вы не видите никаких журналов об ошибках развертывания. Ожидается, что в журнале контейнера будет несколько журналов неудачных развертываний с указанием причины сбоя. Поскольку основные потоки не развертываются, я подозреваю, что в вашей среде что-то странное. В качестве альтернативы вы можете попробовать запустить распределенный режим? или, Можете ли вы открыть задачу JIRA или github со всей имеющейся у вас информацией журнала. - person Ilayaperumal Gopinathan; 15.05.2015
comment
Я могу попробовать это, но я надеюсь, что это не будет необходимо. Это совершенно новый экземпляр GCE, на котором нет ничего, что я туда не поместил... и пока я добавил только java 8, xd и zookeeper. - person Will Milligan; 15.05.2015
comment
Стоит проверить, может ли быть проблема с разрешением имени хоста в приложении-контейнере на одном узле. Вы можете увидеть, какой IP-адрес/имя хоста назначено контейнеру, когда вы запускаете xd-singlenode. Если вы используете все на локальном хосте, возможно, вы можете попробовать установить эти свойства среды: XD_CONTAINER_IP и XD_CONTAINER_HOSTNAME как «localhost» и посмотреть, работает ли это. - person Ilayaperumal Gopinathan; 16.05.2015
comment
Думаю, я понял это. Вы были правы, это экологическая проблема. Я запускал xd в bash в качестве фонового задания, и это было нормально, за исключением того, что единственным способом выключить его было использование bash kill. Я думаю, это что-то напортачило. Запуск в качестве процесса переднего плана в выделенном терминале и завершение работы с помощью Ctrl-C, удаление всех моих потоков и добавление с нуля, похоже, решили эти проблемы. Большое спасибо за ваше терпение и готовность оставаться с предложениями! Мне еще многому предстоит научиться. - person Will Milligan; 16.05.2015
comment
Нет проблем, я рад, что это наконец сработало :-). Не стесняйтесь задавать любые вопросы, связанные со Spring XD, здесь или в JIRA/Github. - person Ilayaperumal Gopinathan; 17.05.2015

arrow_upward
0
arrow_downward

Вам не нужен внешний Zookeeper для работы в одном узле, так как он запускает встроенный сервер. Это сохраняет состояние в памяти, поэтому вы теряете состояние между перезапусками. Однако вы можете настроить его для подключения к внешнему ансамблю Zookeeper.

Если «модуль отладки» относится к запуску SingleNodeApplication с отладчиком, то да, время ожидания может истечь, если вы установите точку останова.

person dturanski    schedule 15.05.2015