Justin- JMS connections act and behave very different from JDBC connections. Just like a long query can block other apps trying to access the connection on a shared JDBC connection, a slow consumer can impact others trying to access it as well. You can do multiple sessions on top of a single connection, but it can get hairy and I don’t get the sense that the intention was to support connection pooling, but rather allow for a single program to do all its producing and consuming over a single connection— not several programs sharing a single connection.
Separate connections per consumer is always a safe starting point. Pre-tuning for shared JMS connections, usually results in de-tuning. I think you’ll find single connection per consumer will meet your performance needs. If you absolutely feel like you must share sessions on top of a single connection, reduce prefetch=“1”, ensure your memoryLimit is well above the default “1 mb”, use NIO on the transportConnector, optimizedDispatch=“true” and dedicatedTaskRunner=“false”. -Matt On Sep 8, 2014, at 6:25 AM, James Black <be_st...@yahoo.co.uk> wrote: > Hi Matt, > > we don't use JmsTemplate in this particular bit of code. > > I have done some testing this morning and the problem seems to be contention > with the shared connection. The Spring DMLC is configured to cache at > Connection, Session and Consumer level. If caching is enabled at all > (connection+) then it uses a shared single connection. I can verify this by > monitoring ActiveMq through Jmx. > > So if I have a DMLC with 20 consumer threads, all sharing the same > connection it is slow, but at low throughput you would not notice. > > If I create 20 separate DMLCs all with a single thread and all with > different connections, then the performance is great in comparison! > > Not sure why this would be as I believed that it is normal to share the > connection for JMS unlike JDBC and I would of assumed that ActiveMQ is > optimised for that case? > > Thanks, > > Justin > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Consumer-performance-problem-with-Tx-tp4685226p4685365.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
