Announcement Announcement Module
No announcement yet.
Possible to cap thread utilization at the dispatcher level? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Possible to cap thread utilization at the dispatcher level?

    I have messages that I want to dispatch in parallel via a task executer, but I don't want more than a few in flight at the same time for the sake of other systems involved. I can control the level of parallelism by setting an upper bound on the thread pool, but is there any way (or would it make sense) to set the limit at the dispatcher level?

    I don't want the pool to just sit there tying up threads when no messages are coming through. I could set the pool size to a range "0-n", but then when the pool was idle, there would be overhead of starting a thread when a message did come in. It seems like it would be more efficient to have a larger pool with reasonable bounds (a minimum > 0) and share it among several channels. There might be some contention if the system was pegged across the board, but in general, it would amortize the thread management costs across several flows. However, I don't want the dispatchers of those channels to be able to use all the threads at once. I want them to throttle themselves channel-by-channel to some local maximum.

    Or is the Spring TaskExecuter smart enough under the hood that I shouldn't worry and just allocate a specifically-sized threadPool for every channel that needs to limit the number of threads?

    <task:executor id="threadPool" pool-size="5" />
    <int:channel id="someChannel">
    	<int:dispatcher task-executor="threadPool" />

  • #2
    It would be difficult to partition the thread pool across multiple dispatchers.

    If you are worried about idle threads, use a range in the pool size, e.g. "1-5", or even "0-5"; then, threads will be created on demand up to the max and they will decay when idle for more than keep-alive seconds.

    The keep alive defaults to 60 seconds.

    The Spring ThreadPoolTaskExecutor delegates to a JVM ThreadPoolExecutor. Take a look at the javadocs for each for more information.


    • #3
      I wasn't thinking so much of partitioning as having each dispatcher maintain a count of how many threads it was using and check that before allocating another one. It doesn't sound like a big deal if there isn't support for it though. It's just that task executers have to be declared separately (instead of nested) which implies sharing which made me wonder if there wasn't a local option I was missing for keeping my dispatcher from running amok with a larger pool.