activemq - folder contents - archival

We have our routine archival process to archive our log files. Is it a best practice to archive - the contents under activemq as well? (IW_HOME/local/logs/activemq)

FYI - We ran into few issues with jms (on tsreports) and we cleared activemq folder and our services startup didnt recreate the folder. Should we as well consider recreating the directory with right permissions setup

Find more posts tagged with

Comments

Rick Poulin

The thing with this folder is that it contains more than just logs. Deleting/archiving the logs is fine, but in deleting the folder you also deleted the messaging queue -- services that depend on this (including TSReports and TSSearch) may have missed some event notifications.

So yes, you should definitely recreate the folder if a restart didn't. And if you still don't end up with a db.data file in this folder after another restart, check your server.log for error messages. TSReports/TSSearch probably won't work properly until this is fixed.

ts_tech

Thank you. It was only missing the folder. After manually creating the folder and restarting services the db flat files got created auto.

I just have this question:

Huge event db files consume lot of disk space after a week or so and causes lots of issues. Can we cleanup event files since they instantly update db for reports and services would get indexed as well.

Rick Poulin

Background info: ActiveMQ is an implementation of the Java Messaging System (JMS) which follows the Publisher/Subscriber design pattern. As the "publisher", ActiveMQ doesn't know how many subscribers are out there, so it doesn't "know" when the message has been delivered to all subscribers. However, as part of its "contract", it's only required to hold messages in the queue for a certain amount of time. I haven't done the research, but ActiveMQ must have a configurable TTL somewhere, which would be the optimal way to restrict the size of the message queue (the db.data file).

Also, it appears to me as though a restart of the system may not "remember" to clear messages in the queue pre-reboot, so it sometimes needs deleting manually.

As a benchmark though, what kind of numbers are we talking about? I have a production system with an average 30 concurrent users for 8hrs/day, and my db.data file stays between 50MB and 1GB.