Distributed command bus without JGroups or DiscoveryClient

Our application is running inside OpenShift Online and it seems that spring-cloud:spring-cloud-kubernetes is not working properly in that platform at the moment (requires some rights that are not available)

Is there any way, as a workaround, to create a Distributed Command Bus from static data? (commands and endpoints in a list in a config server)?

Victor,

Would also be interested in knowing the eventual outcome of above mentioned concern. We’re in the process of moving towards the same stack (spring-cloud:spring-cloud-

kubernetes) At the moment using spring-cloud-eureka service as a discovery-service and eureka-client (discovery-client) on each microservice. From an axon point of view it’s working however registering/deregistering a service has a long lag which is not ideal.

So to get back to your problem, in theory it should just work seeing that spring-cloud-kubernetes is a DiscoveryClient. See docs: https://docs.axonframework.org/part-iii-infrastructure-components/spring-boot-autoconfiguration#using-spring-cloud Perhaps there’s an issue with propgating metadata as described in docs?

Regards,
Dylan

Hi,

basically, you’ll need to implement the CommandRouter interface and use a static list. Somehow, you’d have to find out if the nodes in your static list are available or not, probably by pinging them. Also, you’ll need to know which commands each node supports (but maybe that’s fixed as well).

If everything is static, you wouldn’t need to implement the “updateMembership” method. It can be a no-op. The “findDestination” method should return one of the members in a static list based on consistent routing algorithm. Helper classes for that are available (see org.axonframework.commandhandling.distributed.ConsistentHash).

We have also noticed the long lag with Discovery based mechanisms. Unfortunately, this seems to be part of their design. In AxonHub, we have addressed the challenges of message routing (in a way that’s compatible with Kubernetes) and discovery is practically immediate.

Hope this helps.
Cheers,

Allard

Thank you.

I already did something quite similar: Everything is static, but I delegate de routing to kubernetes services (reverse proxy). Instead of monitoring and registering every pod for a service, I just call throw the service endpoint.