can a saga send commands to the same AR it is associated with ?


I have created a saga that, upon listening for an event, fires a command to the same aggregate that the event originated from. It does not seem to work, my test hangs indefinitely. From the threaddump there are no deadlocks to be seen, just several threads in TIMED_WAITING. Is this supported ? My usecase seemed to be a natural fit for a saga, “when X happens also do Y”. I could orchestrate this from a service ofcourse, but letting axon handle it seems nicer.



are you using ‘sendAndWait’? In that case, if you’re using a SimpleCommandBus and SimpleEventBus, you have a 1-threaded deadlock. It will wait for the command to complete, but the command won’t complete until the event handler has finished. Catch 22…

Solution is either using async processing (tracking event processor is recommended) or prevent the need to wait for the command result.

One note: a saga that sends back information to the same aggregate is a ‘smell’. It is quite often an indication that logic belonging to an aggregate lives outside of it. Alternatlively, it could be an indivation of a missed ‘query’, probably in the component that issues the command.



In this case i am using a distributed commandbus and simple event bus. Note that this is all driven from a spring boot unit test, using H2 in memory db. I tried also using send semantics instead of sendAndWait on the gateway but the result was the same. Note that i did not configure an async processor on the saga, probably this part was missing.

But I agree on the code smell. It seems that the only reason i implemented the saga is because the AR cannot do the necessary queries to construct the second command, i tried to keep it fully unaware of external resources. Maybe i should just start autowiring it, though that does not feel terrific either.


You are correct to keep services out of your aggregate. I.e. don’t do the autowiring thing.

You should try to add the service data to the first command you dispatch to the aggregate. Getting this data is anyway outside the scope of the aggregate.

OK thanks for confirming this !