События из хранилища событий AxonDB не поступают в мой TrackingEventProcessor

В настоящее время я пытаюсь прочитать все события из хранилища событий AxonDB и экспортировать их в файл CSV. Выбранный подход заключается в создании EventHandler в приложении Spring Boot, которое подключено к серверу AxonDB. Используя TrackingEventProcessor с InMemoryTokenStore (по умолчанию), я ожидаю, что все события будут считываться из хранилища событий каждый раз, когда я загружаю это небольшое приложение.

К сожалению, я не получаю события от клиента AxonDB в моем TrackingEventProcessor, что уже пару часов сбивает меня с толку. Я вошел в чрево зверя и увидел следующее поведение, которое я хотел бы обсудить:

  • Во-первых, я использую те же версии, что и исходное приложение (заполняющее хранилище событий):
    • axonDB 1.3
    • клиент axonDB 1.3
    • Axon framework 3.2.1
  • Приложение успешно подключается к AxonDB через gRPC.
  • AxonDBEventStore читает кучу событий
    • 2018-08-16 13:56:49.337 DEBUG 27781 --- [ault-executor-0] i.a.axondb.client.axon.AxonDBEventStore : Received event with token: 17742 и т. д.
  • Мой TrackingEventProcessor запускается с сегментом [0/0], что мне кажется правильным, поскольку я использую InMemoryTokenStore
    • 2018-08-16 14:18:50.190 INFO 30006 --- [t-projection]-0] o.a.e.TrackingEventProcessor : Fetched token: null for segment: Segment[0/0]
  • TrackingEventProcessor запускается и пытается передать следующий оператор (из строки 248 исходного кода в версии 3.2.1):
    • if (eventStream.hasNextAvailable(1, SECONDS))
    • Вышеупомянутая проверка всегда возвращает false, потому что реализация eventStream (EventBuffer от клиента AxonDB) всегда возвращается без результатов.

Я уже давно кусаю пыль и думаю, что зашел в тупик. Я не получаю сообщений об ошибках или исключениях. Чтение событий, похоже, работает, что подтверждается журналом AxonDBEventStore. Но после этого EventBuffer остается пустым, поэтому мой процессор даже не проверяет, должен ли он обрабатывать события, которые ему предъявляются. Полагаю, здесь проблема не в названии моего процессора. Я безуспешно пробовал несколько названий процессоров (которые соответствуют данным в событиях). Десериализация, похоже, работает, так как вчера я обнаружил десериализованное событие где-то во время отладки (хотя не могу вспомнить, где ...). Выглядело так, как я ожидал.

У кого-нибудь есть идеи, в чем может быть проблема?

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
259
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Не могли бы вы попробовать обновить клиент AxonDB до версии 1.3.1, так как в версии 1.3 возникла проблема, когда не были определены апкастеры.

Пожалуйста, дайте мне знать, если это поможет.

С уважением,

Марк Гатье

Привет, Марк, спасибо за ответ. Я пробовал это только сейчас. К сожалению, это не меняет поведения приложения. Я все еще получаю те же результаты.

Ostecke 17.08.2018 09:10

Вы упомянули, что у вас есть два разных приложения. Есть ли у вас общий модуль между этими приложениями, который разделяет основной API (команды, события и запросы)? Если по какой-то причине это не так, совпадает ли полное имя ваших событий (одно в приложении публикации, а другое в приложении-потребителе)? Если полное имя событий не совпадает, обработчик событий отслеживания не сможет его уловить.

Сообщите мне, если это поможет вам!

Ваше здоровье, Милан.

Ответ принят как подходящий

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

Моим первоначальным намерением было создать универсальный инструмент для перезаписи GenericEventMessage в CSV через приложение Spring, а не писать конкретный инструмент для проекта, над которым я работал. Вероятно, это невозможно, и TrackingEventProcessor нуждается в POJO в вашем пути к классам для генерации GenericEventMessage. Раньше мне этого не приходило в голову.

Другие вопросы по теме