Description of problem: Subscription queues defined using amqp1.0 are *not* auto-delete by default. Subscription queues defined using amqp0-10 are auto-delete by default. This puts amqp0-10 and amqp1.0 out of sync. After discussion with gsim we agreed that defining durable subscription queues to be auto-delete by default without a delayed time for the auto-delete, would not make much sense. ie. on broker restart, the broker terminates all the connections (and sessions), so in fact the durable queue is deleted on broker restart. note: By specifying that a subscription is durable, the client is taking on responsibility for deleting it to some extent. The right solution might be to have a configurable time-delayed auto-delete on subscription queues by default. This will protect the broker from clients that go off and leave stale subscriptions after a crash, but it still retain the general ability to survive a crash and re-establish subscription without lost messages. I'm going to fill a RFE bug for this improvement. Version-Release number of selected component (if applicable): qpid-cpp-*-0.22-7 How reproducible: 100% Steps to Reproduce: 1. $cppapi/drain -f amq.direct & 2. qpid-config queues the just created subscription queue is auto-del Actual results: Subscription queue is auto-delete by default (amqp0-10) Expected results: Subscription queue is not auto-delete by default (amqp0-10) Additional info:
> ... I'm going to fill a RFE bug for this improvement. please see bug 985870
Fixed upstream: https://svn.apache.org/r1504621
This improvement has been implemented. Verified on rhel6.6 (x86_64 and i386) and rhel7 (x86_64). The timed auto-delete (default to 120s) is now added by default to the subscription queue when a durable subscription is requested. This works for both amqp0-10 and amqp1.0, but only if C++ client is used (Using other clients the auto-delete-timeout must be explicitly set for the link). please see bug 985870 for details. Packages: qpid-cpp-0.30-7 -> VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0805.html