You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For that IMO it would be essential to be able to create this error queue from the application (as error handling is part of the application) but currently I see no way to create this error queue from the app, as the outgoing channel does only allow creating exchanges but not queues. Any ideas how we can achieve that?
The text was updated successfully, but these errors were encountered:
thanks for you response, haven't seen it due to my holidays. What you describe is about requeuing/retrying which already works out of the box with this plugin due to dead-lettering in dlq, timeout and back to original queue. What I am after is what happens after n retries. In this case the message should be put to an error queue which is not consumed by any application but just a container holding error messages for an ops team or whatsoever. I don't see how the test you mentioned covers it or am I missing something?
We use the existing failure management mechanism (described here https://smallrye.io/smallrye-reactive-messaging/4.20.0/rabbitmq/receiving-messages-from-rabbitmq/#failure-management) in order to allow retries of failed messages by putting it to a dead letter queue with a ttl. We are however don't want to retry forever and put messages to an error queue after n retries.
For that IMO it would be essential to be able to create this error queue from the application (as error handling is part of the application) but currently I see no way to create this error queue from the app, as the outgoing channel does only allow creating exchanges but not queues. Any ideas how we can achieve that?
The text was updated successfully, but these errors were encountered: