Bug 585844 - RFE: allow timed autodelete for queue
Summary: RFE: allow timed autodelete for queue
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: Development
Hardware: All
OS: Linux
high
medium
Target Milestone: 2.0
: ---
Assignee: Gordon Sim
QA Contact: Frantisek Reznicek
URL:
Whiteboard:
Depends On: 683597
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-26 08:39 UTC by Gordon Sim
Modified: 2015-11-16 01:12 UTC (History)
9 users (show)

Fixed In Version: qpid-cpp-mrg-0.9.1073306-1
Doc Type: Enhancement
Doc Text:
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. 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.
Clone Of:
Environment:
Last Closed: 2011-06-23 15:45:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:0890 0 normal SHIPPED_LIVE Red Hat Enterprise MRG Messaging 2.0 Release 2011-06-23 15:42:41 UTC

Description Gordon Sim 2010-04-26 08:39:44 UTC
Some usecases want a queue that will be deleted automatically if not 'used' for some configured length of time. Used in this context may be as simple as having a subscription to it from an active session.

Comment 1 Andy Goldstein 2010-04-26 12:52:44 UTC
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

Comment 2 Gordon Sim 2010-04-26 13:02:42 UTC
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.

Comment 3 Andy Goldstein 2010-04-26 14:14:52 UTC
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?

Comment 4 Gordon Sim 2010-04-26 14:31:34 UTC
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.

Comment 5 Andy Goldstein 2010-04-26 14:39:03 UTC
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.

Comment 6 Gordon Sim 2010-04-26 14:46:24 UTC
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?

Comment 7 Andy Goldstein 2010-04-26 15:41:20 UTC
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?

Comment 8 Gordon Sim 2010-04-26 15:46:37 UTC
Right

Comment 10 Gordon Sim 2011-02-22 11:53:28 UTC
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.

Comment 11 Gordon Sim 2011-03-07 14:44:22 UTC
    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.

Comment 12 Frantisek Reznicek 2011-03-07 17:43:49 UTC
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.

Comment 13 Gordon Sim 2011-03-07 17:47:10 UTC
It is only relevant for auto-deleted queues, but should work for either exclusive or non-exclusive queues.

Comment 14 Frantisek Reznicek 2011-03-15 12:18:24 UTC
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

Comment 15 Frantisek Reznicek 2011-04-06 07:34:16 UTC
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.

Comment 16 Gordon Sim 2011-04-06 11:54:16 UTC
Just fyi, it seems to pass on those packages for me...

Comment 17 Frantisek Reznicek 2011-04-07 14:21:28 UTC
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.

Comment 18 Gordon Sim 2011-04-07 18:03:01 UTC
Thanks for the update Frantisek. I have updated the test upstream to use a unique queue name to avoid this.

Comment 19 Misha H. Ali 2011-05-31 04:44:56 UTC
    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.

Comment 20 Misha H. Ali 2011-06-06 03:14:34 UTC
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

Comment 21 errata-xmlrpc 2011-06-23 15:45:01 UTC
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


Note You need to log in before you can comment on or make changes to this bug.