Add support for /bus/pause and /bus/resume endpoints

[michelzanini]

The same way we have /bus/refresh it might be useful to have /bus/pause and /bus/resume.
My use case was already mention on Spring Cloud Config:
The ability to stop message listener containers to turn the app into read only mode.
That can be done by sending a pause event, then Rabbit containers stop getting messages.
But with the Cloud Bus will be possible to send an event to all my consumers at once.

Thanks.

[dsyer]

Won't it pause the bus and prevent it from accepting the resume event? (That's something to watch out for when someone implements this.)

[michelzanini]

Good point. I think you are right. This is quite tricky. I will think about other ways of doing this, thanks.

[dsyer]

I still think it's a good idea. Maybe the bus inbound adapters can be excluded from the pause event? Doesn't sound like it should be too hard to me.

[dturanski]

@dsyer - Interesting, spring-cloud-stream bindings do not create these components (AmqpInboundChannelAdapter and SimpleMessageListenerContainer) as beans, e.g. here. So the good news is the bus does not need to be excluded. The only way to pause and resume these components is via JMX which exposes the (stop() and start() LifeCycle methods). I've done something similar things in XD with Jolokia. Also, note that it's generally better to stop the the ListenerContainer than the InboundAdapter as the latter will cause back pressure locally vs on the broker.

So, a simple approach might be query the Application Context for beans with a class name that endsWith('ListenerContainer'). This covers all the known listener container types including JMS, AMQP, Kafka, and Gemfire Continuous Query. In order to affect Spring Cloud Stream bindings, we will also have to look for beans of type InputBindingLifecycle and OutputBindingLifeCycle (which would have to exclude the bus)

[dturanski]

Another idea I had is to delegate to the /pause /resume endpoint to call stop() and start() on the app context. The problem is that the app context in that case is a child of the one with all the interesting beans, so those endpoints don't have much affect for this use case