Synopsis:
Dynamic federation does not guarantee delivery of messages. Setting
autoDelete=false on the “transit-queue” during dynamic federation queue
creation would eliminate the issue.
Summary:
Our solution utilizes Qpid 0.5 C++ brokers and clients running on Red Hat
Enterprise Linux 5.4. We are a government backed project that must deploy onto
networks that are low bandwidth, high latency, and intermittently disconnected.
Guaranteed delivery of the messages is a fundamental requirement. Our
solution depends on brokers using direct exchanges and being dynamically
federated. Using dynamic federation, when network connectivity is lost for
more than seven minutes, all messages awaiting federation are deleted. At
re-connect, the federation routes are rebuilt but the unsent messages are not
restored. (Originally Stated in users mailing list on Thu, 05 Nov, 16:55)
Change Request:
Allow Dynamic Federation to create “transit-queues” with autoDelete=False. We
would like to request a new option, autoDelete, on the qpid-route command. In
our case, we would run
qpid-route --durable --autodelete=false dynamic add brokerB brokerA
fed.direct
============
This would be used to create exchange bindings with transit-queues having the
autoDelete property set to false.
Details:
We federate our brokers as follows:
qpid-route --durable dynamic add brokerB brokerA fed.direct
The dynamic option causes the qpid-route command to create a new
“transit-queue”, with the name "bridge-queue" at brokerA. The bridge-queue
serves as the means to move messages from brokerA to brokerB. The new queue
had queue properties of durable=False, exclusive=True and autoDelete=True.
If the network connection is broken for more than seven minutes, the session on
brokerB subscribing to the "bridge-queue" on brokerA is considered to have
ended. The loss of the session subscriber triggers the the autoDelete of the
bridge-queue. The result is that all messages awaiting federation via the
bridge queue are deleted (NOT persisted at all).
Ted Ross suggested a work around. He suggested we create a “queue” route where
the destination broker subscribes to an existing queue on the source broker.
This should cause the inter-broker route to use message acknowledgement in such
a way that recovery will be clean.
We encountered the following issues with the queue route:
1) “Out-of-order” message delivery was experienced
2) The first 1000KB of message data (in our case 10 messages) were not
delivered until the broker process was restarted. This sounds crazy but we
replicated the case multiple times.
3) Our solution loses the ability to do dynamic binding.
Our customer needs to have the in-order, guaranteed delivery of messages on low
quality networks.
How should we proceed with this request?
Cullen Davis
CommIT Enterprises, Inc
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
