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.
Best
Alex
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] https://github.com/apache/brooklyn-server/pull/777
