Hi @espinosada ,
There are a bunch of things to consider here:
- If your max redelivery count is 5 and you have messages going to the DMQ due to max deliveries that means they are failing 5 times before doing so. Do you have an idea why those 11 messages failed 5 times? Consider if they would have succeeded if they were tried 5 or 10 or 30 seconds later or if they were just payloads that couldn’t be parsed so they would have continued to fail. Note that by default Solace will redeliver immediately, but if your service is failing b/c of something that might be resolved with a little time you can configure delayed redelivery on the queue to make it wait prior to redelivery.
I don’t have tested it but it seems that messages in DMQ are not DMQ eligible, what if there is a reconnection in DMQ as well? The messages would be lost?
- You are correct that messages placed on DMQs are not DMQ eligible. That said, if you want to make sure you never lose a message you should make sure you have redelivery set to “try forever” (the default) on your DMQ to ensure messages are never discarded due to the number of redeliveries.
Before migrating to solace we were using Rabbit MQ with TTL to expire from DLQ to main queue, but it is not clear if the same is possible with solace, it seems like its not.
- Solace out of the box doesn’t allow you to chain DMQs together, however since you are using Spring Cloud Stream you could actually implement something like this by using the “error queue” that our binder allows you to configure using
autoBindErrorQueue. That error queue is just a regular Solace queue so you could configure it so it’s DMQ is your initial delivery queue. You have just have to be careful when doing so as you could end up with messages going in an infinite loop if you don’t have some other sort of error checking. You may just want to have an app that listens to your DMQ, does some sort of check to make sure then message is processable and then have it published back to the main queue.
Hope that helps!