A few questions...

Imported from Google Groups
1

Hi Guys,

I’ve got a few questions… (using Axon v3).

1.) I’m using the DistributedCommandBus
In my case, my command creates the actual aggregate, hence i don’t really have an aggregate identifier yet.
If i omit the @TargetAggregateIdentifier annotation, the command bus routing doesn’t know how to route the command.

Could someone give me some insight into how the distributed command bus uses the Aggregate identifier to make decisions…
Maybe that will help me understand what i need to do in the scenario above.

2.) Is there any way i can use the simple command bus for command execution, but defer event execution to the distributed bus? Or even better, based on the command, decide which implementation to use?

3.) My last question relates to handling broadcast events. I’m hoping to use the Axon event handling to maintain read projections. The problem i foresee is, if i scale these projections, but each one is listening for events, how do i prevent duplicate aggregate processing… :(. I’ve seen mention of ‘locking’ strategies and using the DB itself to perform uniqueness checks. Is this the only way? Could someone point me to possible recipe’s in this area?

4.) I really love the real-time command/event handling that jgroups gives axon. A scenario i’ve been thinking of however is, what if all the target event listeners are offline. In my head, I’ve categorised the event (bus) processing as either real-time (jgroups) or polling based (rabbit, time based jpa queries, etc). So, as i said, what happens if my services that use jgroups are offline. When they come back online do they read from the event store to catch up automatically? On the other hand, polling based event handling will automatically handle the scenario… How should i handle this? (I’m really hoping this is something Axon will do for me already…)

Thanks guys,
–KD

2

Hi Kirk,

  1. The Aggregate identifier is used as input to a consistent hashing algorithm, so that each sender of commands will know to which node a command should be routed. This algorithm requires very little intra-node communication to set up and also neatly balances changes when new nodes (dis)appear.

  2. The question confuses me. Are you talking about Commands or Events? They are very distinct messages that have different publishing aspects about them. You could use different Command Busses based on the Command, but I’ve never seen a situation where this added complexity provides benefit over just using a single one. What are you trying to achieve?

  3. In Axon 3, at this time, a tracking processor will always receive all events. In future version, we want to build an implementation of a Distributed Event Processor, which balances the load over different nodes, based on the concurrency characteristics of the model. Right now, you could hard-code something. For example, if you have 2 nodes, do a “mod 2” and only process the event if the outcome matches that node’s config setting. Alternatively, use a message broker with competing or exclusive consumers.

  4. The JGroups stuff in Axon is about Commands. So whether event listeners are offline, is not an issue here. Sounds like you’re mixing up Commands and Events.

Cheers,

Allard

3

Hi Allard,

Thanks for your feedback.

Yes, i’m a bit more versed with Axion now. I approached things with just some event sourcing theory previously.
Unfortunately, i didn’t delve into the detail in the docs at first as i was a bit too excited to get going with my project.
Working with the actual Axon 3 codebase cleared up some assumptions i had… :wink:

The key part being, commands are targeted for single execution… and events are broadcast such that services can react upon them.

Once i grasped the difference concepts (and implementations) of the command bus and event bus, things started to solidify for my (conceptually).

1.) What should i do in the scenario of my command actually creating/provisioning the aggregate. The targetId isn’t known yet. Can an aggregate have more than one key it can be identified with? some alternate key that gives uniqueness? Am i making sense?

2.) I was confused at the time. I thought we could use JGroups for distributed event handling. I wanted local command handling, but ‘realtime’ event notification across vms. I now know this isn’t possible… (unless i write my own implementation… which i’m not about to do in a hurry… :wink:

3.) I may circle back to this question later. For now, i’ll go off and experiment on my own… I’d like to scale my rabbit read projections (when i get it working eventually)… and will re look at this again once I’ve come to terms with it.

4.) Yip. I was at the time. See #2. :slight_smile:

-KD

4

  1. I like client generated identifier, exactly for this reason (and a few others). Basically, just use random UUID’s, which are generated by whoever generates the command. This allows the command to be routed based on that identifier. It also allows any updates to be sent right away, because they will be routed to the same destination, without the need to wait for the result of the create command.

  2. Actually, you can use tracking event processors. In that case, each component will see every event, regardless of the location where it is produced.

Cheers,

Allard