centiservice/matsbrokermonitor

Monitors a message broker for its Mats-relevant queues and topics and DLQs

matsbrokermonitor's Issues

Resize-handle on all textboxes.

Often the stacktraces and DTOs are annoyingly large. #5 provides for a way to copy it out, but a resize handle could make it easier to just quickly look at it right in the browser.

"Copy all text"-button for all text-boxes

Often the devs wants to copy out the text and paste it into an IDE or similar so as to use all tooling available there to analyze it (at least better search than the browser provides).

#6 suggest a resize-handle on all textboxes too.

"Nuke from orbit" - "delete everything"-button for non-prod environments

"GUI" for introspecting queues (and topics) relating to MATS on the MQ

Way to introspect the MQ for MATS messages.

• Inspect queues, and DLQs
• View the MatsTrace
• Retry, Delete, Edit
• Stats
• Configurable filter that logs every message, tracking to and from etc.

Check how the "reissue-cookie" works if it actually triggers

Just occurred to me that we might have already read in the message then - thus we should not commit.

Make "Reissue All" and "Delete All" functionality from QueueBrowse view.

Create Broadcaster (and control) and Broadcast receiver for MatsFactories to get information about queue sizes etc.

When the MatsBrokerMonitor has gotten a full view over the Broker's queues and DLQs, it can broadcast this over the Mats fabric. The different services employing Mats may then install the broadcast receiver to get this information (which is not available via ordinary JMS) and incorporate it into its MatsFactory (based on the queues/topics of its Endpoints).

This enables HealthCheck-style functionality out on the services, instead of it being centralized on the broker or MatsBrokerMonitor - i.e. a service can itself warn that there are many messages on queue, or that the head message is old, or that there are DLQs.

In addition, it would be good if the service could request a forced update back, by submitting a message back to the broadcaster, which then again asks the MatsBrokerMonitor to do the forcedUpdate.

.. this can be extended (as have been the plan..!) to let the "Receiver" part fully implement the MatsBrokerMonitor interface. Further, this idea can be extended to let the services have the full MatsBrokerMonitor GUI, so that one can do view queues and messages, and reissue/delete messages, out on the services.