[
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: [email protected]
For additional commands, e-mail: [email protected]
