I solved my issue by testing different parameters for this bean, https://activemq.apache.org/maven/apidocs/org/apache/activemq/store/kahadb/AbstractKahaDBStore.html
Exampe Activemq.xml section: <jobSchedulerStore> <bean xmlns="http://www.springframework.org/schema/beans"; id="jobSchedulerStore" class="org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl"> <property name="directory" value="${activemq.data}/localhost/scheduler" /> <property name="cleanupInterval" value="10" /> <property name="checkpointInterval" value="1" /> </bean> </jobSchedulerStore> This looks like a user documentation bug? Thank you in advance! Alex -----Original Message----- From: Aleksander Pähn <ap...@perforce.com.INVALID> Sent: Wednesday, January 10, 2024 1:14 PM To: users@activemq.apache.org Subject: RE: Understanding scheduledb.data behavior Any additional feedback on this? Because this part looks undocumented. I have been making tests with https://activemq.apache.org/maven/apidocs/org/apache/activemq/store/kahadb/AbstractKahaDBStore.html And its parameters. I see the db* logs being cleaned up and the size of the scheduledb.data fluctuating when I enable cleanupInterval. This tells me some maintenance is happening - but Im trying to understand the basic algorithm or conditions. What and when gets cleaned up. But when all messages are consumed, and no DLQ. The size of the scheduledb.data does not go down to the initial few KB. Is this a documentation bug? Kind regards and thank you in advance! Alex. -----Original Message----- From: Aleksander Pähn <ap...@perforce.com.INVALID> Sent: Thursday, January 4, 2024 5:24 PM To: users@activemq.apache.org Subject: RE: Understanding scheduledb.data behavior Thank you for your reply. I appreciate your assistance! This is my lab and no DLQ is configured. I consumed all messages from the queues where I tested different message sizes and numbers, waited around 5 minutes. Then checked the /data/localhost/scheduler directory and the scheduledb.data file remains the same size as before consuming the messages. I deleted ALL queues and then restarted the broker, Then checked the /data/localhost/scheduler directory and the scheduledb.data file remains the same size as before deleting all queues and broker restart. What am I missing here? Why is the schedulerdb.data file not shrinking when there are no message or queues to schedule. Kind regards, Alex -----Original Message----- From: Jean-Baptiste Onofré <j...@nanthrax.net> Sent: Thursday, January 4, 2024 10:26 AM To: users@activemq.apache.org Subject: Re: Understanding scheduledb.data behavior Hi, Don't you have a message in DLQ or in the scheduler (redelivered) ? Regards JB On Wed, Jan 3, 2024 at 5:02 PM Aleksander Pähn <ap...@perforce.com.invalid> wrote: > > Hello, > > Im trying to understand the behavior, because the scheduledb.data file > continues to grow no matter how many messages are consumed. > What am I missing? > > Consider this, > ActiveMQ Classic 5.16.3, OpenJDK 1.8.0_392 , Ubuntu 22.04 > 2 Queues 1 and 2 > Each queue 100000 messages. > Queue1 All messages consumed, number of dblog files reduced. > Queue2 Deleted, number of dblog files shrunk. > > Observations, > 1. One dblog file remains in /data/localhost/scheduler. > 2. /data/localhost/scheduler/scheduledb.data file is the same size as before > consuming and deleting. - Why is scheduledb.data not shrinking as the > messages are consumed or queue deleted? > 3. The /data/localhost/tmp_storage directory shows more dblog files than > /data/localhost/scheduler - why? > > Thank you in advance! > Alex > > > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.
