You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alex Rudyy (JIRA)" <ji...@apache.org> on 2015/08/07 16:10:46 UTC
[jira] [Comment Edited] (QPID-6667) [Java Broker] Unusued temporary
queues are not deleted on connection disconnect
[ https://issues.apache.org/jira/browse/QPID-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14661677#comment-14661677 ]
Alex Rudyy edited comment on QPID-6667 at 8/7/15 2:09 PM:
----------------------------------------------------------
I investigated the issue and here is the summary of my investigation:
Both 0.8/0.9.x and 0.10 clients declare temporary queue as exclusive, auto-delete, non-durable queue.
On 0.8/0.9.x path lifecycle policy DELETE_ON_NO_OUTBOUND_LINKS is used for the queue which is exclusive and auto-delete. As result, queue is get deleted only on consumer deletion. The code snippet above does not create a consumer, as result, no consumer close happens and queue is not deleted. The exhibited behvaiour adheres 0.9 spec requirement for queue declared with auto-delete set to "true":
from amqp0-9.xml about queue field "auto-delete":
{quote}
If set, the queue is deleted when all consumers have finished using it. Last
consumer can be cancelled either explicitly or because its channel is closed. If
there was no consumer ever on the queue, it won't be deleted.
{quote}
from amqp0-9-1.xml about queue field "auto-delete":
{quote}
If set, the queue is deleted when all consumers have finished using it. The last
consumer can be cancelled either explicitly or because its channel is closed. If
there was no consumer ever on the queue, it won't be deleted. Applications can
explicitly delete auto-delete queues using the Delete method as normal.
{quote}
Both specs states: If there was no consumer ever on the queue, it won't be deleted.
However, both 0.9 and 0.9.1 spec require the following behavior for exclusive flag set to true:
from amqp0-9.xml:
{quote}
Exclusive queues may only be consumed from by the current connection. Setting
the 'exclusive' flag always implies 'auto-delete'.
{quote}
{quote}
The client MAY NOT attempt to declare any existing and exclusive queue on multiple connections.
{quote}
from amqp0-9-1.xml:
{quote}
Exclusive queues may only be accessed by the current connection, and are
deleted when that connection closes. Passive declaration of an exclusive
queue by other connections are not allowed.
{quote}
{quote}
The client MAY NOT attempt to use a queue that was declared as exclusive by another still-open connection.
{quote}
Both 0.9 and 0.9.1 spec require to delete exclusive queue on connection close. 0.9.1 spec is even more stricter and does not allow to use exclusive queue on a separate connection.
Thus our current 0.8/0.9.x implementation conforms the spec about auto-delete queue requirements but does not conform spec requirements for exclusive queues.
JMS 1.1 spec requires the following for temporary queues:
{quote}
5.4 TemporaryQueue
A TemporaryQueue is a unique Queue object created for the duration of a Connection or QueueConnection. It is a system-defined queue that can be consumed only by the Connection or QueueConnection that created it.
{quote}
Thus, implemented 0.8/0.9.x behavior does not conform JMS 1.1 spec either.
0n 0.10 path lifecycle policy DELETE_ON_SESSION_END is used for the queue with both exclusive and auto-delete flags set to true. As result, queue is get deleted on session close which is in line with 0.10 spec requirements about auto-delete flag :
{quote}
If this field is set and the exclusive field is also set, then the queue MUST be deleted when the session closes.
{quote}
The exhibited 0.10 behavior is partially inline with JMS 1.1 spec requirements about temporary queues as the queue lifespan ends with the session where it was created
Arguably, existing 0.8/0.9.x implementation makes sense for request-response patterns when separate connections are used for requesting and responding apps. I suppose that it was the driver for current implementation.
IMHO, it make sense to introduce a connection parameter which would regulate temporary queue behavior, for example, "temp-queue-lifecycle" which could be set by default to "delete-on-connection-close" in case of 0.8/0.9.x or to "delete-on-session-close" in case of 0.10 to confirm JMS spec requirements (in this case, we can create temp queue with only exclusive flag set to true for 0.8/0.9.x or both exclusive flag and auto-delete flag set to true for 0.10 ). Users can override the behavior by setting "temp-queue-lifecycle" to "delete-on-no-consumer" which would result in creating temp queue with only auto-delete flag set to true.
was (Author: alex.rufous):
I investigated the issue and here is the summary of my investigation:
Both 0.8/0.9.x and 0.10 clients declare temporary queue as exclusive, auto-delete, non-durable queue.
On 0.8/0.9.x path lifecycle policy DELETE_ON_NO_OUTBOUND_LINKS is used for the queue which is exclusive and auto-delete. As result, queue is get deleted only on consumer deletion. The code snippet above does not create a consumer, as result, no consumer close happens and queue is not deleted. The exhibited behvaiour adheres 0.9 spec requirement for queue declared with auto-delete set to "true":
from amqp0-9.xml about queue field "auto-delete":
{quote}
If set, the queue is deleted when all consumers have finished using it. Last
consumer can be cancelled either explicitly or because its channel is closed. If
there was no consumer ever on the queue, it won't be deleted.
{quote}
from amqp0-9-1.xml about queue field "auto-delete":
{quote}
If set, the queue is deleted when all consumers have finished using it. The last
consumer can be cancelled either explicitly or because its channel is closed. If
there was no consumer ever on the queue, it won't be deleted. Applications can
explicitly delete auto-delete queues using the Delete method as normal.
{quote}
Both specs states: If there was no consumer ever on the queue, it won't be deleted.
However, both 0.9 and 0.9.1 spec require the following behavior for exclusive flag set to true:
from amqp0-9.xml:
{quote}
Exclusive queues may only be consumed from by the current connection. Setting
the 'exclusive' flag always implies 'auto-delete'.
{quote}
{quote}
The client MAY NOT attempt to declare any existing and exclusive queue on multiple connections.
{quote}
from amqp0-9-1.xml:
{quote}
Exclusive queues may only be accessed by the current connection, and are
deleted when that connection closes. Passive declaration of an exclusive
queue by other connections are not allowed.
{quote}
{quote}
The client MAY NOT attempt to use a queue that was declared as exclusive by another still-open connection.
{quote}
Both 0.9 and 0.9.1 spec require to delete exclusive queue on connection close. 0.9.1 spec is even more stricter and does not allow to use exclusive queue on a separate connection.
Thus our current 0.8/0.9.x implementation conforms the spec about auto-delete queue requirements but does not conform spec requirements for exclusive queues.
JMS 1.1 spec requires the following for temporary queues:
{quote}
5.4 TemporaryQueue
A TemporaryQueue is a unique Queue object created for the duration of a Connection or QueueConnection. It is a system-defined queue that can be consumed only by the Connection or QueueConnection that created it.
{quote}
Thus, implemented 0.8/0.9.x behavior does not conform JMS 1.1 spec either.
0n 0.10 path lifecycle policy DELETE_ON_SESSION_END is used for the queue with both exclusive and auto-delete flags set to true. As result, queue is get deleted on session close which is in line with 0.10 spec requirements about auto-delete flag :
{quote}
If this field is set and the exclusive field is also set, then the queue MUST be deleted when the session closes.
{quote}
The exhibited 0.10 behavior is also inline with JMS 1.1 spec requirements about temporary queues
Arguably, existing 0.8/0.9.x implementation makes sense for request-response patterns when separate connections are used for requesting and responding apps. I suppose that it was the driver for current implementation.
IMHO, it make sense to introduce a connection parameter which would regulate temporary queue behavior, for example, "temp-queue-lifecycle" which could be set by default to "delete-on-session-close" to confirm JMS spec requirements (in this case, we can create temp queue with only exclusive flag set to true ). Users can override the behavior by setting "temp-queue-lifecycle" to "delete-on-no-consumer" which would result in creating temp queue with only auto-delete flag set to true.
> [Java Broker] Unusued temporary queues are not deleted on connection disconnect
> -------------------------------------------------------------------------------
>
> Key: QPID-6667
> URL: https://issues.apache.org/jira/browse/QPID-6667
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Alex Rudyy
> Fix For: qpid-java-6.0
>
>
> Creating a temporary queue, never using it and then closing the connection leaves the (unused) temporary queue on the broker
> The following code snippet reproduce the issue
> {code}
> System.setProperty((ClientProperties.AMQP_VERSION), "0-9-1");
> AMQConnection connection = new AMQConnection("localhost", 5672, "guest", "guest", "", "/test");
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> for(int i = 0; i < 100; i++)
> {
> final TemporaryQueue tmpQ = session.createTemporaryQueue();
> }
> System.exit(0);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org