I still have no solution for above issue. It still keeps on occurring.
I want to solve it through hornetq config, don't want to code for a customized workaround .
Don't find any logical reason why messages should not go to a DLQ in above scenario.
Any HornetQ experts out there ? who can comment on it.
There was an issue on not moving to DLQ when there are no Queues on an Address. it's fixed on all the Three branches:
If that's not the issue... we need a replicator and a JIRA.
I spent some time understanding the HornetQ-2.2.14-Final code today.
What I observed in sequence of methods being called if a connection fails.
In above entire sequence none of the method increased "reference.deliveryCount".
Shouldn't the reference.deliveryCount( number of attempts ) be increased in case of cancellation? isn't it similar to retrying same message again, once the bridge is connected ?
I see that as one of the reasons why messages are not moved to DLQ when bridge connection keeps on fluctuating.
Please share your comments on this.
I don't see a reason for DLQ through the bridge on this case....
The messages will get to the DLQ when the user rolls back receiving a message, say if the message has something spoiling your data and causing you to rollback your data. (say you are receiving a message that's causing a duplicate key in your Database, so you will rollback over and over). on that case the rollback will count as a delivery and make it to the DLQ.
On the Case of the bridge.. a temporary failure doesn't fall into that... The bridge is supposed to deliver all the messages between two nodes and recover well from failures. There is no treatment for rollback messages on the bridge.