These are chat archives for akkadotnet/akka.net

18th
Jan 2019
Onur Gumus
@OnurGumus
Jan 18 08:34
@jameswilddev , the problem is if all your seed nodes die, when they start again they will form up a different cluster.
from scratch.
What is the purpose of existence confirmed in watch termination ? docs are confusing.
jameswilddev
@jameswilddev
Jan 18 09:46
@OnurGumus That's what I'm seeing yeah and I take it this is intentional and there's no way (even manually) to rejoin that cluster to those reincarnated seed nodes?
Bartosz Sypytkowski
@Horusiath
Jan 18 11:22
@jameswilddev you can join cluster by joining to address of any node, that you know it's part of the cluster
jameswilddev
@jameswilddev
Jan 18 11:23
@Horusiath But you can't in this scenario because it looks like a node can only join a cluster once. The "orphaned" cluster's nodes are already in a cluster and the new seed node considers itself in a cluster even though it's alone.
Bartosz Sypytkowski
@Horusiath
Jan 18 11:23
the case is that usually people have limited set of nodes with known address (seed nodes) and a lot of nodes with dynamic addresses
jameswilddev
@jameswilddev
Jan 18 11:24
Indeed and this isn't any different, but sometimes those seed nodes have to be restarted or completely fail
Bartosz Sypytkowski
@Horusiath
Jan 18 11:25
if I remember correctly in docs there's a note, that you should have more than one seed node, this way if you need to restart them, you can do that one by one
jameswilddev
@jameswilddev
Jan 18 11:26
But if they were all to go down there's no recourse other than to restart every other node?
Bartosz Sypytkowski
@Horusiath
Jan 18 11:26
no, you still can connect, but then it's up to you to discover addresses of alive nodes
it's simple: if you want to connect to cluster, you must know address of at least one node that is part of the cluster already
jameswilddev
@jameswilddev
Jan 18 11:27
I guess if there's something we can do to tell that lone seed node about the rest of the cluster or vice versa
But if there's not we have no choice but to restart every node
Bartosz Sypytkowski
@Horusiath
Jan 18 11:28
(also something that people often forget about is to set up downing strategy, so that cluster won't wait for dead nodes)
jameswilddev
@jameswilddev
Jan 18 11:28
We can't connect to the cluster because the seed node thinks it's already in a cluster (of itself) and the rest of the cluster already is in a cluster
I thought we weren't supposed to use auto-downing in production because it risks split brain in the event of a network partition?
Bartosz Sypytkowski
@Horusiath
Jan 18 11:30
there are different split brain resolvers - a bit more clever beasts than auto-down
jameswilddev
@jameswilddev
Jan 18 11:46
I'll have to do some research into whether they could resolve the scenario I'm describing; one member cleanly exiting the cluster then popping up in its own separate cluster on restart doesn't sound like it's something split brain resolution would fix.
I guess we could maybe hook the cluster event for when a node leaves and if it's the last seed node restart
(after a delay to give said seed node time to start)
Bartosz Sypytkowski
@Horusiath
Jan 18 13:06
@jameswilddev I've created a plugin, which registers akka nodes inside consul and uses it for cluster discovery (see: https://github.com/Horusiath/akka.cluster.discovery ) - but in greater scheme of things, the problem is still the same, just applies to consul nodes instead of akka nodes
also I don't see why would you down all seed nodes (i.e. 3 of them) at once: it's highly unlikely to happen under normal scenario (unless you keep them all on a single machine or entire DC goes down)
Onur Gumus
@OnurGumus
Jan 18 13:23
@jameswilddev you should not allow all seeds nodes down unless you can afford full cluster restart.
That's why you can define more than one seed nodes.
If you want you can make all nodes as seed nodes.
As long as they are known.
jameswilddev
@jameswilddev
Jan 18 13:24
Most members of the cluster don't have fixed IPs (autoscaling). Looking to keep the number of seed nodes to a minimum (cost, operational overheads)
And sometimes things don't go as planned.
Onur Gumus
@OnurGumus
Jan 18 13:25
Then use multiple light house
it is not hard to guarantee this.
jameswilddev
@jameswilddev
Jan 18 13:26
Correct, it's actually impossible (halting problem :)). I'll see if we can stretch to two.
Onur Gumus
@OnurGumus
Jan 18 17:01
if you watch a remote actor and if that remote actor temporarily disconnected, you get termination message. however if connection is reestablished, existing actor references continue to function. I find this behavior inconsistent.
voltcode
@voltcode
Jan 18 19:36
Hi guys, a perhaps quick question - what's the recommended approach to link akka actor(s) to user session in an asp net application? Until introduction of akka, asp net session was the main mechanism to store user-related data. Now, I'd like to migrate towards and akka-based state management to make the application more reactive and better composable with other services. What would be the preferred approach so that I don't have to work against asp net mvc all the time? Move towards an actor per user pattern and put entire session, while replacing all session references with tells and asks ? Is there a better way? Do I have to get rid of the session object, or maybe there's a way to put the session inside the user's actor ?
voltcode
@voltcode
Jan 18 20:12
Most of the examples I can find, are stateless web api examples that just forward everything to Akka, without mentioning authentication, authorization ,etc etc.