Configuring receive-timeout and interval-trigger in a poller

Hi -- I am in the process of tuning our SI-based application, and one of the things I'm looking at is to set reasonable values for receive-timeout and interval-trigger for each poller.

I see that the reference manual offers some guidance in this area, as shown below. I think this is basically what we need -- we have internal queue-based channels that are waiting for messages to arrive for processing. When new messages arrive, we want to minimize the delay before these messages start to get processed, and if messages cannot be processed quickly enough then we expect them to build up on the internal queue so that upstream processing can continue without blocking.

However, I have a couple of questions about this:

1. When you have a long receive timeout, why bother with an interval trigger at all? Assuming that you have a dedicated thread pool for processing messages off the queue channel, why not just call receive() again immediately? Would it be a bad idea to set the interval to zero?

2. What will happen if, for example, I have a task executor with 10 threads configured to poll for messages on the channel, and a load of messages suddenly arrive on the queue? Ideally, processing of these messages should be balanced among the threads in the pool, but if maxMessagesPerPoll is set to the default (unbounded), does this mean that one thread will grab all the messages while the others remain idle? Is this a reason to override the default maxMessagesPerPoll with a sensible batch size?

Any help would be much appreciated.

Thanks
-Matt

Quote:

---

As mentioned in the background section for Polling Consumers above, you can also configure a Polling Consumer in such a way as to emulate event-driven behavior. With a long receive-timeout and a short interval-trigger, you can ensure a very timely reaction to arriving messages even on a polled message source. Note that this will only apply to sources that have a blocking wait call with a timeout. For example, the File poller does not block, each receive() call returns immediately and either contains new files or not. Therefore, even if a poller contains a long receive-timeout, that value would never be usable in such a scenario. On the other hand when using Spring Integration's own queue-based channels, the timeout value does have a chance to participate. The following example demonstrates how a Polling Consumer will receive Messages nearly instantaneously.

<service-activator input-channel="someQueueChannel"
output-channel="output">
<poller receive-timeout="30000">
<interval-trigger interval="10"/>
</poller>
</service-activator>

---

Can anyone advise on the above?

Thanks
-Matt