Remote + Cluster = what?

[rogeralsing]

Are Akka.Remote and Akka.Cluster supposed to be able to be used together?

If I expose an actor in a cluster node, e.g. Petabridge Lighthouse.
And then try to reach that actor using normal remote from a non cluster node, it does work and I can pass messages to the actor on the cluster node.
But after the message have been processed, the cluster node throws a protocol exception.

Are non cluster systems supposed to be able to connect to individual cluster nodes?

• If yes, why does it disconnect and throw?
• If no, why can I connect and pass messages to actors on the cluster nodes?

[smalldave]

Clustering is built on top of remote.
Fundamentally clustering just gives you a way to detect and monitor other actor systems.
Sounds like a bug.
What is the protocol exception?

[rogeralsing]

This:

Akka.Remote.Transport.ProtocolStateActor: Underlying transport closed.
Akka.Remote.Transport.ProtocolStateActor: Underlying transport closed.
Akka.Remote.EndpointWriter: AssociationError [akka.tcp://webcrawler@127.0.0.1:4053] <- akka.tcp://MyClient@localhost:65243: Error [Shut down address: akka.tcp://MyClient@localhost:65243] [   at Akka.Remote.EndpointReader.HandleDisassociated(DisassociateInfo info)
   at Akka.Remote.EndpointReader.OnReceive(Object message)
   at Akka.Actor.UntypedActor.Receive(Object message)
   at Akka.Actor.ActorBase.AroundReceive(Receive receive, Object message)
   at Akka.Actor.ActorCell.ReceiveMessage(Object message)
   at Akka.Actor.ActorCell.Invoke(Envelope envelope)]
Akka.Actor.OneForOneStrategy: Shut down address: akka.tcp://MyClient@localhost:65243

[rogeralsing]

So I take it that it should be possible to remote into cluster nodes w/o affecting the cluster topology, right?

e.g. if we have a cluster for computation services and then let workstations use remote to communicate with that cluster.

[smalldave]

Yes but the cluster is dynamic so how do you know who to talk to? You could arbitrarily nominate some nodes as entry points into your compute cluster. Guess the seed nodes would be a good choice for that. You'd still need to check the node you want to talk to is available.
I think the ClusterClient extension is designed to ease this a bit.

[rogeralsing]

I'm thinking there could be fixed nodes in the topology.
e.g. a webserver with an actorsystem that fronts http requests. and then dynamic nodes for compute power that comes and goes.
That cant be a totally unrealistic senario (?)

[smalldave]

Nope. But why not make webservers part of the cluster?

[Aaronontheweb]

Nope. But why not make webservers part of the cluster?

I agree with this. Just make the webservers part of the cluster.

The only nodes that shouldn't be part of a cluster are clients - i.e. desktop / mobile / embedded clients that aren't perpetually always on. Anything that fundamentally acts as a server of some sort should just be part of the cluster.

[Aaronontheweb]

Marking this as a bug.

[skotzko]

@Aaronontheweb please check up on this per our convo this AM

[HakanL]

Maybe a little out of scope, but can a ClusterClient connect in to a cluster (via the seed nodes) and send/receive messages as if it was a full-blown node, or how does it differentiate from a regular node? I'm looking into how to handle a client who is very unreliable, but still want to send/receive (actually Tell/Ask) messages into the cluster, not caring who in the cluster responds.

[Aaronontheweb]

Looking into #1700 and am porting the Cluster.Tests.MultiNode.RestartNodeSpec to tackle that bug, and ran into this. Definitely a bug by design. Looking into it now

[Aaronontheweb]

Cluster nodes that are not joined in the cluster can communicate via Akka.Remote - confirmed that this works via multi-node test in #1821.

As for a node that isn't running Akka.Cluster to communicate via Akka.Remote with the Cluster, I'll need a separate setup for that.

[Aaronontheweb]

This is fixed - verified in our deathwatch specs and elsewhere for Akka.Cluster.