Non-static GrainClient #2822

ReubenBond · 2017-03-07T03:21:51Z

This PR implements the majority of the remaining items in #467. With this PR merged, an end-user can

Call into multiple separate clusters from a client
Call into multiple other clusters from within one cluster

The core abstraction which this introduces is IClusterClient, which implements IGrainFactory. It is implemented by the public class ClusterClient. ClusterClient has static Create methods which match the existing GrainClient.Initialize methods with the major difference that they create and do not start the client. A client is started via a call to Start, which is asynchronous.

This does not implement support for automatically binding GrainReferences to their originating cluster, but there is an IGrainFactory.BindGrainReference(ref) method for that purpose - so users aren't completely stuck. The plan is to implement those kinds of features later on, probably leveraging the clusterId concept from GeoClusters.

Calling from one grain into multiple other clusters:

public class ConnectorGrain : Grain, IConnectorGrain
{
    private readonly IClusterClient clientOne = ClusterClient.Create(
        new ClientConfiguration
        {
            Gateways = new List<IPEndPoint>(new[] {new IPEndPoint(IPAddress.Loopback, 11112)}),
            PreferedGatewayIndex = 0
        });

    private readonly IClusterClient clientTwo = ClusterClient.Create(
        new ClientConfiguration
        {
            Gateways = new List<IPEndPoint>(new[] {new IPEndPoint(IPAddress.Loopback, 22222)}),
            PreferedGatewayIndex = 0
        });

    public override async Task OnActivateAsync()
    {
        await base.OnActivateAsync();
        await this.clientOne.Start();
        await this.clientTwo.Start();
    }

    public async Task<string> Three()
    {
        var one = this.clientOne.GetGrain<IOneGrain>(Guid.NewGuid());
        var two = this.clientTwo.GetGrain<ITwoGrain>(Guid.NewGuid());
        return await one.One() + " + " + await two.Two();
    }
}

Similarly, for standalone clients:

var clientOne = ClusterClient.Create(CreateConfig(11112));
var clientTwo = ClusterClient.Create(CreateConfig(22222));
var clientThree = ClusterClient.Create(CreateConfig(33332));

await Task.WhenAll(
    clientOne.Start(),
    clientTwo.Start(),
    clientThree.Start());

var one = clientOne.GetGrain<IOneGrain>(Guid.NewGuid());
var two = clientTwo.GetGrain<ITwoGrain>(Guid.NewGuid());
var three = clientThree.GetGrain<IConnectorGrain>(Guid.NewGuid());

while (!Console.KeyAvailable)
{
    Console.WriteLine($"{one}: {await one.One()}");
    Console.WriteLine($"{two}: {await two.Two()}");
    Console.WriteLine($"{two}: {await three.Three()}");

    await Task.Delay(TimeSpan.FromSeconds(1));
}

ReubenBond · 2017-03-07T12:45:07Z

I've tagged this as a work-in-progress for now. The biggest change intended for the final version is to make the client startup asynchronous

… obsolete

…RuntimeClient

ReubenBond · 2017-03-08T11:30:25Z

Alright, the IClusterClient.Start() method in the latest revision is async :)

jdom · 2017-03-08T22:44:33Z

What is the reasoning for having to call Start? Should we separate the creation of the ClusterClient into something that returns an already initialized client? Close(Async) still makes sense, kind of like an async Dispose method, but it sounds like initializing shouldn't be done on the ClusterClient. What do you think?
On a separate note, we were talking with Jason that we could avoid having a static Create method on it, and separate it into ClusterClientBuilder or something of the sort, with a configuration a little bit closer to asp.net (or EF, since it's a client library). Of course this can be after the PR is merged.

ReubenBond · 2017-03-08T22:50:50Z

For example, consider this flow:

Create client
Wire up event handlers (cluster disconnect, client request, maybe some custom ones from the service provider)
Start the client

That flow has no chance of race conditions, whereas the following does

Create & start the client
Wire up handlers

Additionally, I believe creation should be synchronous, whereas connecting to a cluster is async.

I'd be happy if we had a ClientBuilder, but I figured that change should coincide with a similar change on the silo side and at the same time, we should allow the user to provide their own DI container (and inject their own services).

jdom

Some small comments I started to write. Sending them since we also synced in person. I'll continue reviewing anyway.

jdom · 2017-03-08T22:53:39Z