On Wed, Apr 7, 2010 at 10:15 PM, mattcodes <m...@mattfreeman.co.uk> wrote:
>
> When you say overhead are you talking about ongoing on startup, I was
> thinking of initializing the pool on startup, so bring up minsize of pools
> say 30 producer(1:1)session(1:1)connection, so when requested its all ready
> to go, use it, and release it back to the pool for the next incoming web
> request that has to send a message to the backend queue.
Not only is the overhead of creating each object large, but creating a
connection and a session per producer is just simply unnecessary. It
winds up being a waste of resources that burden the broker
unnecessarily.
> If I go the route of having 1 connection, how many session would you have
> per connection? I guess start with the connection as singelton, then a pool
> of sessions? Eventually scale it to connection per 20 sessions? Or something
> like that?
A single connection can support many sessions. As I said before, the
best approach is use a pooling connection factory. That way all of
this is handled for you and all you need to do is create and cache the
producers.
Bruce
--
perl -e 'print
unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
