Hi Dejan, The solution you are proposing is very elegant, however I don't think we can make it work in our situation.
In our current setup the monitoring/alert software polls various application http endpoints, which in turn execute some internal checks and return some status information in json. The monitoring software correlates and interprets this status info to either open or close the alert. Given our current monitoring software and network setup, there is no option for the application itself to directly make 'open/close alert' calls to the monitoring software. Another option is to use a database to keep track of in progress mesages on the DLQ, however this particular application doesn't use a database as it is just mediating an FTP signal to various HTTP endpoints. Bringing in a database dependency just for tracking overdue messages feels wrong, my view is that the AMQ broker itself should provide this info. I think the plugin is an perfect long term solution, but meanwhile I just might go for a quick countermeasure employing the exclusive consumer feature to either have the consumer or the browser accessing the queue seperately. That way I don't have to worry about dispatched messages not showing up in the browser thread causing the false negatives. The consequence is off course that this will only work with a single consumer. Let me know what you think. Best regards, Kristof I guess I need to tell you a bit more about the architecture -- View this message in context: http://activemq.2283324.n4.nabble.com/Reliably-calculate-time-spent-in-broker-tp4669606p4669891.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
