Messages not moving to DLQ from a Queue configured as source queue of a core bridge.

[dhaval.rami]

HornetQ version : hornetq-2.2.14.Final

Running with -Xmx1536M

Setup:

• I have a main.queue, on which I have setup a non-exclusive divert to a divert.queue,

So all the messages that come to main queue are also copied to the divert.queue.

• I have defined DLQs and retry count for of '1' for both main.queue and divert.queue.
• I have setup a two core bridges

1) Between main.queue and a remote.main.queue on HQ in same LAN

2) Between divert.queue and a remote.divert.queue which is in some other network, and bridge operates in WAN.

The problem is with 2nd bridge, whenever there is some network fluctuation, the bridge disconnects and reconnects, the delivering count of the divert.queue goes up and comes down which is ideal .

If  disconnection are frequent and for longer duration the messages are never moved to DLQ of divert.queue, instead delivering count of divert.queue keeps on increasing  at one point all HQ memory is used up and it stops responding.

I am attaching the configuration file, tell me if I am missing/miss-configuring any parameter.

-Dhaval

[dhaval.rami]

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.

[clebert.suconic]

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:

https://github.com/hornetq/hornetq/commit/86d3f653529af09b7a59ea2374cd4ade6a39ff26

If that's not the issue... we need a replicator and a JIRA.

[dhaval.rami]

Hi Clebert,

                      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.

Sequence:

BridgeImpl.connectionFailed(HornetQException, boolean)

BridgeImpl.fail(boolean)

BridgeImpl.cancelRefs()

QueueImpl.cancel(MessageReference, long)

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.

-Dhaval

[clebert.suconic]

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.