On 23 February 2016 at 10:53, Frizz <frizzthe...@googlemail.com> wrote: > On Mon, Feb 22, 2016 at 5:32 PM, Timothy Bish <tabish...@gmail.com> wrote: > >> ... and for the case of many senders you might >> indeed see a performance drop since you are now reducing the number of >> connections to what looks like eight, so all those producers are now >> restricted to eight connection to shovel all their data through. >> > > But without a PooledConnection, the number of connections would be = 1, no? > > More details: My test application creates 250 MessageProducers, each one > running in its own thread. Connection/Session/MessageProducer are only > created once - and never closed. Messages are sent in a loop per thread, as > fast as possible. > > I don't see why a PooledConnectionFactory (connections > 1) does not result > in an increased number of messages/second - compared to a > non-PooledConnectionFactory (connections == 1).
The pooled factory enables re-use of underlying connections when applications/frameworks repeatedly create+close connection objects over time, which is inefficient because creating the underlying connection is relatively expensive. If you create connection objects and keep them open forever the pool can't actually help as the problem behaviour it caters for isnt actually occurring. I can't say for sure from your summarised description and partial code, but it seems like you may only ever create 1 connection object with the factory. If so, explicitly creating multiple connections and splitting your producers across them would likely improve performance.
