пользовательский десериализатор не вызывается apache storm

Штормовая версия - 1.0.6.

У меня есть собственный сериализатор, зарегистрированный для одного из моих классов. Как и ожидалось, вызывается метод записи, который успешно выполняется. Однако метод read моего пользовательского сериализатора вообще не вызывается, хотя execute вызывается в последующих болтах. Я тестирую это в локальном кластере, всегда пытаясь сериализовать значение true.

Я предполагаю, что по какой-то причине Storm не доволен моей пользовательской сериализацией и передает кортеж как есть в нисходящий поток без сериализации. Значение указателя поля, которое я вижу в нисходящем болте, такое же, как и то, которое было испущено.

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


person user3612009    schedule 19.03.2018    source источник


Ответы (1)


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

См. проверка сериализации, где проверка вызывается и где десериализация происходит в нелокальном кластере.

person Stig Rohde Døssing    schedule 20.03.2018
comment
Спасибо. Это имеет место даже в том случае, когда топология выполняется в кластере, но болты выполняются в одном и том же рабочем потоке? - person user3612009; 21.03.2018
comment
Да. Взгляните на класс ExecutorTransfer, который я связал, это тот код, который обрабатывает диспетчеризацию кортежей между исполнителями. Если целевой исполнитель является локальным (в том же рабочем потоке), нет причин сериализовать кортеж, поскольку его можно передать по ссылке. - person Stig Rohde Døssing; 22.03.2018