the broker maintains some per connection state, connectionId and clientId to enforce the single clientId in use jms requirement, this can be an area of thread contention on heavily loaded systems that open/close many connections. So even for vm connections (where there is no tcp socket) there will be a pooling benefit.
But the age old answer is to 'ask the computer' for your particular use case. On 22 April 2014 17:07, Paul Gale <paul.n.g...@gmail.com> wrote: > Hi, > > Connection pooling is generally recommended as a good thing. However, is > pooling of VM protocol (vm://) based connections > required/advised/nonsensical when communicating between Camel and a broker > in which it is embedded? Please explain. > > From what I have read the VM protocol bypasses the TCP stack, therefore I'm > inclined to think it's not necessary. Regardless, that doesn't necessarily > imply that there isn't a cost associated with creating and destroying these > vm:// connections such that it wouldn't benefit from pooling. > > Thanks, > Paul -- http://redhat.com http://blog.garytully.com
