Hi all, I am seeing some odd behaviour in a 5.14.5 ActiveMQ instance that used mKahaDB - I have not seen this sort of thing before, and was wondering if anyone could shed some light on it.
The directory listing below is for one fragment of an mKahaDB installation. It is configured for 8mb journal files, and accepts messages for a single queue only. Messages are 60-80kb in size. What I am seeing is a very large index (db.data), often far in excess of the total size of the journals. The following is not uncommon to what is happening in other mKahaDB fragments: -rw-r--r-- 1 activemq activemq 8388608 Jun 19 18:07 db-5985.log -rw-r--r-- 1 activemq activemq 8388608 Jun 19 18:09 db-5986.log -rw-r--r-- 1 activemq activemq 8388608 Jun 19 18:11 db-5987.log -rw-r--r-- 1 activemq activemq 8388608 Jun 19 18:14 db-5988.log -rw-r--r-- 1 activemq activemq 8388608 Jun 19 18:16 db-5989.log *-rw-r--r-- 1 activemq activemq 99401 Jun 20 00:13 db-5991.log-rw-r--r-- 1 activemq activemq 8388608 Jun 20 01:00 db-5990.log-rw-r--r-- 1 activemq activemq 728 Jun 20 01:03 db-5993.log-rw-r--r-- 1 activemq activemq 8388608 Jun 20 09:32 db-5992.log*-rw-r--r-- 1 activemq activemq 3291400 Jun 20 17:54 db.redo *-rw-r--r-- 1 activemq activemq 79540224 Jun 20 17:54 db.data* -rw-r--r-- 1 activemq activemq 8388608 Jun 20 17:54 db-5994.log Points of note: - Total journal size is 67.2mb, indexes are 79.5mb. - db-5990.log is written after db-5991.log, db-5992.log after db-5993.log (non-sequential writes) The thing that brought this to my attention was that storePercentUsage was hitting 100% for a multi-GB max store size. I suspect this is due to some crusty data in the indexes themselves - after 5993 x 8mb journals, perhaps a 79mb journal is not unreasonable. When the journals are deleted and rebuilt, they go down to 2mb. Any ideas as to why the index is so large, and what might cause journals to be written out of order? Thanks, Jakub