activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fenbers <>
Subject Re: ActiveMQ slowness every 30 days
Date Fri, 10 Dec 2010 18:34:40 GMT


James Green-3 [via ActiveMQ] wrote:
 Why do you need to redeliver topic messages? To me you
are bending a message
queue to react like a database. 

I appreciate the reply.&nbsp; Here's a little bit of background info...&nbsp; A
hydrologist takes 10 different actions on a particular river to issue a
river forecast.&nbsp; Several hydrologists work concurrently on different
rivers.&nbsp; The goal is to show a status of where each of 30 rivers are in
the forecast process at any one time.&nbsp; This prevents one hydrologist
from beginning work on a river forecast that another hydrologist is
already working on.&nbsp; A JMS message is sent to AMQ each time one of the
actions is taken on a river.&nbsp; So my AMQ client app consumes these
messages and displays the status of these actions in a GUI. 

If my client app (consumer) is restarted or is started late n the
process, then it needs to correctly redisplay the status of all 30
rivers -- even those that occurred prior to the launch of the latest
instance, thus redelivering the message causes my consumer to correctly
redisplay message that were sent prior to the launch of the consumer.&nbsp;
Each hydrologist runs an instance of my consumer to see the progress of
all the other hydrologists working on the river forecasts.&nbsp; The
subscribers remain alive in ActiveMQ.&nbsp; This is why my consumer can be
relaunched and be able to get all of the back messages. 

This approach works very well (except for the bogging down of this
consumer and producers after about 30 days).&nbsp; If there is a smarter way
to have my consumer redisplay actions taken prior to its launch, then
please share it with me because I'm eager to learn of better ways to do

Does the log show anything? I'm wondering if the kahadb cleanup is
in and is eventually going over some threshold causing the slowdown.

The log shows lots of stuff (33MB in about 6 hours) but most of it
comprises of this error: 
YYYY-MM-DD HH:MM:SS,ddd | WARN | Duplicate message add attempt
rejected. Message id: somehostname-59695-1291947282050-0:1:1:1:513 | | ActiveMQ Transport:

This message means very little to me, although the 513 increments with
each log entry.&nbsp; Is the 59695 number the process ID?&nbsp; Or what is the
34201 number?&nbsp; What's the 0:1:1:1: mean?&nbsp; The text would seem to imply
that I'm trying to submit the same message repeatedly to the broker,
but I haven't found where I could be doing this...&nbsp; I could learn more
if the log reported what the repeated message was, but it doesn't,
unfortunately.&nbsp; Any ideas? 

A grep of "cleanup" on the log files shows a handful of the following

INFO | Slow KahaDB access: cleanup took xxx 

where xxx ranges anywhere from 500 to 9000.&nbsp; Are these
seconds, or milliseconds?&nbsp; And are these numbers typical or

I should also mention that messages sent from the producers are set to
expire at less than 12 from the current time, so it's not like message
are kept for long periods of time. 


fn:Mark Fenbers
org:National Weather Service;Ohio River Forecast Center
adr:;;1901 South OH-134;Wilmington;OH;45177-1908;USA
title:Sr. HAS Meteorologist
note:"HAS" is an acronym for Hydrometeorological Analysis and Support

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message