activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Green <>
Subject Re: ActiveMQ slowness every 30 days
Date Fri, 10 Dec 2010 21:12:53 GMT
I would call this a mis-use of the technology. What you are trying to do is
to restore state across application restarts.

By all means have a client component listening for messages ("progress
updates" if you like). However, it should update a database that your GUI
should reflect.

I can't comment on the rest as I don't have the necessary experience -
though what you are seeing is likely the result of your perhaps
unanticipated use of AMQ.


On 10 December 2010 18:34, fenbers <> wrote:

> 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
> 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 |
> | ActiveMQ Transport:
> tcp:///165.92.xx.xx:34201
> 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
> messages:
> 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
> 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;<>
> 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:
> version:2.1
> end:vcard
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

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