Introduce 'MemberDowned' member event #25854
Conversation
Compatiblity note: MemberEvent is a sealed trait, so it is debatable whether it is acceptable to introduce a new member.
| @@ -317,6 +317,8 @@ object ClusterSingletonManager { | |||
| case state: CurrentClusterState ⇒ handleInitial(state) | |||
| case MemberUp(m) ⇒ add(m) | |||
| case MemberRemoved(m, _) ⇒ remove(m) | |||
| case MemberDowned(m) if m.uniqueAddress != cluster.selfUniqueAddress ⇒ | |||
| remove(m) | |||
There was a problem hiding this comment.
That is a too scary change.
Note that MemberDowned will happen immediately since Down is an external/user action, while in contrast MemberExited is after convergence on leader and such.
Let's ignore MemberDowned in singleton.
| @@ -247,6 +247,7 @@ final class ClusterSingletonProxy(singletonManagerPath: String, settings: Cluste | |||
| case state: CurrentClusterState ⇒ handleInitial(state) | |||
| case MemberUp(m) ⇒ add(m) | |||
| case MemberExited(m) ⇒ remove(m) | |||
| case MemberDowned(m) ⇒ remove(m) | |||
|
Agreed, will change things to be more conservative. I guess we could make this more compatible by making |
|
Test FAILed. |
|
Test FAILed. |
|
Test PASSed. |
In lightbend-labs/mima#200 I argue that it's a form of binary breakage, one that MiMa should warn against. But in Montreal Adriaan didn't really agree with me, while Seth did, so current it's 2 vs 1. 😉 |
|
@dwijnand yes, I agree it'd be helpful if MiMa warned against it, but whether it is acceptable to ignore that warning is a harder question |
|
Btw, I got paranoid that https://github.com/lightbend/reactive-lib/blob/master/akka-cluster-bootstrap/src/main/scala/com/lightbend/rp/akkaclusterbootstrap/ClusterStatusCheck.scala would break from this. But that's So I checked and it doesn't look like there is any exhaustive pattern matching on |
Compatiblity note: MemberEvent is a sealed trait, so it is debatable whether
it is acceptable to introduce a new member.