Axon Event and Event Handling : Scaling problem

Imported from Google Groups
#1

Axon seem to notify all event listeners for all events. This works well if there are few 100 or 1000 event types. The moment we have say more event types say 10000 or so each event type is seeming to get published to all event listeners

e.g. 100 event types and 200 event listeners each event listeners method is parsed every time an event is published for matching and filtering the methods.
say 10,000 events got generated then 10,000 times 200 event listeners are matched.

if I have 2000 event listeners then for 10,000 events each time an event is published 2000 event listeners are parsed for matching based on method signature
that is humongous processing time.

what i thought would work better is each event type has a subscribe and unsubscribe method which will register event handlers that need to be published too rather than matching all event handlers from universal list of event handlers.

Any thoughts?

#2

Hi,

currently, Axon will indeed subscribe each handler to the Bus, which will forward all events. If you need more specific routing, you’ll need to implement that in the messaging infrastructure. However, Axon does optimize the serialization, where it will only deserialize a message if it’s really handled.

The issue I had encountered when attempting to implement a filtered subscription, is that events may be hierarchical. A messaging infrastructure doesn’t have access to the class hierarchy that an event maps to, making it impossible to find out if a specific message is “an instance of <>”. For example, a handler subscribed to AddressChangedEvent. In that case, both the “CustomerMoved” and “AddressCorrected” events need to be forwarded to that handler. Only the client is able to detect those.

Ideas are welcome.
Cheers,

Allard

#3

is this how the standard mq or messaging infrastructure deals?

like AMQP / rabbitMQ / mule / etc assumes no event hierarchy. can we not follow the same pattern?

I understand event hierarchy simplifies coding and maintenance but this leads scaling problem and exponential performance degradation esp when too many listeners are there in same cluster…

Event cluster could be one possible solution.

#4

Hi,

AMQP allows you to use routing keys and bindings with wildcards to indicate what kind of message(s) you’d like to receive. In Axon, you can customize the routing key to use based on a matcher (see RoutingKeyResolver interface). If you customize the bindings between the queues that your clusters listen to and the exchange where the messages are sent, you can filter out unwanted messages.

Cheers,

Allard