activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira Paz <>
Subject Database access and prefetch considerations
Date Thu, 30 Oct 2008 13:30:27 GMT
Hi, activemq guys.

We are suffering some bad service times on a production system embedding 
ActiveMQ as message broker. We are not sure whether the problem is the 
broker itself, but I would like to get some insights in the broker 
internals, to be able to understand the situation better.

We are using an activemq 4.1 release (we are not allowed to upgrade it) 
, with pure JDBC persistence. We are using only queues and persistent 

The first concern is about database access. Even when the number of 
messages in queues are high, we are observing no growth in the number of 
active database connections. Furthermore, it seems that only a thread 
per connection is responsible of fetching and deleting messages in the 
persistence.  Given the fact that we have 30 consumers on a given queue, 
sharing the same connection, does this mean that a single thread is 
managing all the persistence needs? If true, wouldn't it be a potential 
bottleneck, avoiding us to improve the performance adding more consumers?

The second question is about the consumer prefetch. We did disable it in 
the past, trying to avoid situations where messages got stuck in queues, 
due to slow consumption of previous messages, producing unexpected and 
apparently random delays in the consumption of some messages.

We wonder if prefetch could in some way lighten the load on the database 
side. We guess that perhaps messages prefetched for a given queue are 
kept in memory, avoiding the need to read them from the database. On the 
other side, does prefetch activate a particular revover strategy for 
database message restoring, or are they fetched in a one by one basis?

This also triggers the question of mesage caching. Even when prefetch is 
disabled, is there any strategy, perhaps configurable, to cache messages 
in memory? We are suspecting that when queue message counts goes higher, 
performance goes down. Could this be related with cache issues, i.e. LRU 
strategies keeping messages not to be delivered before older ones 
already out of memory?

Please, don't hesitate into sharing any related theory with me. I hope 
we can fix our performace problems with your help.

Best regards.


View raw message