Switching on/off Gateways and service activators

[kkcmadhu]

Hi All,

I am trying to build my services stack backed by spring integration and AMQP. One of our goal is to have a fine grained control of each service (i.e we should be able to suspended/commission/monitor the services as desired).
Our straw man idea for now is to have each of our service behind a service activator , front ended by an amqp inbound gateway/inbound handler. (clients will place the request in a rabbit Q, ibound gateway/handler picks this message and places the response in the replyQ).

So if i have 5 services, i will be having 5 amqp-inbound gateways and 5 service activator ,where each of the inbound gateway listens of a separate Queue(Rabbit Q). I call this whole setup an SI-Server (hosting my services)

To scale I am planning to have many such instance of SI-Servers. (cluster mode).

For fine grain control of each of the service in the SI-Server, I need a mechanism to suspend/resume services, without affecting other services in the same SI server instances. Is there a way to achieve this in Spring Integration?

One solution which i am thinking of is to have a on/off switch for each of the amqp-inbound gateway, and a way to switch on/off the gateways at run time.
Can the community throw some light of how this can be achieved, or suggest a better way to achieve this. Or do you think if spring-integration is not the correct tool for this use case?

[Gary Russell]

You can start/stop the inbound adapters/gateways using JMX or the <control-bus/> by sending '@adapterId.start()' or '@adapterId.stop()'.

For multiple instances you'd have to control the adapter on each instance.

We demonstrated some clustering techniques at SpringOne; the demo code is here https://github.com/garyrussell/sprin...ration-ha-demo.

For a non-single source cluster (where all the instances are competing consumers), the cluster controller has an MBean operation pauseAll() which can be used to stop the inbound adapter on each instance; it is not instantaneous however, it depends how often the instances are configured to check their state. Probably only worth going that route if you have many instances and can't use some other management technique to stop the adapter on each instance.