You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a customer requesting that an "idleTaskExecutionLimit" property be exposed for tuning purposes. Instead of comparing against a hard coded zero value, this property will allow consumers to be created in a more aggressive manner. Bruce has looked at this and created a patch against 3.0 trunk. He commented: "I see no harm in allowing this, especially since the customer's use case has proven that doing so improves his ability to consume messages faster."
I've added this for 3.0.3, based on Bruce's patch. The semantics of the idleConsumerLimit value are a bit different though: It's the maximum number of consumers that are allowed to be idle at any time - but interpreted strictly now. Since a newly scheduled invoker is likely to be idle initially, the comparison goes like getIdleInvokerCount() < getIdleConsumerLimit() when deciding whether to start a new invoker. Consequently, idleConsumerLimit's default is 1 now (not 0): It needs to be raised beyond 1 for an actual effect.
Thomas Risberg opened SPR-7189 and commented
We have a customer requesting that an "idleTaskExecutionLimit" property be exposed for tuning purposes. Instead of comparing against a hard coded zero value, this property will allow consumers to be created in a more aggressive manner. Bruce has looked at this and created a patch against 3.0 trunk. He commented: "I see no harm in allowing this, especially since the customer's use case has proven that doing so improves his ability to consume messages faster."
-Thomas
Affects: 2.5.6, 3.0.2
Attachments:
Referenced from: commits ad5c7ae
The text was updated successfully, but these errors were encountered: