On 27/03/2008, James Strachan <[EMAIL PROTECTED]> wrote:
> On 27/03/2008, DominicTulley <[EMAIL PROTECTED]> wrote:
> >
>
> > I would say "yes" to the similar output but I don't have a proper machine
> > with lsof on it!
> > I used ubuntu on a virtual machine to check my suspicion but I couldn't
> get
> > AMQ running on it so I couldn't run proper tests.
> >
> > you're right that netstat gives you lots of guff but just doing netstat |
> > grep 61616 should do the trick for starters..
>
>
> Aha! I can now reproduce it :)
>
> I'm delving into the debug logs now... I've a hunch its the
> JmsTemplate sending messages that is the culprit...
Yeah - the defaults don't use a pooled connection factory; so the
sending part of the test tends to create a connection/session/producer
for each message thats being sent.
i.e. the cacheLevelName=CACHE_CONSUMER does indeed only create a
single connection - and caches/reuses sessions/consumers.
However this route in the load test...
<route>
<from uri="dataset:myDataSet"/>
<to uri="activemq:example.A"/>
</route>
just sends to JMS without any inbound JMS message; so this bypasses
all the caching stuff in the cacheLevelName as under the covers its
using a JmsTemplate with a default ActiveMQConnectionFactory - so no
pooling.
I'm just in the process of patching activemq-core so that it'll use a
pooled connection factory by default to avoid this issue.
However for now you can avoid this by setting the connectionFactory on
the ActiveMQComponent to be either Spring's SingleConnectionFactory or
the PooledConnectionFactory from ActiveMQ.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
