Restart time with large number of persisted messages
We are in the process of evaluating the Sun Message Queue and have noticed that if we send a large number of messages to a queue and then shut the server down, the restart takes a very long time. In the console after the restart, MQ appears to be loading all the messages back into memory. I finally get the message:
[10/Nov/2006:16:07:41 EST] [B1153]: Loading of destination publish_request [Queue] in process, 159042 of 159042 messages loaded, 100% complete
but even at this point a client cannot connect to the queue. If I check the database server, MQ is generating massive amounts of queries. For the above 159,042 messages it took 20 minutes before the server was up and able to process any more messages on this queue. Is this normal and to be expected?
Is MQ really storing all these messages in memory? We have a suite of applications where the failure or downtime in one application could cause a large volume (1,000,000) messages of around 1KB in size to bank up in a queue. Can MQ realistically handle these kinds of volumes? What if I have to restart MQ with 1,000,000 messages in the queue - on the above timings the restart will take in the order of hours.
Any advice or experiences appreciated.
David
[1253 byte] By [
davidh] at [2007-11-26 11:23:57]
# 1
Hi!, what kind of file persistence are you using?, what version are you using?, can you publish the content of your var/instances/imqbroker/props/config.properties file?.
In some cases we have up to 200.000 messages in the queue system, then restart the broker, and doesn't take that amount of time you say.... mmmm, maybe is the kind of persistance you are using.
bye!
# 2
Thanks BuZMan. We are using Open Message Queue 4.0 version 4 (the community version of Sun Message Queue). We are not using file persistence, but JDBC persistence to a MySQL database. I'm at home at the moment, so I can't get my hands on the config, but the only things I have changed are for the JDBC persistence (as described in the admin guide) and to change the defaults for auto created queues to make most options "unlimited".
# 3
Our config.properties file is as follows:
imq.instanceconfig.version=300
imq.autocreate.reaptime=
imq.autocreate.queue=true
imq.autocreate.queue.maxNumActiveConsumers=-1
imq.autocreate.destination.maxBytesPerMsg=-1
imq.autocreate.destination.maxNumMsgs=-1
imq.autocreate.destination.maxNumProducers=-1
imq.autocreate.destination.maxTotalMsgBytes=-1
imq.persist.store=jdbc
imq.persist.jdbc.dbVendor=mysql
imq.persist.jdbc.brokerid=BROKER0
imq.persist.jdbc.mysql.driver=com.mysql.jdbc.Driver
imq.persist.jdbc.mysql.opendburl=jdbc\:mysql\://161.117.20.177\:3306/mq1
imq.persist.jdbc.mysql.createdburl=jdbc\:mysql\://161.117.20.177\:3306/mq1
imq.persist.jdbc.mysql.user=mq1
imq.persist.jdbc.mysql.password=password
imq.persist.jdbc.mysql.needpassword=true
# 4
Just re-tested using file based persistence, and with 160,000 persisted messages, the server takes 60 seconds to start up, so quite a bit faster than the 20 minutes with JDBC persistence.
I also increased the number of messages to 300,000 and the startup takes 45 minutes with JDBC and 12 minutes with file based.
