Persistent Streams - ask for details

Axon Framework
1

Hey

Persistent Streams are to be used with Subscribing Event processors. And it’s documented that in such case a Subscribing Event processor can replay events (normally it cannot).

So, I have additional questions for Subscribing Event processor used with Persistent Streams:

  1. In which thread is the event handler executed? It’s not the same thread of the command handler that raised given event, right?

  2. Can the exception from event handler be propagated back to command handler and so to the command dispatching place?

  3. How technically the consumption of events from PS works? Is it like event handler polls Axon Server asking if there are new events (like it’s e.g. in kafka)? Or is there some factual push from Axon Server to client event handler? What is realistic latency?

  4. It seems to me that Persistent Streams semantically more match Streaming Event processors (as you can replay the events). So, I guess there was some strong motivation to bind them with Subscribing ones - what was it?

2

Persistent streams are implemented as subscribing processors, but they do not run in the same thread as regular subscribing processors, and not the same thread from command handler. In Axon Server UI - you will have options to replay, track position, control the number of segments or manipulate the token position. So yes they are being tracked, but by Axon Server, not the client application. Client application subscribes for events, and Axon Server is in charge to track how many events have been sent to application. Its true, semantically it matches Streaming Event processors. You can configure how many threads, which thread pools to use, sequencing policy etc. The processor it self does not need to keep track of anything (update token in the store), Axon Server does heavy lifting for you.

So, I guess there was some strong motivation to bind them with Subscribing ones - what was it?

Client application just subscribes for events, and does not track events anymore.

3

Hey Stefan,

Thank you for your input.

Do you also have answers for questions 1. and 3. ?

4
  1. Thread is taken from the pool. You can define your own thread pool:
 @Bean
    public ScheduledExecutorService persistentStreamScheduler() {
        return Executors.newScheduledThreadPool(10, Thread.ofVirtual()
                                                          .name("persistent-streams-", 0)
                                                          .factory());
    }

It’s not the same thread of the command handler that raised given event.

  1. Axon Server pushes events to the client app and takes note if delivery was successful, then it moves the token internally (Axon Server is the token store). The connection between client app and server is live, so there is less latency than polling and updating the token in the dedicated token store table.