Starting Multiple Consumers

[ehrdoctors]

I am looking into the same issue, and think that this parent/child context seems like a work around (albeit feasible in the short term), not a long term solution to the problem.

In my configuration context file for a IMAP/AMQP connector I have a number of "routes in". Each one has an inbound IMAP adapter, a filter bean, a transformer bean, and and outbound AMQP adapter. There are some channels and some Rabbit Infrastructure also defined for each route in.

I would like to be able to start and stop, and restart the "routes in" independent of one another. I see the ClassPathXmlApplicationContext and I understand what you are saying in theory, The idea is to put the inbound adapter for each "route in" into its own separate child context using ClassPathApplicationContext.

The child context can be created or destroyed, which would be the start/stop mechanism. Am I understanding correctly? What would be the mechanism for sending start and stop commands? a std-in adapter?

I have some experience with Integration Engines in healthcare. The Open source Mirth is a java based one. These engines have similar functionality to SI when it comes to channels, adapters, transformers, filters, etc, but they add a UI. The UI has WSWYG editor for the configurations, and it has a management console (threads, start, stop). The engines also have logging and queuing of messages is also built in. Given AMQP provides a generic queuing prtocol and Rabbit provides persistent queues detached from the integration piece, it is probably superior to the tightly coupled queuing strategy deployed in other integration engines I have seen.

It seems SI could also be the generic integration engine if it had the UI and management piece found in other products on the market.

We are interested in exploring this option in further detail.

[Gary Russell]

You can send commands to any adapter using a <control-bus/>; send '@adapterName.stop()'.

You can also use JMX to access the Lifecycle methods; Spring has a convenience API making JMX much easier to use - there is an example here: http://forum.springsource.org/showth...007#post432007 but you would use the Lifecycle interface for the proxyInterface property.

You can then invoke Lifecycle interface methods (stop/start etc).

[ehrdoctors]

You can send commands to any adapter using a <control-bus/>; send '@adapterName.stop()'.

You can also use JMX to access the Lifecycle methods; Spring has a convenience API making JMX much easier to use - there is an example here: http://forum.springsource.org/showth...007#post432007 but you would use the Lifecycle interface for the proxyInterface property.

You can then invoke Lifecycle interface methods (stop/start etc).

I turned on JMX which was most of what I was looking for .

I am still looking into control bus. Whats the advantage over JMX? .
The control box docs are kind of limited on details here:
http://static.springsource.org/sprin...e/#control-bus

I am not sure how to add a control box (or 2) to my config....

[Gary Russell]

The monitoring example cited in that post shows how to use the control bus. Here's a snippet of the code from DefaultTwitterService...

	public void stopTwitterAdapter() {

		Message<String> operation = MessageBuilder.withPayload("@twitter.stop()").build();

		this.controlBusChannel.send(operation);

		if (this.dummyTwitter != null) {
			this.controlBusChannel.send(MessageBuilder.withPayload("@dummyTwitter.stop()").build());
		}
	}

As far as advantages Vs. JMX - it's just a different technique (sending messages Vs. direct API calls - just like any use of Spring Integration).

There's also an open Pull Request for that sample that shows yet another technique (using Spring Integration JMX adapters as an interface to the MBeanServer). https://github.com/SpringSource/spri...-samples/pulls