Inbound filter question

[carlheymann]

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.

[spencergibb]

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]

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 same context.getId(), which is used to populate the originService in RemoteApplicationEvent. 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]

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.index to use rather than port.

[carlheymann]

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]

There are hint's in the docs.

[carlheymann]

Thanks, I missed these docs, somehow.

[eacdy]

@spencergibb @carlheymann
Spring Cloud docs say that:

For example, in lattice, set spring.application.index=${INSTANCE_INDEX} in application.properties (or bootstrap.properties if using configserver).

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]

@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.