Announcement Announcement Module
Collapse
No announcement yet.
Spring integration and throttling, windowing approaches Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring integration and throttling, windowing approaches

    Hi,

    I'm a newbie to Spring Integration and have a few questions.

    [Thread handling]

    Does the same thread handle a request through a pipeline to an endpoint or gateway or are separate threads used at each channel? It would be simpler if the request uses the same thread as the message travels though the message bus.

    Throttling

    How would throttling be handled in SPring Integration? For instance if Spring integration was used to connect to an external system and that system could only handle at most 10 messages per second, what strategies or approaches could be used with Spring Integration to support this?


    Windowing

    Is windowing supported in Spring Integration? Windowing addresses the maximum number of connections to an endpoint or gateway. So If the external application could only handled 10 connections concurrently then the requests to a gateway would be blocked until a slot or window is available after which the slot is used for a new request.

    [JMX Control]

    Can each channel or the message bus as a whole be managed? The scenario I'm envisaging is that the message system may need to quiesce so any requests in the middle of processing could be temporarily curtailed. Any subsequent request could be queued until the system is re-enabled at a later time afterwhich the messages would be processed as normal? Is this a bespoke solution or something SI could handle out of the box?

    Thanks in advance for any guidance.

  • #2
    ad Thread handling:
    By default a single thread is used for the whole pipeline, if you want async hand-off you need to do something special (e.g. <dispatcher/> or <queue />)

    ad Throttling:
    You can specify pollers (with dedicated thread pools) to deal with a message source or queue channel. Also you can use dedicated thread pools in dispatchers. As a result you can precisely control the number of threads that operate on each source of messages

    ad Windowing:
    This is not implemented, in a sense that you can not limit the number of threads irrespective of the thread pool. I've found this is usually fine to implement yourself with a Semaphore though. I guess that supporting this from the framework is going to be tricky, as the requirements are quite specific usually.

    Comment

    Working...
    X