You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Lorenz Quack (JIRA)" <ji...@apache.org> on 2016/11/24 14:48:58 UTC
[jira] [Commented] (QPID-7547) [Java Broker] Refactor closing and
deletion of AbstractConfiguredObjects
[ https://issues.apache.org/jira/browse/QPID-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693458#comment-15693458 ]
Lorenz Quack commented on QPID-7547:
------------------------------------
A serious complication of this is that we cannot safely delete an object on the Config Thread from the IO Thread if that object also tries to do operations on the IO Thread (i.e., deadlock).
This is a problem especially on the AMQP 0-10 path.
> [Java Broker] Refactor closing and deletion of AbstractConfiguredObjects
> ------------------------------------------------------------------------
>
> Key: QPID-7547
> URL: https://issues.apache.org/jira/browse/QPID-7547
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Lorenz Quack
>
> Currently deletion and closing of objects are completely independent.
> It seems reasonable that an object that is being deleted should be closed before hand to ensure resources are being cleaned up and to reduce code duplication.
> In fact many implementations of ConfiguredObjects already do this.
> This JIRA suggests to do this in a generic way in AbstractConfiguredObject.
> The suggested order would be:
> ACO.deleteAsync
> * calls delete on all children
> * closes itself
> * deletes itself
--
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