Throttle Support

[dashout]

Hi,

i was given the task to evaluate 'Spring Integration'. :? I had a question on the Enterprise Integration Pattern support of SI.

Isn't Throttler Pattern part of EIP?
I could not find any support for throttling in the SI, probably is this something Message-Endpoint or Channel-Adapter should take care of and is out-of-scope for SI?

Can someone plz explain if Throttling is possible using SI (apart from the 'Poller' of Channel-Adapter).

To add into context, the requirement is like, we need to notify users by SMS. the enterprise smsc cannot be loaded by more than 5 requests from an application in 1 second.

[Mark Fisher]

Throttling is supported by Spring Integration through the use of Spring's TaskExecutor abstraction. I'm not sure what you meant by "apart from the 'Poller' of Channel-Adapter" (can you elaborate?)... but that is one side of the picture; the other is a queueing channel with a limited capacity.

For example, if component A is sending requests to a channel, and component B is polling that channel for Messages, you can control the following parameters: 1) rate at which B polls the channel, 2) taskExecutor settings for B's poller (e.g. thread pool core/max size), and 3) capacity of the channel's queue. When component A sends more requests than B can handle, the Messages will be buffered in the queue. If A sends even more requests than the *channel* can handle (exceeds its queue-capacity), the channel.send() calls will block until the designated timeout or until space is available on the queue (whichever occurs first). Thus, component A or any inbound Channel Adapter can decide how to handle that situation (block, propagate exception, drop messages, etc).

I hope that clears things up a bit, but please let me know if I am not addressing your question. In any case, I'm interested in more details about your use-case. It sounds like you are talking about calls *from* SI to the backend system?

[ttruong]

Throttling the system?! I am rather concerned with the performance using SI! My colleague also mentioned that there are a lot(!) of threads started and we will rather sooner than later have some performance issues. I think this will be one of our next big investigation (as soon as we have more integration data and workflows).

Do you have any results on performance?

Thanks Tai

[Mark Fisher]

All tasks executing in Spring Integration are submitted through Spring's TaskExecutor abstraction, and the TaskExecutor instances are fully configurable. This means that you have complete control over how many threads are being used, how those threads are managed, etc. Furthermore, you can provide different taskExecutor references for different components (e.g. to control competing consumers with different rates, different throughput expectations, and so on). All of these configuration options will be documented for the 1.0 final release in much more detail than they are currently. In general though, you should not be concerned with any performance issues because you are using Spring Integration. We have been very focused on ensuring the absolute minimal overhead. Once the configuration options are understood, you should be able to control the scheduling and thread management in order to optimize CPU usage and achieve scalability.

[iwein]

Mark, correct me if I'm wrong, but I think you introduced the improvements regarding thread management after M6, people working with M6 might see a worrying number of threads.