activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Co <>
Subject Re: Persistent messages not being cleaned up for non-durable Topic
Date Tue, 12 Sep 2006 00:52:16 GMT
FWIW, 3.x is pretty old. I would go for the 4.x code. :) Let us know how 
your tests go with the 4.x code.

kentdorsey wrote:
> 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
> testing.
> 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.
> Kent
> 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_DELIVERY_MODE (persistent), Message.DEFAULT_PRIORITY,
>> 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 raw message