Search code examples
spring-bootaxon

@EventHandler retry logic and DistributedCommandBus setup


1st Question: So I am using Spring Eureka and the DistributedCommandBus set via the following:

  public CommandRouter springCloudCommandRouter(DiscoveryClient discoveryClient, Registration localServiceInstance) { ... }
  public CommandBusConnector springHttpCommandBusConnector(@Qualifier("localSegment") CommandBus localSegment, RestOperations restOperations, Serializer serializer) { .. }
  public DistributedCommandBus springCloudDistributedCommandBus(CommandRouter commandRouter, CommandBusConnector commandBusConnector) { ... }

and my question for this part is how can i show that this is working? I have two K8 pods running the above code and have seen one run the @CommandHandler and the other run the @EventSourcingEvent but did not see anything in the logs to give any indication that it is using the bus.

Just want to be able to show that it is "working" as i have been asked to do so.

the Eureka part is working and i see all the info from said dashboard.


Edit - removed 2nd question to ask in another thread


Solution

  • To keep focus with my answer, I'll only provide a suggestion for your first question, which summarizes to:

    How can I point out my DistributedCommandBus set up with Eureka is actually routing the commands to different instances?

    I would suggest to set up some logging around this. That way, you could log when the message is dispatched from Node 1 and when it is handled by Node 2. Ideal for this would be to register the LoggingInterceptor as a MessageHandlerInterceptor and MessageDispatchInterceptor.

    To do so, you will have to register it on the DistributedCommandBus, but also on the "local segment" CommandBus. The DistributedCommandBus will be in charge of dispatching it and thus calling the LoggingInterceptor upon dispatching. The local segment/CommandBus is in charge of providing the command to a Command Handler in the right JVM and as such will call the LoggingInterceptor upon handling.

    The sole downside to this, is that the LoggingInterceptor will be a handler and dispatch interceptor as off Axon Framework release 4.2. Thus, for now, you will have to do with it only being a Handler Interceptor.

    However, this would suffice as well, as the LoggingInterceptor will only log upon handling the command. This would then only occur on the Node which actually handles the command.

    Hope this helps!