Start-up Membership updates

[smcvb]

When using the SpringCloudCommandRouter, the SpringCloudCommandRouter#resetLocalMembership(InstanceRegisteredEvent) method will clear out the local instance.
This is done, and required, as otherwise the local instance's name and URI will never be set correctly.

Forcefully removing the membership, as is done currently, can however introduce a period of time wherein a SpringCloudCommandRouter isn't aware of any memberships at all until the first HeartbeatEvent is catched to update the memberships.

It would be better to mark the local member in some fashion, so that it can be overwritten upon a HeartbeatEvent, instead of removing it entirely.

Note that I've encountered this behaviour when using Spring Cloud Kubernetes and Spring Cloud Eureka. Unsure whether other implementation, like Spring Cloud Consul for example, introduce the same behaviour, as it depends on how the local Registration is implemented.

Marking this issue as a "Could", as the time window is typically no longer than 30 seconds (the default heartbeat time interval), minimizing the risk overall.

[YuriyBarvenko1234]

hey, what is the status of this issue? I saw that Axon 4.3 has already released.

[smcvb]

Sorry for the delay here @YuriyBarvenko1234, we have quite some stuff on our plate.
As you've rightfully noticed, Axon 4.3 has been released. What's meant with this is a release of Axon Framework and Axon Server. The extensions always come after this due to their dependency on the framework.

Added, I'd like to point out our usages of tags on issues. If a ticket is being worked on, the tag Status: In Progress will be used. If no status is present, then no active work is occurring, nor any decision whether it will be processed.

[smcvb]

@corradom has spent quite some time when it comes to looking for a nice API adjustment to resolve this tiny-window issue. We have however noticed to future versions of Spring Cloud again change certain specifics when it comes to when metadata is being shared among ServinceInstances.

To get our heads around those changes and what they might mean for this extension, I have created this StackOverflow issue.

Although this enhancement obviously benefits people, we feel moving along with Spring Cloud's release train is also important. Given the fact that the expected changes would meddle with our current thoughts on this fix, we feel it justified to postpone this issue until the version upgrade has been implemented into this extension.

[smcvb]

Whilst resolving #23 I encountered this exact issue in my testing phase.
I have managed to resolve it quite cleanly in this commit.

What's essentially done right now, is that if the clean-up phase is initiated through handling the InstanceRegisteredEvent and the set of ServiceInstances found from the DiscoveryClient is empty, we at least add the local ServiceInstance (the Registration) to the set of known Axon nodes which (likely) have command handling functions.

I will thus for the time mark this issue as resolved, as local testing did resolve the problem at hand.
If anybody still encounters this problem when utilizing the SpringCloudCommandRouter, feel free to keep commenting under this issue.