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. Here's a little bit of background info... A
hydrologist takes 10 different actions on a particular river to issue a
river forecast. Several hydrologists work concurrently on different
rivers. The goal is to show a status of where each of 30 rivers are in
the forecast process at any one time. This prevents one hydrologist
from beginning work on a river forecast that another hydrologist is
already working on. A JMS message is sent to AMQ each time one of the
actions is taken on a river. 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.
Each hydrologist runs an instance of my consumer to see the progress of
all the other hydrologists working on the river forecasts. The
subscribers remain alive in ActiveMQ. 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). 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
things!
Does the log show anything? I'm wondering if the kahadb cleanup is
kicking
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 |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Transport:
tcp:///165.92.xx.xx:34201
This message means very little to me, although the 513 increments with
each log entry. Is the 59695 number the process ID? Or what is the
34201 number? What's the 0:1:1:1: mean? 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... I could learn more
if the log reported what the repeated message was, but it doesn't,
unfortunately. Any ideas?
A grep of "cleanup" on the log files shows a handful of the following
messages:
INFO | Slow KahaDB access: cleanup took xxx
where xxx ranges anywhere from 500 to 9000. Are these
seconds, or milliseconds? And are these numbers typical or
astronomical?
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.
Mark
begin:vcard
fn:Mark Fenbers
n:Fenbers;Mark
org:National Weather Service;Ohio River Forecast Center
adr:;;1901 South OH-134;Wilmington;OH;45177-1908;USA
email;internet:mark.fenb...@noaa.gov
title:Sr. HAS Meteorologist
tel;work:937-383-0430
tel;fax:937-383-0033
note:"HAS" is an acronym for Hydrometeorological Analysis and Support
x-mozilla-html:TRUE
url:http://weather.gov/ohrfc
version:2.1
end:vcard
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-slowness-every-30-days-tp3080715p3082497.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
