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!