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 2018/05/30 09:25:00 UTC
[jira] [Comment Edited] (QPID-7541) [Java Broker] Close Consumers
when a Queue is deleted
[ https://issues.apache.org/jira/browse/QPID-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494923#comment-16494923 ]
Alex Rudyy edited comment on QPID-7541 at 5/30/18 9:24 AM:
-----------------------------------------------------------
As part of discussion on user mailing list [What is AMQP 1-0 spec complaint Broker behaviour for deletion of queue with consumers attached?|https://lists.apache.org/thread.html/3e64db4411925250b02e3f4648263a648c4406f1bbcb342369eeb06a@%3Cusers.qpid.apache.org%3E] the following consistent models for queue deletion were suggested:
* when deleting a queue which has had messages "consumed" by an uncommitted transaction, the queue deletion treats those messages as if the transaction had
already rolled back (e.g. puts them on a DLQ or whatever), and then the transaction itself is marked as rollback only. There is an implicit serialisation here that says that deleting the queue is an atomic operation and while it occurs you cannot process transaction commits/rollbacks which affect messages on the queue (nor can you allow new messages on to the queue nor allow acknowledgement of messages during the 'delete' operation).
* a queue cannot be deleted while there are associated sending or receiving links
I attached a patch implementing both approaches. The patch make changes to prevent the deletion of queue with any associated sending or receiving links by default. However, this default behaviour can be switched off by setting context variable {{qpid.queue.deleteUnusedOnly}} to {{false}} which would allow queue deletion as below:
* detaches all links with an error "amqp:resource-deleted"
* any in-progress producing/consuming transactions are marked as rollback-only
* the remaining messages on the deleted queue can be moved alternate binding if one is configured
Please note, that implemented changes do not add any locks for delete operation. Some more work is required to eliminate the races when the transaction discharge starts before the queue deletion marks the transaction as rollback-only. The queue delete operation should wait for the discharging transactions to complete.
was (Author: alex.rufous):
As part of discussion on user mailing list [What is AMQP 1-0 spec complaint Broker behaviour for deletion of queue with consumers attached?|https://lists.apache.org/thread.html/3e64db4411925250b02e3f4648263a648c4406f1bbcb342369eeb06a@%3Cusers.qpid.apache.org%3E] the following consistent models for queue deletion were suggested:
* when deleting a queue which has had messages "consumed" by an uncommitted transaction, the queue deletion treats those messages as if the transaction had
already rolled back (e.g. puts them on a DLQ or whatever), and then the transaction itself is marked as rollback only. There is an implicit serialisation here that says that deleting the queue is an atomic operation and while it occurs you cannot process transaction commits/rollbacks which affect messages on the queue (nor can you allow new
messages on to the queue nor allow acknowledgement of messages during the 'delete' operation).
* a queue cannot be deleted while there are associated sending or receiving links
I attached a patch implementing both approaches. The patch make changes to prevent the deletion of queue with any associated sending or receiving links by default. However, this default behaviour can be switched off by setting context variable {{qpid.queue.deleteUnusedOnly}} to {{false}} which would allow queue deletion as below:
* detaches all links with an error "amqp:resource-deleted"
* any in-progress producing/consuming transactions are marked as rollback-only
* the remaining messages on the deleted queue can be moved alternate binding if one is configured
Please note, that implemented changes do not add any locks for delete operation. Some more work is required to eliminate the races when the transaction discharge starts before the queue deletion marks the transaction as rollback-only. The queue delete operation should wait for the discharging transactions to complete.
> [Java Broker] Close Consumers when a Queue is deleted
> -----------------------------------------------------
>
> Key: QPID-7541
> URL: https://issues.apache.org/jira/browse/QPID-7541
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Reporter: Lorenz Quack
> Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 0001-QPID-7541-Broker-J-Close-Consumers-when-a-Queue-is-d.patch, proton-j_client.log, simultaneous_closing.log
>
>
> Currently when a Queue is deleted the associated Consumers are not closed.
> This is essentially a resource leak.
> Note: In 6.1.x, for the AMQP 1.0 protocol, deleting a queue did detach the sending links (without error). Receiving links were not detached. This code (org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0#queueDeleted) was removed in 7.0.x and this JIRA raised.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org