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 an HTTP REST
endpoint on the application, which in turn executes some internal checks and
returns health status informatio
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.
On a second thought, why you just don't just set expiry on the messages
(e.g. 1h) which will move them to the separate queue (dlq) and use advisory
to create alert. You can then close the alert later when you process a
message from dlq.
Regards
--
Dejan Bosanac
--
Red Hat, Inc.
Hi Dejan,
Thanks for your reply.
I had a look at the plugin feature and I agree it could be a viable
solution.
However it does seem that I have to take extra considerations into account
to make the solution robust.
If I keep the message timings in memory similar to the other plugin
implementati
Hi Kristof,
I think the approach to your problem is to develop a custom plugin that can
track messages and their process times. There's some information on
interceptor mechanism in ActiveMQ at these pages
http://activemq.apache.org/interceptors.html
http://activemq.apache.org/developing-plugins.h
