activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kentdorsey <>
Subject Re: Persistent messages not being cleaned up for non-durable Topic
Date Sat, 09 Sep 2006 19:27:03 GMT

The ActiveMQ 3.2.1 handling of persistent messages delivered to non-durable
topic subscriptions appears to incorrectly persist messages that have been
successfully received.

I set up a test case with a single message broker configured to use cached,
journaled, jdbc persistence against an HSQLDB database to do some local

Modified the ProducerTool to set the delivery mode to
DeliveryMode.PERSISTENT for non-durable as well as durable topic messages to
match the configuration on the project in question.  

Ran two ConsumerTool instances as non-durable subscribers to
dynamicTopics/bogus.  Ran a ProducerTool to send messages.  Messages were
sent and received correctly.

After several minutes, the messages were STILL persisted to the database,
due to the 5 minute period checkpoint() call in the JDBC adapter.

My hunch is that the discrepancy between the logic used to call
DurableTopicMessageContainerManager in the DefaultBroker and the logic used
to acknowledge a message in ActiveMQMessageConsumer and ActiveMQSession may
be the root cause of the problem.  Setting the Session to be transcated may
solve the problem, not sure.  Messages are persisted (correctly) when they
are marked with DeliveryMode.PERSISTENT, but no acknowledge is ever sent,
because the topic is not durable, among other things.

Message.DEFAULT_DELIVERY_MODE is DeliveryMode.PERSISTENT, so most users new
to ActiveMQ andJMS experience will be sending persistent messages.

Have not tested this in 4.x.


kentdorsey wrote:
> A project that I am working on is seeing a massive build-up (over 500,000)
> persistent messages for aTopic with non-durable subscribers.
> The configuration:
> ActiveMQ 3.2.1
> There is a network of brokers: A and B connected over a reliable protocol
> network channel.
> The brokers are being accessed as a cluster using a client connection URI
> with the reliable protocol to support failover.
> The topics in question have non-durable subscribers.
> The messages are being published with defaults, i.e.
> Message.DEFAULT_TIME_TO_LIVE (no expiration).
> The session acknowledgment mode is Session.AUTO_ACKNOWLEDGE.
> The client behavior does not call acknowledge() on the message, since
> Session.AUTO_ACKNOWLEDGE was specified.
> The problems:
> A slowdown in database performance :-)
> Over 500,000 messages have built up in the ACTIVEMQ_MSGS table over
> several months.
> There are no entries in ACTIVEMS_ACKS. (which is a good thing)
> The following select statement is resulting in hundreds of thousands of
> "physical reads" (per the DBA) each hour:
> There is no index on the EXPIRATION column.  There is a JIRA issue where
> this has been corrected.  The index will be added to the system in
> question.
> The questions:
> What is triggering the above select statement?
> I have read several reports on the forums of persistent messages not being
> deleted for non-durable topics.  Is there possibly a defect related to the
> above configuration?
> Thanks,
> Kent Dorsey

View this message in context:
Sent from the ActiveMQ - User forum at

View raw message