title: When does a single JMS connection with multiple producing sessions start becoming a bottleneck?
body: <p>I've recently read a lot about best practices with JMS, Spring (and TIBCO EMS) around connections, sessions, consumers &amp; producers</p>
  
  <p>When working within the Spring world, the prevailing wisdom seems  to be</p>
  
  <ul>
  <li>for <strong>consuming/incoming flows</strong> - to use an <code>AbstractMessageListenerContainer</code> with a number of consumers/threads.</li>
  <li>for <strong>producing/publishing flows</strong> - to use a <code>CachingConnectionFactory</code> underneath a <code>JmsTemplate</code> to maintain a single connection to the broker and then cache sessions and producers.</li>
  </ul>
  
  <p>For producing/publishing, this is what my (largeish) server application is now doing, where previously it was creating a new connection/session/producer for every single message it was publishing (bad!) due to use of the raw connection factory under <code>JmsTemplate</code>. The old behaviour would sometimes lead to 1,000s of connections being created and closed on the broker in a short period of time in high peak periods and even hitting socket/file handle limits as a result.</p>
  
  <p>However, when switching to this model I am having trouble understanding what the performance limitations/considerations are with the use of a single TCP connection to the broker. I understand that the JMS provider is expected to ensure it can be used in the multi-threaded way etc - but from a practical perspective</p>
  
  <ul>
  <li>it's just a single TCP connection</li>
  <li>the JMS provider to some degree needs to co-ordinate writes down the pipe so they don't end up an interleaved jumble, even if it has some chunking in its internal protocol</li>
  <li>surely this involves some contention between threads/sessions using the single connection</li>
  <li>with certain network semantics (high latency to broker? unstable throughput?) surely a single connection will not be ideal?</li>
  </ul>
  
  <p>On the assumption that I'm somewhat on the right track</p>
  
  <ul>
  <li>Am I off base here and misunderstanding how the underlying connections work and are shared by a JMS provider?</li>
  <li>is any contention a problem mitigated by having more connections or does it just move the contention to the broker?</li>
  <li>Does anyone have any practical experience of hitting such a limit they could share? Either with particular message or network throughput, or even caused by # of threads/sessions sharing a connection in parallel</li>
  <li>Should one be concerned in a single-connection scenario about sessions that write very large messages blocking other sessions that write small messages?</li>
  </ul>
  
  <p>Would appreciate any thoughts or pointers to more reading on the subject or experience even with other brokers.</p>