brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Heneveld (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-498) Deadlock in MembershipTrackingPolicyTest when updating sensors vs group members
Date Fri, 05 May 2017 13:08:04 GMT

    [ https://issues.apache.org/jira/browse/BROOKLYN-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998301#comment-15998301
] 

Alex Heneveld commented on BROOKLYN-498:
----------------------------------------

Thread 1 is trying to publish to members (needing members list lock while holding the AttributeMap.values
lock).

Main is updating the GROUP_MEMBERS sensor (needing AM.values lock) while adding a child member
(holding members list lock).

We have a similar issue with addition/removal of children -- in AbstractEntity.addChild we've
taken the view to publish outwith holding the lock which as a comment there notes could mean
that we publish REMOVED _after_ publishing ADDED.  We could take the same approach to group
members.  However it is nice being able to rely on publishing order.

The other option is to mandate that if the values lock is going to be sought while holding
members or children, the values lock should be taken first.  This feels safer to me.  [~aledsage]
?

> Deadlock in MembershipTrackingPolicyTest when updating sensors vs group members
> -------------------------------------------------------------------------------
>
>                 Key: BROOKLYN-498
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-498
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Alex Heneveld
>
> Core tests can hang due to this.  Set high invocation count eg on {{testDeprecatedSetGroupWorks}}
to expose.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message