Good Day. I’ve enabled
axon:
distributed:
enabled: true
in properties. I enabled eureka client and configured axon-distributed-commandbus-springcloud:3.1 and axon-spring-boot-starter:3.1
But My commands dispatched in SimpleCommandBus not in DistributedCommandBus.
How to enable distributed command bus?
You can use -Ddebug as JVM parameter (or —debug as app param) to have Spring output a report that will tell you which beans have been created and why (not).
Look for the DistributedCommandBus or the SpringCloud(HttpBackup)CommandRouter.
Also, do you wire a CommandBus or a SimpleCommandBus in your application?
Cheers,
Allard
Thank you for the help, Allard! I’m wiring a CommandBus.
I’ve figured out about this issue. (it was wrong configuration for discovery client)
Axon is really the great framework.
However I have next issue,
I every 30 second get 404 error to fallback /message-routing-information for configuration service.
Should I disable fallback?
And also I get “No node known to accept [wepoll.topic.CreateTopicCommand]”
But I have running service with @CommandHandler for this type of command
I’m new in Axon framework, sorry if I waste you time.
Ok I figured out that
CommandGateway has to be injected to receive commands from other nodes.
Hi Vladimir,
All questions are valid, so it’s definitely not a waste of our time; so please keep posting questions!
For your issue at hand, let me first answer the fallback mechanism.
The fallback mechanism for the SpringCloudCommandRouter was mainly introduced as there are Spring Cloud implementation which do not support the adjustment of their own Metadata (for example, Consul).
However, as I see you’re using Eureka, that method of sharing the message routing information between the nodes should work fine.
Thus, you’re not inclined to use the fallback mechanism in your situation.
The reason that you’re receiving a 404 is however still interesting, as it should only try to pull message routing information of nodes which are in your cluster.
Could you check which nodes are alive in your Eureka Cluster and see which node’s message routing information request fails due to the 404?
And for your second question, which you’ve seemed to have fixed: if ‘no node is known to accept command [x]’, that means that the application publishing the (in your scenario) CreateTopicCommand can’t find any other nodes which are able to handle that command.
This might occur because of the 404 you’re receiving, as that call is done so that a node in the cluster knowns what all the other nodes in the cluster can handle message-wise.
Thus if it fails to update it’s knowledge of what every node can do, it could just as well think that no node is able to handle your CreateTopicCommand.
Hope this helps you out Vladimir!
Cheers,
Steven
In my Eureka server I have six services:
I get 404 for CONFIGURATION-SERVICE
it’s Spring Cloud Config server with default configuration. I added axon auto configuration dependencies.
Hi Vladimir,
the 404 is caused by Axon’s attempt to retrieve capabilities from that service. Since it’s not an Axon service, it won’t get that information. The SpringCloudCommandRouter should blacklist that instance (not asking it again), but it seems not to do that for some reason.
Why the commands don’t get routed, is a mystery, so far. Can you see any “command filters” configured on any of the service instances’ meta data?
Cheers,
Allard
Hi Vladimir, Allard,
The blacklisting on an exception\ was added in in Axon version 3.1.1.
Axon Framework 3.1 only introduces the fallback mechanism, not the blacklisting on exceptions occurring (my bad).
Additionally, if you’ve got services you know before hand will never handle any Axon traffic, your can add a Predicate serviceInstanceFilter to the configuration of your SpringCloudCommandRouter/SpringCloudHttpBackupCommandRouter.
That predicate can then be set up to ignore service instances with specific names/etc, which in your case could be a filter on the application name ‘CONFIGURATION-SERVICE’.
Hope this helps you out.
Cheers,
Steven
Hi Steven, Allard.
Yeah, after migrating to 3.1.1 everything is fine! No more 404 exception and nonaxon services are blacklisted .
Commands are routed as well and no more issues.
Thank you for the help!
however this expression is always true for me
https://github.com/AxonFramework/AxonFramework/blob/master/distributed-commandbus-springcloud/src/main/java/org/axonframework/springcloud/commandhandling/SpringCloudCommandRouter.java#L175
And it still requests fallback url.
Am I doing something wrong ?
Hi Vladimir,
Good to hear the version increment to 3.1.1 did solve some of your issues!
Happy to have been of help 
Second, the statement should return true for any non-blacklisted service instance.
So for all your Axon-Nodes, that should be the desired behavior.
But your comment seems to suggest it also returns true for your ‘CONFIGURATION-SERVICE’ Service Instance.
Is that correct?
Cheers,
Steven
Yes, it returns true for ‘CONFIGURATION-SERVICE’
Hi Vladimir,
That’s interesting. First thing that pops to mind is that an equals between two identical EurekaServiceInstances isn’t true.
That would definitely be an issue, I’ll look into that asap.
If you find any other points of interest, please do share!
Cheers,
Steven
Hi Vladimir,
I tested the situation and did regard this as a bug.
The ServiceInstance implementations do not necessarily have an equals() function, something which is an issue with the contains() function which was being called.
I opened up a bug ticket and resolved it.
The fix should be a part of 3.1.2.
Thanks for notifying us of it, feel free to try it out and see if it solves the issue you had!
Cheers,
Steven
Thank you Steven!
Waiting for updates. Anyway this bug doesn’t stop me…