This improvement relates to #5782.
While the receive-timeout makes a sensible setup easier I feel strongly that a default of -1 (dont block on receive) should be set for the inbound channel adapter. Two main reasons for this. Firstly I don't think a component designed for polling should block by default since this will confuse people. Most people would expect the below to check JMS daily at midnight but in fact we block until a message is received any time of day. This means the behaviour is very similar to the message driven JMS equivalent.
<jms:in ...>
\
</jms:in>
Secondly where this default behaviour is not understood the application will behave in a non intuitive way. For example an application that should be polling 100 queues every twenty seconds using ten threads will in fact block up all available threads on the first ten queues and will then be unable to execute other scheduled tasks.
Jonas Partner opened INT-1795 and commented
This improvement relates to #5782. While the receive-timeout makes a sensible setup easier I feel strongly that a default of -1 (dont block on receive) should be set for the inbound channel adapter. Two main reasons for this. Firstly I don't think a component designed for polling should block by default since this will confuse people. Most people would expect the below to check JMS daily at midnight but in fact we block until a message is received any time of day. This means the behaviour is very similar to the message driven JMS equivalent.
<jms:in ...> \
</jms:in>
Secondly where this default behaviour is not understood the application will behave in a non intuitive way. For example an application that should be polling 100 queues every twenty seconds using ten threads will in fact block up all available threads on the first ten queues and will then be unable to execute other scheduled tasks.
Affects: 2.0.1, 2.0.2