Re AMQ-1648; it would be ideal to avoid as much as possible having to evict/lose messages, because a queue or some other system resource has reached its max capacity. Instead, you'd like to proactively monitor system resources and invoke or trigger some action (e.g., whenever a resource reaches a predefined threshold) that can alleviate the situation and thus avert losing messages. Check out http://www.ttmsolutions.com/Transactional_Software_Solutions/Active_Monitor_AMon.php AMon . It gives you that facility to do just that.
Joe http://www.ttmsolutions.com stirlingc wrote: > > > Joe Fernandez wrote: >> >> Sounds like you're wanting to implement a message-level audit trail? With >> Camel, you could very quickly implement a wiretap message pattern >> (http://camel.apache.org/wire-tap.html) and have the wiretap route the >> tapped messages to a log4j appender. The appender's logfile could >> rollover based on size and/or time. You could then write a simple MBean >> that is loaded via a plugin and used to query the appender's log file. >> With this approach, you'd have much more control. >> > > Thanks for the idea, that sounds like a possible solution. I was hoping, > however, to do this with the stock AMQ MBeans and queue configuration > rather than introducing new code into our system, however, it looks like I > might have to do this. The existing MBean views are sufficient for our > purposes, but the problem is that the messages are so short-lived in the > queue that they are rarely browseable. > > I found the following open ticket for implemented fixed-size rollover > queues, so this answers my first question: > > http://issues.apache.org/activemq/browse/AMQ-1648 > -- View this message in context: http://old.nabble.com/How-to-maintain-an-historical-view-of-queue-contents--tp26159890p26163364.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
