A project that I am working on is seeing a massive build-up (over 500,000) persistent messages for a non-durable Topic.
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 clutser 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. The following select statement is resulting in hundreds of thousands of "physical reads" (per the DBA) each hour: SELECT ID, CONTAINER, MSG_ID, SENT_TO_DEADLETTER FROM ACTIVEMQ_MSGS WHERE (EXPIRATION <> 0 AND EXPIRATION<:1) 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: http://www.nabble.com/Persistent-messages-not-being-cleaned-up-for-non-durable-Topic-tf2242336.html#a6219438 Sent from the ActiveMQ - User forum at Nabble.com.
