These are chat archives for akkadotnet/akka.net

12th
Sep 2016
Yin Zhang
@melcloud
Sep 12 2016 00:16
@corneliutusnea Ah, sorry. Got you. You are talking about nodes in same cluster. Then your scenario is fine. LH will act as the seed node for this purpose.
which means C1 and C2 will form a cluster and gossip to each other
Corneliu
@corneliutusnea
Sep 12 2016 00:29
but in my scenario C1 and C2 can't reach each other, I'd like them to ONLY talk via the LH
Yin Zhang
@melcloud
Sep 12 2016 00:32
but if C1 and C2 cannot reach each other, how can they be the same cluster?
Corneliu
@corneliutusnea
Sep 12 2016 02:20
well, a cluster is a logical entity
but there is a firewall in between them that I can't get rid of :(
Bartosz Sypytkowski
@Horusiath
Sep 12 2016 05:08
@corneliutusnea cluster nodes can communicate directly with each other. Lighthouse is used only to form the cluster.
also don't use cluster client when you can just call actors or use distributed pub/sub - cluster client is basically distributed pub/sub with ability to reach the cluster from the outside
Corneliu
@corneliutusnea
Sep 12 2016 05:15
@Horusiath I don't plan to use the cluster client but I don't have (atm) to make the cluster nodes talk to each other when they are deployed as Azure Web Site instances. They can happily talk to the LH which is in the same VNet but not in between them :( so I'm looking for alternatives to have the cluster still working without the nodes being able to talk to each other directly
Arjen Smits
@Danthar
Sep 12 2016 09:12
@corneliutusnea Your putting yourself in a really difficult situation. The akka cluster is specifically designed and engineered to have p2p connection to each member in the cluster. All kind of things depend on that. So if you are going to deviate from that design you will run into all kinds of problems with mechanisms that detect if a node is down or unreachable.
I think, your best bet in this would be to remove your website from the cluster, and use a proxy node that is part of the cluster, that can talk to the cluster on behalf of the website.
the website could use remoting to communicate with the proxy, while the proxy uses the normal mechanisms
however your proxy would have to be specifically engineered to suit its role as a proxy for your website.
Bartosz Sypytkowski
@Horusiath
Sep 12 2016 09:49
at least it's possible :P
Corneliu
@corneliutusnea
Sep 12 2016 10:21
@Danthar I understand ... I just really wanted to use the power of the websites to run the cluster. If I have more nodes (e.g. cluster dedicated nodes != websites) = more resources = more $
If I move away from Web Service to Cloud Service = more management
I know ... I want to have my cake and eat it to .. two of them ... in a cluster ... for free .. :)
Arjen Smits
@Danthar
Sep 12 2016 12:07
Well, building a proxy would still help you. Yes costs would be higher, but it would be linear and in a predictable way. It just slightly raises the costs if adding a new website node. But you could still run those proxies all on one VM if you want. That way the cost of adding a new website node, would go down the more website-nodes you have.
Corneliu
@corneliutusnea
Sep 12 2016 12:09
yes, my plan was to write a proxy and run it on the LH .. or hope there is such a proxy already on the LH :D
Arjen Smits
@Danthar
Sep 12 2016 12:10
No there is not.
The lighthouse is a baremetal actorsystem instance. The only thing it does is join a specified cluster
and run the basic cluster infrastructure that every cluster node does
So its role is to act as a seed node for bootstrapping your cluster
It does not do anything else
A proxy implementation would basically have to be the "cluster" version implementation of your website.
Where it knows how to act on messages received by your website, and knows that it, for example, needs to subscribe in some cluster-pubsub
and send any responses from that, back to the website
Thats what i meant with that your proxy would have to be specifically engineered to suit its role as a proxy for your website.
And thats why there is no generic cluster proxy thingy
Vlad Kosarev
@vladkosarev
Sep 12 2016 12:15
Remoting doesn't work for azure websites right now anyway so you can't even do that
Arjen Smits
@Danthar
Sep 12 2016 12:16
If remoting does not work, then clustering would not work either, since it uses the same infrastructure underneath
Vlad Kosarev
@vladkosarev
Sep 12 2016 12:16
yes, clustering never worked, remoting broke in 1.1
remoting has been fixed in dev branch but hasn't been released yet
Arjen Smits
@Danthar
Sep 12 2016 12:17
ah, yep
Mike Johnson
@softwaremike
Sep 12 2016 19:41
Are you saying remoting doesn't work at all in 1.1 or just for azure websites? I just updated my 1.0 project to 1.1.1 a few minutes ago and we use remoting between several processes..
Bartosz Sypytkowski
@Horusiath
Sep 12 2016 20:00
@softwaremike v1.1.1 works normally. @Danthar meant azure websites. Do we have ticket for that?
Arjen Smits
@Danthar
Sep 12 2016 20:01
@Horusiath I am not sure. It has come up several times. But i think it was related to a bug in how we resolved hostname's at first, and later on ipv6 issues. Which afaik both have been resolved
I think this played largely during your vacation ;)
Mike Johnson
@softwaremike
Sep 12 2016 20:13
@Horusiath OK thanks!
Next problem - I upgraded all my projects across the board to 1.1.1. When the actor system starts up, I now get this exception:
Logger [Akka.Event.DefaultLogger] specified in config cannot be loaded:
System.MissingMethodException: Method not found: 'System.Type Akka.Dispatch.Mailboxes.GetMailboxType(Akka.Actor.Props, Akka.Configuration.Config)'.
at Akka.Remote.RemoteActorRefProvider.ActorOf(ActorSystemImpl system, Props props, IInternalActorRef supervisor, ActorPath path, Boolean systemService, Deploy deploy, Boolean lookupDeploy, Boolean async)
at Akka.Actor.ActorCell.MakeChild(Props props, String name, Boolean async, Boolean systemService)
at Akka.Actor.ActorCell.AttachChild(Props props, Boolean isSystemService, String name)
at Akka.Actor.Internal.ActorSystemImpl.SystemActorOf(Props props, String name)
at Akka.Event.LoggingBus.AddLogger(ActorSystemImpl system, Type loggerType, LogLevel logLevel, String loggingBusName, TimeSpan timeout)
at Akka.Event.LoggingBus.StartDefaultLoggers(ActorSystemImpl system)
My HOCON config is very simple:

akka {
actor {
provider = "Akka.Remote.RemoteActorRefProvider, Akka.Remote"
}

remote {
    helios.tcp {
        port = 8092
        hostname = localhost
    }
}

}

Mike Johnson
@softwaremike
Sep 12 2016 20:18
Anyone seen this exception before?
Mike Johnson
@softwaremike
Sep 12 2016 20:46
Never mind, ignore that... one of my projects still had Akka.Remote 1.0.8 it its references :) oops!