1

I am using activemq. KahaDB is activemq's default message store. But it keeps on increasing in size and eventually runs out of disk space. Even if all the messages are acknowledged, it still grows in size and creates new log files in its data store continuously.

I have set no properties related to KahaDB, it is using the default properties.

        broker = new BrokerService();
        TransportConnector connector = new TransportConnector();
        connector.setUri(new URI("tcp://localhost:61616"));
        broker.addConnector(connector);
        broker.start();

These are the only properties I have set on broker. Can someone please tell me the properties I can use on KahaDB to not have this error?

hars
  • 127
  • 4
  • 17
  • There can be several reasons why you run out of disk space. I suggest to study ActiveMQ documentation / guides some more. – Claus Ibsen Oct 22 '17 at 14:08

1 Answers1

0

The KahaDB journals and index files stick around for a number of reasons some of which aren't always readily apparent so you need to do some debugging and see what is keeping the log files around, it can be as simple as one unacknowledged message that holds the whole log file, and in some cases future log files that track acks for the other messages in that log.

The ActiveMQ site has a nice article on it about looking into this so you can see what is in your case keeping things in the logs alive. It is also a good idea to use the latest release because things get fixed along the way to prevent logs from sticking around when they shouldn't.

Tim Bish
  • 17,475
  • 4
  • 32
  • 42
  • I definitely dont have any unacknowledged messages. If a message is sent to DLQ, then would that hold up the entire log file from being deleted? Lets take a scenario, If there are 20 messages in DLQ and all 20 are present in separate log files, then it would keep all 20 log files I believe, right? – hars Oct 22 '17 at 23:01
  • Yes, a DLQ is a Queue like any other, if the messages are sparsely laid out then they keep all the logs alive in which they reside. Using the debugging info provided in the link I gave would of course tell you that for sure if you'd just put some time into it. – Tim Bish Oct 23 '17 at 19:09