brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: DynamicCluster entity and cluster.first.first sensor
Date Thu, 07 Sep 2017 11:44:26 GMT

Thanks Thomas, and Richard.  More details:

This removed the boolean `cluster.first` set on group members -- code 
that was marked in the code for removal (and which was ambiguous and 
buggy eg if an entity is in two groups, and which caused deadlocks when 
using dynamic group membership).

It does have a simple workaround as Thomas notes -- access the 
`cluster.first.entity` on the group (though note it's not necessarily 
the `parent`).  The PR also now correctly updates this and clears this 
as the group changes or becomes empty, respectively.  Alternatively you 
can set the `firstMember` specially to advertise its first-ness.  There 
are also some policies for electing a primary node in a group (one of 
the main use cases of this I believe) which I've been working on and 
will add these soon.

As the removal is a breaking change I should have flagged it on ML and 
in release notes:  mea maxima culpa!  ML absence has been remedied here 
-- and it is going in to release notes imminently.


On 07/09/2017 12:17, Thomas Bouron wrote:
> Hi Brooklyner.
> Just a quick heads-up for those who are using `DynamicCluster` and more
> specifically, `cluster.first.entity` sensor on cluster members.
> There was a change introduced by this PR[1] that removes the sensor from
> cluster members. This breaking change was merged to fix a potential
> deadlock of the Brooklyn server. The sensor is still present at the cluster
> level though, so DSL users can still get it from members with the following:
> $brooklyn:parent().attributeWhenReady("cluster.first.entity")
> This affects only the bleeding-edge Brooklyn, *not the latest stable
> release*.
> Cheers.
> [1]

View raw message