best way to both prevent starvation and ensure minimal throughput within a Spring JMS listener pool

Question

I have a JMS listener pool:

<jms:listener-container connection-factory="jmsConnectionFactory" 
 acknowledge="client" concurrency="10">
    <jms:listener destination="foo1" ref="ref1"/>
    <jms:listener destination="foo2" ref="ref2"/>
    <jms:listener destination="foo3" ref="ref3"/>
    <jms:listener destination="foo4" ref="ref4"/>  // etc...
</jms:listener-container>

I'm looking for a way to ensure that some of my message types don't starve or block out all the others. Example: I would prefer to have at least M but no more than N percent of my pool be dedicated to processing foo1 messages, even though such processing may erratically stall.

Presently, if I let this happen, then all 10 threads in my pool will end up dedicated to foo1 messages. foo{2-4} messages will have to wait. I can prevent such starvation by enforcing timeouts on my foo1 listener, but then I fail my throughput goals.

Is there some easy configuration-based way of achieving this? Can I have two JMS listener pools running at once?

Or is my safest bet just to set up two entirely different server fleets, one dedicated to foo1 messages, the other to foo2-4?

Ideally, I would like to do something like the following. But "concurrency" isn't an attribute of jms:listener, just jms:listener-container:

<jms:listener-container connection-factory="jmsConnectionFactory" 
 acknowledge="client" concurrency="25">
    <jms:listener destination="foo1" ref="ref1" concurrency="10" /> // ensure higher throughput
    <jms:listener destination="foo2" ref="ref2" concurrency="5" />  // don't let foo1 starve me...
    <jms:listener destination="foo3" ref="ref3" concurrency="5" />  // don't let foo1 starve me...
    <jms:listener destination="foo4" ref="ref4" concurrency="5" />  // etc...
</jms:listener-container>

Thanks.

Gary Russell Gary Russell · Accepted Answer · 2012-12-14T02:16:10

Understand that the namespace configuration is just a convenience to simplify configuration. Each <listener/> element gets its own listener container and "inherits" the attributes from the <listener-container/> element.

So, in your first example, the concurrency="10" is not shared across all the listeners; each <listener/> gets a concurrency of 10.

You can achieve your second example by declaring two <listener-container/> elements, one with concurrency 10 and one with 5. Then declare each listener in the appropriate container element.

Hope that helps.

best way to both prevent starvation and ensure minimal throughput within a Spring JMS listener pool

1 Answers