Thanks again for your help.
On Fri, Jul 27, 2012 at 3:42 AM, Dejan Bosanac wrote:
> Yeah, i think that's about right.
>
> Regards
> --
> Dejan Bosanac
> Senior Software Engineer | FuseSource Corp.
> dej...@fusesource.com | fusesource.com
> skype: dejan.bosanac | twitter: @dejanb
> blog: http://w
Yeah, i think that's about right.
Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dej...@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Fri, Jul 27, 2012 at 12:26 P
Dejan - thanks for the detailed explanation. Based on this, I went back and
figured the folly.. I misread the maximumActive to mean the connection
limit rather than the session-count per connection. My bad. I am upping the
maxConnections now. Also, based on your tweaks in 5.7 (thanks for the
excell
Hi,
the pooled connection factory will try to create maxConnections
(default 1) and then reuse them from the pool. The process of
connections creating (failover and randomize) is not related to the
pool at all. With failover in case, the client (and the pool) will not
even see host1 connection pro
It seems like with a failover transport configuration
(failover:(nio:host1:port1,nio:host2:port2)?randomize=false) and a
PooledConnectionFactory, the client-side still tries to create a new
connection per thread instead of fetching from the pool of connections.
With 'randomize' flag turned off, I w
