The KahaDB index does not drop in size after increasing. It just keeps
track of free pages and will re-use them. So the index tends to grow as
large as it needs and hits a consistent point. A large backlog of messages
will cause the index to increase to track all of the messages. There was at
Jakub,
I had hoped that someone who knows the internals of KahaDB (not me) would
respond, but since no one has...
If the percent utilization dropped from 100% after the index rebuild, then
that's a bug (because the percent utilization should be the same in an
existing index and a rebuilt one)
Sorry, that last paragraph should have read:
--
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 *index* is not
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
