It should instead return the derived per-minute value.
Note, the per-minute value is calculated by the plugin container based on the last two collected values and the time between them. We may need to tweak this code to be tolerant of live/user-requested collections, which could occur 1 or 2 seconds apart...
I have committed and pushed a fix to master. Changes were required on both the server and on the agent side. On the server side, MeasurementDataManagerBean.findLiveData had to be refactored to pass the schedule ids to the agent. We have to pass the schedule ids because per-minute metrics are calculated using cached, previously collected values. Those values are keyed off of the schedule id. On the agent side, MeasurementManager.getRealTimeMeasurementValue was refactored to calculate per-minute values for TRENDSUP/TRENDSDOWN metrics.
commit hash: 5dd42bad3a234981bfd05bbdeacb451e79963234
MeasurementDataManagerBean.findLiveData is part of the remote APIs, and these changes do not effect backwards compatibility since it is an implementation change only; however, I wanted to point this out because it should probably be tested as part of the verification for this bug.
For testing, you can use metrics for an RHQ server. Make sure the "Transactions Committed" and the "Transactions Committed per Minute" metrics are both enabled. If you select Transactions Committed (on the Tables sub tab) and repeatedly click the Get Live Value button, the value displayed should continually increase since this is a TRENDSUP metric. But when you select Transactions Committed per Minute and click the Get Live Value button, the displayed value should be less than the the value for Transactions Committed.
Bulk closing of old issues in VERIFIED state.