Rob, Thanks for the response! I've tried using separate consumers, one for each queue, and got the same results. So, it doesn't appear to be caused by the wildcard '>'. I will raise an issue for this.
For the time being, do you know if I can setup a cron job to delete the old files? If we set our expiration time to say 2 hours on all our queue messages, then it seems I can safely delete all old files that are greater than 2 hours old. Will this mess something else up though? Maybe an index somewhere that references these old files? Thanks, Brian -----Original Message----- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: Saturday, May 31, 2008 2:32 AM To: users@activemq.apache.org Subject: Re: Journal files don't get cleaned up On 31 May 2008, at 02:15, Desai, Brian wrote: > I'm running ActiveMQ 5.1.0 with the AMQ persistence adapter, and it > appears that not all of the journal files get cleaned up. My setup > is a > little abnormal, as I'm trying to test out ActiveMQ's ability to > handle > queue messaging with consumers that may become inactive for periods of > time. > > So for this test, I have a single publisher pushing messages out to 21 > queues. These are persistent messages with an expiration time. I > have > a message listener reading from all queues (reading from '>'). So, as > soon as the message is sent to the queues, it's read by the message > listener, taking it off the queue. So far, so good. > > I have a 2 MB max file length set on the AMQ persistence adapter. > So, I > would expect to see for the journal, 2 MB files that get cleaned up > after the file rolls over. However, the journal files don't always > get > cleaned up, as shown in the file listing below. Out of 181 rollovers, > 30 of the files did not get cleaned up. The message listener showed > no > errors, and as far as I can tell, it didn't drop any messages. > > -rw-r--r-- 1 root root 2096753 2008-05-30 20:30 data/journal/data-13 > -rw-r--r-- 1 root root 2096967 2008-05-30 20:31 data/journal/data-14 > -rw-r--r-- 1 root root 2096899 2008-05-30 20:45 data/journal/data-25 > -rw-r--r-- 1 root root 2097057 2008-05-30 21:20 data/journal/data-52 > -rw-r--r-- 1 root root 2096916 2008-05-30 21:22 data/journal/data-54 > -rw-r--r-- 1 root root 2096536 2008-05-30 21:45 data/journal/data-72 > -rw-r--r-- 1 root root 2096894 2008-05-30 21:47 data/journal/data-73 > -rw-r--r-- 1 root root 2097129 2008-05-30 21:49 data/journal/data-75 > -rw-r--r-- 1 root root 2097101 2008-05-30 21:58 data/journal/data-82 > -rw-r--r-- 1 root root 2097026 2008-05-30 21:59 data/journal/data-83 > -rw-r--r-- 1 root root 2096906 2008-05-30 22:02 data/journal/data-85 > -rw-r--r-- 1 root root 2096973 2008-05-30 22:13 data/journal/data-94 > -rw-r--r-- 1 root root 2097105 2008-05-30 22:24 data/journal/data-102 > -rw-r--r-- 1 root root 2097033 2008-05-30 22:41 data/journal/data-113 > -rw-r--r-- 1 root root 2096730 2008-05-30 22:42 data/journal/data-114 > -rw-r--r-- 1 root root 2096569 2008-05-30 22:45 data/journal/data-116 > -rw-r--r-- 1 root root 2096870 2008-05-30 22:50 data/journal/data-118 > -rw-r--r-- 1 root root 2096567 2008-05-30 22:52 data/journal/data-119 > -rw-r--r-- 1 root root 2096766 2008-05-30 23:03 data/journal/data-128 > -rw-r--r-- 1 root root 2096877 2008-05-30 23:06 data/journal/data-130 > -rw-r--r-- 1 root root 2096888 2008-05-30 23:18 data/journal/data-140 > -rw-r--r-- 1 root root 2096699 2008-05-30 23:20 data/journal/data-141 > -rw-r--r-- 1 root root 2096973 2008-05-30 23:22 data/journal/data-143 > -rw-r--r-- 1 root root 2096924 2008-05-30 23:31 data/journal/data-150 > -rw-r--r-- 1 root root 2096936 2008-05-30 23:45 data/journal/data-161 > -rw-r--r-- 1 root root 2096527 2008-05-30 23:57 data/journal/data-170 > -rw-r--r-- 1 root root 2097151 2008-05-30 23:58 data/journal/data-171 > -rw-r--r-- 1 root root 2096972 2008-05-31 00:11 data/journal/data-179 > -rw-r--r-- 1 root root 2096703 2008-05-31 00:13 data/journal/data-180 > -rw-r--r-- 1 root root 2097069 2008-05-31 00:14 data/journal/data-181 > > I haven't even gotten to the test yet where the listener is not > running. > So, in this "normal" operation, all messages are consumed. Yet, not > all > journal files get cleaned up. These left-over files don't ever get > cleaned up. They will eventually start filling the hard drive. I can > understand files being left behind when there's no consumer, but there > is a consumer the whole time. > > Does anyone know why this happens, or how I can fix it? > > What I'm basically looking for is a persistence layer for messaging to > multiple clients, so that consumers can get messages retroactively > when > they start up. I could try to use topics with durable clients, but I > thought the queues would be easier to setup, as messages in queues are > persisted by default. However, I don't want the consumer to process > "stale" messages, which is why I set an expiration time. So, I would > think that, with a constant rate of messages, the persistent disk > store > utilization would eventually level out as the messages started to > expire. I realize that if there's no consumer for a queue, expired > messages won't get cleaned up (am currently trying to figure out a > work-around for that - periodically checking the queues with a > QueueBrowser seems to trigger the removal of expired messages). > However, even when all consumers are active, the journal keeps > growing, > as it's not always cleaning up it's files! > > Here's my configuration. > > <beans > xmlns="http://www.springframework.org/schema/beans"; > xmlns:amq="http://activemq.apache.org/schema/core"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.0.xsd > http://activemq.apache.org/schema/core > http://activemq.apache.org/schema/core/activemq-core.xsd > http://activemq.apache.org/camel/schema/spring > http://activemq.apache.org/camel/schema/spring/camel-spring.xsd";> > > <!-- Allows us to use system properties as variables in this > configuration file --> > <bean > class > ="org.springframework.beans.factory.config.PropertyPlaceholderConfi > gurer"/> > > <broker xmlns="http://activemq.apache.org/schema/core"; > brokerName="localhost" dataDirectory="${activemq.base}/data" > advisorySupport="false"> > > <!-- Destination specific policies using destination names or > wildcards --> > <destinationPolicy> > <policyMap> > <policyEntries> > <policyEntry queue=">" memoryLimit="5mb"> > <deadLetterStrategy> > <sharedDeadLetterStrategy > processExpired="false"/> > </deadLetterStrategy> > </policyEntry> > <policyEntry topic=">" memoryLimit="5mb"> > <dispatchPolicy> > <strictOrderDispatchPolicy/> > </dispatchPolicy> > <subscriptionRecoveryPolicy> > <lastImageSubscriptionRecoveryPolicy/> > </subscriptionRecoveryPolicy> > </policyEntry> > </policyEntries> > </policyMap> > </destinationPolicy> > > <!-- Use the following to configure how ActiveMQ is exposed in > JMX --> > <managementContext> > <managementContext createConnector="true"/> > </managementContext> > > <persistenceAdapter> > <amqPersistenceAdapter archiveDataLogs="false" > syncOnWrite="false" > directory="${activemq.base}/data" > maxFileLength="2 mb"/> > </persistenceAdapter> > > <!-- The maximum about of space the broker will use before > slowing down producers --> > <systemUsage> > <systemUsage> > <memoryUsage> > <memoryUsage limit="20 mb"/> > </memoryUsage> > <storeUsage> > <!--<storeUsage limit="1 gb" name="foo"/>--> > <storeUsage limit="5 mb" name="foo"/> > </storeUsage> > <tempUsage> > <!--<tempUsage limit="100 mb"/>--> > <tempUsage limit="5 mb"/> > </tempUsage> > </systemUsage> > </systemUsage> > > <!-- The transport connectors ActiveMQ will listen to --> > <transportConnectors> > <transportConnector name="openwire" > uri="tcp://localhost:61606" discoveryUri="multicast://default"/> > <transportConnector name="ssl" uri="ssl://localhost: > 61617"/> > <transportConnector name="stomp" > uri="stomp://localhost:61613"/> > <transportConnector name="xmpp" > uri="xmpp://localhost:61222"/> > </transportConnectors> > > </broker> > > </beans> > > > > Any help would be greatly appreciated! > > Thanks, > Brian > Hi Brian, thanks for the very detailed email! This does look like a bug - and its probably related to the use of the wildcard '> ' for the Queue listener. I wonder if you've looked ay virtual topics - see http://activemq.apache.org/virtual-destinations.html ? Could you raise an issue for us - so we don't forget to track? cheers, Rob http://open.iona.com/products/enterprise-activemq http://rajdavies.blogspot.com/
