Bug 585844

Gordon,

We have a use case where we want to put a message in a temporary queue and only have the message "move" (via an alternate exchange) when the queue is deleted (after the configured amount of time of "non-use").  Do you think this is feasible?

Thanks,
Andy

Yes that is feasible. If the queue has the alternate-exchange property set then wehn it is deleted, all messages on it will be routed through the alternate-exchange.

Yes, that makes sense.  My question was more around the concept of "having a subscription to it from an active session" - since there's no subscription to this queue, what keeps it from being deleted prematurely?

You mean you want 'in-use' to include having messages enqueued? I.e. the queue would be deleted if (a) it has no subscription on it for the configured timeout or (b) if there is no message sent to it in that same timeout? If so, that is fine.

We're planning on enqueueing a single message into a temporary queue.  If the "session" is lost, we want that message to be sent to the alternate exchange.  But other than that one message, we don't plan on enqueueing anything else.

Ok, so you want the queue to be considered in-use while any session that declares it is active? And if that session then is lost it would wait for upto n secs for another session to declare it before deciding the queue was no longer needed? Does that sound right?

Yes, that sounds like it will work.  So when the execute() method is invoked in a failover situation (with retry=true), our client would declare the queue (even though it potentially already exists) and that would ensure it stays around, right?

Right

See http://svn.apache.org/viewvc/qpid/trunk/qpid/tests/src/py/qpid_tests/broker_0_10/extensions.py?view=markup for an example/test of this feature which is controlled through a new queue argument, qpid.auto_delete_timeout, whose value is specified in seconds.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:
Autodeleted queues are deleted as soon as the session using them is detached.

Consequence:
Such queues are lost on failover.

Change:
A new configuration option was added imposing a delay between the time a queue becomes eligible for auto-deletion and the time it is actually deleted.

Result:
If such a timeout is specified and is longer that the time for failover, then such queues will survive failover but will still be automatically cleaned up.

I can see the unit test test_timed_autodelete() passing which is fine.
I'm doing some manual investigation to better understand and test it.

Does this feature work only with queue exclusive set True (as normal queue-auto delete does) or I can expect that also non-exclusive queues can be auto-deleted after timeout?

Raising needinfo.

It is only relevant for auto-deleted queues, but should work for either exclusive or non-exclusive queues.

The feature has been implemented and tests:
  qpid_tests.broker_0_10.extensions.ExtensionTests.test_timed_autodelete
  custom_py_units.queue.LLAPITests.*timed_autodelete*
have proved that the feature is functional, tested on RHEL 4.9 / 5.6 / 6.1 i386 / x86_64 on packages:
python-qmf-debuginfo-0.9.1079953-3.el5.x86_64
python-qpid-0.9.1079482-1.el5.noarch
python-qpid-qmf-0.9.1079953-3.el5.x86_64
qpid-cpp-client-0.9.1079953-1.el5.x86_64
qpid-cpp-client-devel-0.9.1079953-1.el5.x86_64
qpid-cpp-client-devel-docs-0.9.1079953-1.el5.x86_64
qpid-cpp-client-rdma-0.9.1079953-1.el5.x86_64
qpid-cpp-client-ssl-0.9.1079953-1.el5.x86_64
qpid-cpp-mrg-debuginfo-0.9.1079953-1.el5.x86_64
qpid-cpp-server-0.9.1079953-1.el5.x86_64
qpid-cpp-server-cluster-0.9.1079953-1.el5.x86_64
qpid-cpp-server-devel-0.9.1079953-1.el5.x86_64
qpid-cpp-server-rdma-0.9.1079953-1.el5.x86_64
qpid-cpp-server-ssl-0.9.1079953-1.el5.x86_64
qpid-cpp-server-store-0.9.1079953-1.el5.x86_64
qpid-cpp-server-xml-0.9.1079953-1.el5.x86_64
qpid-dotnet-0.4.738274-2.el5.x86_64
qpid-java-client-0.9.1080013-2.el5.noarch
qpid-java-common-0.9.1080013-2.el5.noarch
qpid-java-example-0.9.1080013-2.el5.noarch
qpid-qmf-0.9.1079953-3.el5.x86_64
qpid-qmf-devel-0.9.1079953-3.el5.x86_64
qpid-tests-0.9.1073306-1.el5.noarch
qpid-tools-0.9.1078967-1.el5.noarch
rh-qpid-cpp-tests-0.9.1079953-1.el5.x86_64
ruby-qpid-qmf-0.9.1079953-3.el5.x86_64
sesame-0.9.4443-3.el5.x86_64
sesame-debuginfo-0.9.4443-3.el5.x86_64

-> VERIFIED

There seems to be an problem with the feature just in the consecutive qpid build qpid-cpp-server-0.10-1.el5.

The very basic test qpid_tests.broker_0_10.extensions.ExtensionTests.test_timed_autodelete consistently fails now:
qpid_tests.broker_0_10.extensions.ExtensionTests.test_timed_autodelete .. fail
Error during test:
  Traceback (most recent call last):
    File "/usr/bin/qpid-python-test", line 311, in run
      phase()
    File "/usr/lib/python2.4/site-packages/qpid_tests/broker_0_10/extensions.py", line 39, in test_timed_autodelete
      self.assert_(not result.queue)
    File "/usr/lib64/python2.4/unittest.py", line 309, in failUnless
      if not expr: raise self.failureException, msg
  AssertionError


The failure highlights the fact that queue was not deleted after timeout.

I'm investigating more, back to ON_QA atm.

Just fyi, it seems to pass on those packages for me...

The comment 15 is test issue caused by unit tests interference.

When looping just qpid_tests.broker_0_10.extensions.ExtensionTests.test_timed_autodelete everything is ok, but when looping all the python unit tests my-queue queue is left declared and causes false negative failures in next runs.

The feature works as expected.

Waiting for bug 683597 dependency for finishing this defect.

Thanks for the update Frantisek. I have updated the test upstream to use a unique queue name to avoid this.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -8,4 +8,8 @@
 A new configuration option was added imposing a delay between the time a queue becomes eligible for auto-deletion and the time it is actually deleted.
 
 Result:
-If such a timeout is specified and is longer that the time for failover, then such queues will survive failover but will still be automatically cleaned up.+If such a timeout is specified and is longer that the time for failover, then such queues will survive failover but will still be automatically cleaned up.
+
+Release Note Entry:
+
+Previously, queues marked for automatic deletion were deleted immediately after they were released from a session and, in case of failover, the queues were permanently lost. A delay has now been introduced between the time a queue is eligible for automatic deletion and the time when it is actually deleted. Additionally, if this delay period is longer than the failover time, then the queue survives the failover and then, if it is not required, is automatically deleted.

Technical note can be viewed in the release notes for 2.0 at the documentation stage here:

http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/2.0/html-single/MRG_Release_Notes/index.html#tabl-MRG_Release_Notes-RHM_Update_Notes-RHM_Update_Notes

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0890.html