Skip to content
This repository has been archived by the owner on Apr 15, 2018. It is now read-only.

Risk of island creation if max-nr-of-seed-nodes < actual number of seeds and host is reused #159

Open
octonato opened this issue Apr 19, 2017 · 2 comments

Comments

@octonato
Copy link

In ConstructrMachine.scala line 197

  private def seedNodes(nodes: Set[Address]) =
    nodes.take(maxNrOfSeedNodes).toVector

The following scenario can happen:

nodes = Set(addressA, addressB, addressC, addressD, addressE, addressF)
max-nr-of-seed-nodes = 3

addressA, addressB and addressC have crashed and infrastructure is redeploying new nodes. While redeploying, hosts are reused. So, for instance, new node gets same IP and port as addressC.

If seedNodes method returns by accident (is a Set) exactly the same nodes that are gone (ie: A, B and C). A node trying to join with addressC will be unable to see addressD, addressE and addressF and will happily make a cluster with himself because his host is on the list of returned addresses.

Obviously this only happens when max-nr-of-seed-nodes is set to something different to the default. I guess this property is most useful for large clusters to avoid sending join request to a large number of nodes, however the risk still exists.

Not sure what could be a good solution for this though.

@jasongoodwin
Copy link
Contributor

Because a cluster should never be created when "Joining" in constructr, it seems important that the self address can never be provided in the seed node list passed to Akka. It might make sense for Constructr to log a warning, then filter or fail if it sees the self address in the first spot to ensure that nobody accidentally configures their system in a way that would allow two clusters to form.

@hseeberger
Copy link
Owner

Good catch!
I will rework general semantics soon (single cluster formation), then this should be resolved.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants