Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add configuration option to control creation of new consumers in DefaultMessageListenerContainer [SPR-7189] #11849

Closed
spring-projects-issues opened this issue May 11, 2010 · 2 comments
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

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

@spring-projects-issues
Copy link
Collaborator Author

Thomas Risberg commented

Patch supplied by Bruce

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

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.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants