Starting member with dynamically allocated port about scalecube-services HOT 9 CLOSED

Actually if you run this code right now:

ICluster clusterA = Cluster.newInstance().join();

It will start transport on default port 29001.

from scalecube-services.

Dynamically allocated means on nodes start on default port 29001 + 1
After enhancement it will be possible to run on same vm several cluster instances:
...
ICluster clusterA = Cluster.newInstance().join(); -- > starts on default port
ICluster clusterB = Cluster.newInstance().join(); ---> starts on default port +1

from scalecube-services.

We can do dynamically allocated ports, but there is one problem here.
Cluster creates transport instance in newInstance() method, but start in join() method.
This will cause situation when next code will not work as expected

for (int i = 0; i < 10; i++) {
      clusters.add(Cluster.newInstance());
    }
 for (ICluster cluster : clusters) {
      cluster.joinAwait();
    }

I wonder why we really need to separate newInstance from join?
@antonkharenko @ronenhamias WDYT?

from scalecube-services.

IMHO there are 2 options:

Option 1 (base port)
ICluster clusterA = Cluster.newInstance(3000).join(); // start on port 3000
ICluster clusterB = Cluster.newInstance(3000).join(); // start on port 3001 since 3000 is taken.

Option 2 (port 0)
it means that these 2 lines are the same:
ICluster clusterA = Cluster.newInstance().join();
ICluster clusterA = Cluster.newInstance(0).join();

from scalecube-services.

Don't you think that this approach might lead to unpredictable behavior?
Zero configuration == good defaults, but it does not mean "find some random port just to do not fail".
What if some other application already uses this port (for example, old server instance that was not killed / stuck), and correct behavior in this case should be just fail to start?

from scalecube-services.

@kshchepanovskyi Basically idea is somewhat similar to what Hazelcast do (see http://docs.hazelcast.org/docs/3.3/manual/html/ports.html) that it doesn't find some random port, but search in the configured ports range (with meaningful defaults) for the free port to bind. If all ports from the configured range are bound then fail. Having only one port basically is just a special case of port range where this range contains single element.

from scalecube-services.

@antonkharenko

Ok, with "automatic cluster node discovery" - similar to Hazelcast's multicast/tcp - it might be good idea.

Anyway, there still are few tricky moments.

1. Hazelcast always checks if service that listens on remote port is actually hazelcast.
2. Hazelcast has a concept of "cluster name". Cluster nodes should check remote node's "cluster name" so that they are confident they do not connect to wrong node.

That's why I consider this feature danger.

Motivation: streamline testing and development and deployments with zero configuration.

If we do not handle all corner cases, instead of improving things we can make them only worse.

from scalecube-services.

@kshchepanovskyi Basically automatic node discovery is supported via seed members (it means you need to provide address of at least one existing node on cluster join to discover all other nodes in the cluster). It is not supported multicast discovery (as for now) since it I am not sure it has much value outside of demo or dev environment - multicast often disabled.

Also we have the concept of "cluster name" too. It is called "syncGroup" and it is a part of cluster configuration (ClusterConfiguration.ClusterMembershipSettings.syncGroup) which you can set to arbitrary string identifier. In addition to that Transport send handshake messages on connect so basically node on the other end need to run Transport too in order to pass handshake.

from scalecube-services.

Done at PR: #57

from scalecube-services.