Штормовой болт не может десериализовать объект из носика - PullRequest
Новая
       55

Штормовой болт не может десериализовать объект из носика

0 голосов
/ 13 сентября 2018

Я делаю весеннее приложение, используя Storm 1.1.2, JDK 8 (Storm не понравился скомпилированный код JDK 9), Kafka 0.11 и Docker Compose.

Идея состоит в том, чтобы создать контейнерную службу, которая может принимать вызовы REST для создания топологических топологий, а затем отправлять их в кластер штормов. Все работало локально, но перемещение отправки топологии из отправки в локальный кластер в StormSubmitter вызывает проблемы. У меня есть большинство из них решены, но есть странная проблема сериализации.

У меня есть носик, который успешно читает с Кафки. Он читает байтовые массивы объектов Protobuf и использует собственный десериализатор для создания сообщений из них. У меня есть два разных болта, считывающих этот носик, один из которых печатает входящие сообщения (болт A), а другой фильтрует сообщения на основе поля и отправляет их на другой болт, который будет агрегирован (болт B).

Единственное различие, которое я замечаю между двумя болтами, состоит в том, что болт B имеет конструктор, а болт A - нет.

По какой-то причине болт А без проблем получает сообщения из носика и печатает их, но каждый раз, когда сообщение приходит к болту Б, он выдает исключение com.esotericsoftware.kryo.KryoException: Class cannot be created (missing no-arg constructor): my.package.MyProtobufMessage. Я вижу, что вы можете зарегистрировать сериализаторы для классов, но почему болт А может обрабатывать сообщение, когда болт Б не может?

Также отдельная проблема, но когда я добавляю третью топологию, nimbus не назначает ему супервизора. Одна топология будет работать с 2-мя работами и 9-ю руководителями, вторая топология будет работать с 2-мя работниками и 6-ю руководителями, а затем я добавлю третью топологию, которая будет отображаться в журналах UI и Nimbus, но не в журналах супервизора. В пользовательском интерфейсе третьей топологии будет 0 рабочих, execs и 0 назначенных mem

1 Ответ

0 голосов
/ 13 сентября 2018

Возможно, вам «повезло» в том, что носик и болт А находятся в одном и том же рабочем, а болт В - в другом.Storm не сериализует кортежи, если они не переданы другому работнику, поэтому болт А может прочитать сообщение.

Что касается третьего вопроса о топологии, вам необходимо убедиться, что у ваших супервизоров достаточно рабочих слотов для вашеготопологий.Каждый супервизор определяет в конфигурации Storm (storm.yaml), сколько рабочих JVM он хочет запустить.Я предполагаю, что первые две топологии занимают все слоты.

Конфигурация по умолчанию для супервизоров - 

supervisor.slots.ports:
    - 6700
    - 6701
    - 6702
    - 6703

, что позволяет использовать 4 рабочих JVM на каждом супервизоре.Поскольку рабочие JVM не являются общими, если вы используете 2 топологии, каждая из которых занимает 2 рабочих места, вы использовали все слоты.Вы можете либо добавить больше слотов, либо больше компьютеров супервизора, либо уменьшить количество работников, необходимых для вашей топологии.

...