Persistent streams questions

Axon Framework
, ,
1
  1. “Persistent streams require Axon Server version 2024.1 or higher.”. How about axon in cloud (contexts created via https://console.cloud.axoniq.io)? Does this support PS?
  2. Could this be an alternative to pooled streaming processors? Can you list the advantages and disadvantages of both (compare them)? I would like to get rid of the token table in the db and the massive db operations behind maintaining that.
  3. Is it working well with multitenancy?
  4. How to migrate from pooled streaming processors to subscribing persistent streams?
2

@Marc_Gathier @Steven_van_Beelen
?

3

At this moment Axon Cloud is still running Axon Server 2023.2.x, so it does not support persistent streams yet. We are planning to upgrade Axon Server in cloud to 2024.1 or 2024.2 soon.

Persistent streams can definitely be used as an alternative for pooled streaming processors. The advantage of this would be as you mentioned, no need for the token entry table anymore, and more automatic balancing of segments over connected applications.
A disadvantage is that the update of the progress for persistent streams is not in the same transaction as the processing of the events, as these actions are not stored in the same database. Persistent streams guarantee at least once delivery, but in some cases (when the status update from the client could not reach Axon Server) events may be sent more than once.

The multi-tenacy extension also supports persistent streams.

To migrate from pooled streaming processors to persistent streams you need to change the event processor configuration in the application and ensure that you initialize the persistent stream at the last (most recent) token. You don’t have to change the event handlers.

1 Like
4

@Marc_Gathier @Steven_van_Beelen
Thanks for the clarifications. So in the meantime (before axon cloud will support PS) is it any way/strategy to limit these token table queries frequency (update/select)? They are running constantly so cannot optimize db (resource) usage costs. I have ~10 services (x 3 tenants which cause ~30 schemas in db) which constantly quering their own token table.

5

Hello @Marc_Gathier

I believe a migration guide is in order with regards to migrating toward PS from other EP strategies; pro’s, design choices, trade-off’s e.t.c for the sake of clarity.

Is this possible?

Thank you.

6

There are ways to limit the number of queries on the token table. First, you can increase the batch size for the event processor. This will reduce the number of updates for a processor if there are many events arriving around the same time.
Secondly, if you have multiple application instances, you can increase the tokenClaimInterval, see Streaming Event Processor.

7

The thing is about when there is no traffic means no event arrives - e.g. during night there is no traffic but still token table is intensively queried. So as I understand that this batch size will not resolve the issue
token_table_queries

8

The token claims are there, @KaeF, to do two things:

  1. Ensure that in a distributed setup, only a single thread is processing events for a given segment of the stream.
  2. A blocked Event Processing thread would be incapable of updating the token claim. Hence, not seeing an updated timestamp on the token_entry means a thread is blocked. This occurrence allows other threads to steal the claim to take over event processing.

There is an option to impact the frequency, but you will drop the certainty just described. If you’re using a TrackingEventProcessor, you can increase the eventAvailabilityTimeout setting. For the PooledStreamingEventProcessor, that’s the claimExtensionThreshold.

But, if you increase those values, you also increase the time window wherein a blocked event processing thread would be stalling your event handling tasks. Thus, your query models are updated even later, or your process kicks-off more slowly.

To be frank, I wouldn’t recommend increasing eventAvailabilityTimeout/claimExtensionThreshold to bridge your “evening” slot at all. Then again, I cannot vouch for your cloud provider costs, of course.

Perhaps it is easier to shut down your event handlers during the evening, @KaeF? The benefit of a message-driven architecture is the possibility of running the event-handling side as a separate application. If you are certain about the time windows where you don’t want that to be active, you can thus shut it down there.

Granted, it would make your app less reactive IF somebody wants to use it in the evening. In that case, the events are simply not processed. But, for that, you’d need token claim updates, I am afraid. Or, you would need to create some other reactive component to start the event handling side of your application whenever actions are dispatched. Bit of work, but doable, I believe.

9

Thanks for the explanation.

Although I wouldn’t say I like this solution, I don’t want to interfere with the design assumptions and won’t change it.

I’ll wait for the possibility of using persistent streams and until then I’ll optimize the database costs in different way.

10

Sure thing, @KaeF. Always glad to clarify.
Your valid concern is a definite reason Persistent Stream support was introduced to Axon Server in the first place.

If we do not notify you when we upgrade to a more recent Axon Server version in our cloud offering, be sure to nudge us once you feel the time is right!