When the bridge target transport is not accessible, or there's a shovelling error, the Bridge will move messages into its own error queue (bridge.errorqueue, which is configurable)
The problem is, these error-messages can't be picked up by any tool currently provided by Particular. They require an administrator to manually move them across to another queue.
A quicker interim win would be to add the ability to put the bridge into some kind of a "recoverability mode" which would allow it to automatically re-process messages from its error queue.
Benefit to impacted parties
Customers would not need to involve administrators or write custom code/procedures to manually move messages out of the bridge's error queue so that they can be re-processed by the bridge.
mikesigs
commented
3 months ago
Problem description
When the bridge target transport is not accessible, or there's a shovelling error, the Bridge will move messages into its own error queue (
bridge.errorqueue, which is configurable) The problem is, these error-messages can't be picked up by any tool currently provided by Particular. They require an administrator to manually move them across to another queue.Whilst the ultimate goal is to incorporate the bridge error queue into ServiceControl and ServicePulse, that would require a bigger piece of work and hence a longer wait for customers to resolve their current friction points.
A quicker interim win would be to add the ability to put the bridge into some kind of a "recoverability mode" which would allow it to automatically re-process messages from its error queue.
Benefit to impacted parties
Customers would not need to involve administrators or write custom code/procedures to manually move messages out of the bridge's error queue so that they can be re-processed by the bridge.