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.
James
On 10 December 2010 18:34, fenbers <mark.fenb...@noaa.gov> 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. 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<email%3binternet%3amark.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.
>
