Justin Bertram 246bf08391 ARTEMIS-2909 revert ARTEMIS-2322 ... This reverts commit dbb3a90fe6. The org.apache.activemq.artemis.core.server.Queue#getRate method is for slow-consumer detection and is designed for internal use only. Furthermore, it's too opaque to be trusted by a remote user as it only returns the number of message added to the queue since *the last time it was called*. The problem here is that the user calling it doesn't know when it was invoked last. Therefore, they could be getting the rate of messages added for the last 5 minutes or the last 5 milliseconds. This can lead to inconsistent and misleading results. There are three main ways for users to track rates of message production and consumption: 1. Use a metrics plugin. This is the most feature-rich and flexible way to track broker metrics, although it requires tools (e.g. Prometheus) to store the metrics and display them (e.g. Grafana). 2. Invoke the getMessageCount() and getMessagesAdded() management methods and store the returned values along with the time they were retrieved. A time-series database is a great tool for this job. This is exactly what tools like Prometheus do. That data can then be used to create informative graphs, etc. using tools like Grafana. Of course, one can skip all the tools and just do some simple math to calculate rates based on the last time the counts were retrieved. 3. Use the broker's message counters. Message counters are the broker's simple way of providing historical information about the queue. They provide similar results to the previous solutions, but with less flexibility since they only track data while the broker is up and there's not really any good options for graphing.		2020-09-23 12:08:57 -04:00
..
src	ARTEMIS-2909 revert ARTEMIS-2322	2020-09-23 12:08:57 -04:00
pom.xml	[maven-release-plugin] prepare for next development iteration	2020-08-24 16:03:24 +02:00