@vasily-kirichenko i tested it 1-2 weeks ago, if you have 3 seed nodes u need to change the seed order, so that the self-entry is at the end, else u will get a split instantly if the first seed node restarts. Node2-3 are UP and valid. Node1 restarts and joins itself instantly and waits for other nodes to connect "init-face".
I am using a ClusterRouterGroup router with currently one routee. But if the routee node restarts and joins the cluster. I looks like that no message are not delivered there anymore. If a node goes down should the routee no be removed and if the node rejoins readded to the ClusterRouterGroup ?
A couple of questions around Hyperion I was unable to find answers for:
- Why the fork from Wire, how does it differ?
- Will it remain binary-compatible with Wire? Asking because ServiceStack uses Wire and the option of direct data exchange might be useful.
- Does this still hold true? https://gitter.im/akkadotnet/akka.net?at=59bec683177fb9fe7ed1bf76 - I don't intent to use it for persistence, but I could see using in a gateway MQ, which would have the same issues (although probably less likely to occur).
Wonder if anyone can help explain how the ActorBase.Context works. I'm doing some async work which will use Context.Sender to reply. Am I right in thinking if I grab the context before it will remain correct for the actor? If I do it lazily i get "There is no active ActorContext, this is most likely due to use of async operations from within this actor"
@chrisjhoare Context is realized over thread-static fields. If you are using any value from Conext in an other thread (async or not) u will need to copy it into the state.
var sender = Context.Sender;
myTask = Task.Run(async () => {
sender.Tell("hallo");
});In general u can use the IActorRef.PipeTo(...) extensions to send back a message/result on completion.
Task.Run(async() => {
return "hello";
}).PipeTo(Context.Sender);
@drittich
- Back in the days Wire was converted to use GPL licensing model which is a no go for most commercial stuff. It was forked prior this point, and that's how Hyperion was made.
- It won't be binary-compatible. Changing the encoding is one of the major tasks to be done there.
- Yep. The general premise is not to use it for data to be stored/replayed for long time. Once encoding will change it will be hard to read older scheme.
and still down the stream itself
I see it in akka jvm docs, I guess it may have been added after we ported that part
i create a topic akkadotnet/akka.net#3903
What i currently see is that RemoteDeploy and Streams have this behavior that both can pass unknown-exception-types to remote systems/nodes
If you'd replace dotnetty with another TCP implementation, it would be possible
@vladmir-boy yes it's possible, but I wouldn't assume it's an easy task. I think, you should be able to get all necessary documentation here: https://getakka.net/articles/remoting/transports.html#using-custom-transports
@Mun1z Most likely yes, but it depends of the game. The main benefit will be that there will be no locks (synchronisation) for user-states and world interactions. Clients would be served as fast as possible. But if your game-server/client can handle everything in a single message loop on 3Ghz, i want border that much to replace it with actor model.
Probably a trivial question but I forgot the answer. Suppose in the mailbox of an actor we have messages m0 .. m5 all different object types.
m0 is delivered first and the state of the actor changes to a state that only has a
I forgot what happens to the messages m1..m4. Are they kept in the mailbox or are they sent to the actor and not processed?
m0 is delivered first and the state of the actor changes to a state that only has a
Receive defined for the type of m5.I forgot what happens to the messages m1..m4. Are they kept in the mailbox or are they sent to the actor and not processed?
@HermansG Every message is picked from the mailbox and get processed in order. If u want to postpone messages, you will need to resend it to the current actor again
or stash it with IWithUnboundedStash and
Context.Self.Tell(msg, Context.Sender);or stash it with IWithUnboundedStash and
Stash.Stash(); and after Stash.UnstashAll();
Hey I have a question about event adapters and their support across persistence plugins. In short, I am trying to use an event adapter to serialise protobuf-net dtos using InMemory, Sql and Mongodb (through cosmosdb/documentdb emulator engine). I'm unsure if my event adapter implementation is incorrect or if there is a problem with the compatibility among different persistence drivers.
I have put together a solution with each of the three mechanisms (with tests) here:
https://github.com/ctrlaltdan/akka-event-adapters
Any help would be appreciated :D
and after the persistent system passes byte[] again to the eventadapter and u are returing byte[]+String.Empty
on loading, you will get byte[]+string.empty again back
just remove
""System.Byte[], System.Private.CoreLib"" = protobuf
I have an other question and i fought that i resolved it, I have in a k8s cluster 3 seed nodes
i am using static-quorum of size 2 as split blrain resolver
To resolve this problem, i changed the seed-node list on each seed node, so it's own entry is at the end of the list
Node0 => node1,node2,node2
Node1 => node0,node2,node1
Node2 => node0,node1,node2
It was fine for a while
But now node0 restarted on some point in the last days and joined itself again and formed a new cluster