Closed
Description
The inbound filter, defined in BusAutoConfiguration.inboundFilter(), includes the condition
!serviceMatcher().isFromSelf(event)
This seems to ensure that processes running the same app won't be able to communicate through the bus. Why is this? Wouldn't it make sense for apps to be able to send each other messages through the bus? Or am I missing something?
It also means that one has to invoke /bus/refresh on a separate app (e.g. on a config server with the bus enabled). Invoking it on one of the processes for the app in a cluster results in only that process being refreshed, because because it handles the context level event. The processes will filter out the refresh event.
Activity
spencergibb commentedon Jun 17, 2015
The bus is implemented using Spring
ApplicationEvents. So when a bus event is posted to/bus/*, the receiving service processes that event then sends it to rabbit. That filter is there to not process the message twice.carlheymann commentedon Jun 17, 2015
The problem I see, is that if there are multiple processes for an app with a specific
spring.application.name, they will all have the samecontext.getId(), which is used to populate theoriginServiceinRemoteApplicationEvent. So if one of them tries to send a message out, the messages will be filtered out everwhere, i.e. even on processes where the message didn't originate from.How about using a UUID, generated in the context at runtime, for the event's originService?
spencergibb commentedon Jun 17, 2015
Yes, you need to have a unique context id. See ContextIdApplicationContextInitializer for how Spring Boot creates the context id. If all instances of a service have the same name and run on the same port (valid in cloud situations), then you could supply a
spring.application.indexto use rather than port.carlheymann commentedon Jun 18, 2015
OK that makes sense. So this means that in apps using spring boot and cloud, using defaults will lead to some surprising results, right? So I suggest that this be changed to include a unique ID. A UUID seems suitable because it has to be unique to the process throughout a cluster of arbitrary size. Or else include a hint on the readme? I find that I need to include the property in the bootstrap.yml file when using spring cloud config. E.g.
spring.application.index: ${random.long}. Not a proper UUID, but could be good enough.spencergibb commentedon Jun 18, 2015
There are hint's in the docs.
carlheymann commentedon Jun 19, 2015
Thanks, I missed these docs, somehow.
eacdy commentedon Dec 3, 2016
@spencergibb @carlheymann
Spring Cloud docs say that:
lattice seems like a component of CloudFoundry(I don't quite know about CloudFoundry). I wonder whether there is a similar value like ${INSTANCE_INDEX} when I use docker ?
Or, I should config just like this
spring.application.index: ${random.long}?spencergibb commentedon Dec 5, 2016
@eacdy we generally don't want comments on old closed issues. I have no idea if there is a similar value for docker. The random long should work.
Merge pull request #18 from stonio/patch-2