title: What does a high Spring JMS DefaultMessageListenerContainer.receiveTimeout parameter mean?
body: <p>I am getting into a project that implemented an IBM MQ listening Spring JMS application and I have troubles understanding the "receiveTimeout" in the DefaultMessageListenerContainer.</p>
  
  <p>Compared to sources from the internet I think my project is kind of special that we are using a really high value of 30 seconds for the "receiveTimeout" parameter and I don't know what this actually means.</p>
  
  <p>I have tried to figure out the meaning of the "receiveTimeout" parameter and I will give you my understanding below after the Spring configuration. </p>
  
  <p>FYI: We are reading/processing many many messages from a queue that are all really small (about 100kb).</p>
  
  <p>This is the spring configuration that we are using:</p>
  
  <pre><code>&lt;bean id="msgListenerContainer"
          class="org.springframework.jms.listener.DefaultMessageListenerContainer"
          p:connectionFactory-ref="mqConnectionFactory" 
          p:messageListener-ref="myMessageListener" p:sessionTransacted="true"
          p:concurrentConsumers="1" p:maxConcurrentConsumers="20"
          p:receiveTimeout="30000" p:idleTaskExecutionLimit="10"
          p:idleConsumerLimit="5" /&gt;
  </code></pre>
  
  <p>If anyone is whondering about the different parameters here is what I have gathered throughout the internet:</p>
  
  <blockquote>
    <p>The <strong>idleConsumerLimit</strong> property is used to specify the the maximum
    number of consumers that are allowed to be idle at a given time. 
    Increasing this limit causes invokers to be created more aggressively.
    This can be useful to ramp up the number of consumers faster.</p>
    
    <p><strong>idleTaskExecutionLimit</strong>: The limit for the number of allowed idle
    executions of a receive task. The default is 1 causing idle resources
    to be closed early once a task does not receive a message. 
    idleTaskExecutionLimit property is set to 10 to allow tasks to execute
    10 times instead of the default value of 1.</p>
    
    <p><strong>receiveTimeout</strong> property is set to 30 seconds to tell the DMLC's
    receive operation to poll for message for 30 seconds instead of the
    default one second.</p>
  </blockquote>
  
  <p>And here is my understanding:</p>
  
  <blockquote>
    <p>So this means: If there is a heavy load Spring JMS will start up to 20
    consumers (maxConcurrentConsumers) and as soon as the load goes down, these consumers will 
    continue to read messages for 30 seconds (receiveTimeout) before closing or going idle.
    So after that 5 consumers (idleConsumerLimit) will still idle for 10 seconds (?) (idleTaskExecutionLimit) before
    closing down.</p>
  </blockquote>
  
  <p>Please correct me if I am wrong.</p>
  
  <p>One internet page stated that my consumers will only read a message every 30 seconds but I do not think that this is the right interpretation of "receiveTimeout". </p>
  
  <p>One issue that we currently have is that we have many many GET's reading from the MQ but not actually getting a message - Like we can have 60'000 GET's that actually are able to read a message compared to 2'100'000 GET's that happend but did NOT read a message.</p>
  
  <p>I am thankful for any help in understanding the behaviour of Spring JMS better.</p>