When to use SubscribableMessageSource

Hi

Can someone help me to understand, When to use “SubscribableMessageSource” and whats is the purpose with an example.

Not able to understand from the axon document.


axon:
    eventhandling:
        processors:
            name:
                mode: tracking
                source: eventBus

The source attribute refers to the name of a bean implementing SubscribableMessageSource or StreamableMessageSource that should be used as the source of events for the mentioned processor. The source default to the event bus or event store defined in the application context.

Thanks

Hi Azeem,

Axon has two technical solution to getting the events from the EventBus/EventStore over to the event handlers you’d write yourself.
These are the SubscribingEventProcessor and the TrackingEventProcessor.

The first receives events as they are published, by subscribing to a source of those messages.
This event handling happens in the same thread as the thread which has originally published the event.

Thus, the SubscribingEventProcessor requires a SubscribableMessageSource, as it needs to subscribe itself to get events.
As you’ve noticed, the EventBus is an implementation of a SubscribableMessageSource, and hence is provided to SubscribingEventProcessors

The TrackingEventProcessor keeps it’s own record of the events it has handled, by storing that knowledge in a token.
As it is doing this on it’s own accord, it is thus a separate thread from the original event publishing thread.
Additionally, it thus requires to be able to retrieve those events itself.
As we typically refer the retrieval of these events as a ‘Stream of Events’, it thus requires a StreamableMessageSource.
The EventStore is an implementation of both the EventBus and the StreamableMessageSource, and due to this it can be used as the source for a TrackingEventProcessor.

The default EventProcessor in Axon 4 and up is the TrackingEventProcessor, as users typically want their event handling to be dealt separately from the event publishing.
Axon 3 however defaults to the SubscribingEventProcessor, as it does involve less moving parts to think about when you’re starting off your Axon based application.

A very short rule of thumb when to use what, could be something along the lines off:

  • Are you updating a query model you need to replay in the future? Use a TrackingEventProcessor. Is the event handler a fire-and-forget like operation? Use a SubscribingEventProcessor.

Hope this sheds some light on your options Azeem.

Cheers,
Steven

Thank’s Steven for your detailed explanation.