@Horusiath hey, thanks for the response. I ve just updated from 1.6 to the latest beta and everything works just fine. Thanks a lot for the amazing sharding module.
I have some questions about Akka.NET and cluster routers. Hope someone can help me clear things up...
As far as I understand it, in order to pass messages between nodes in a cluster, the message must go through a a cluster-aware router. Correct?
And for that I can either use a group or pool router. Difference is that the group router sends the mesasge to predifned routees that might or might not exist at the target node. The pool router on the other hand deploys its routees on the target node. Correct?
For deciding where to route message (and in case of pool router, deploy routees), the use-role property in the cluster part of the deployment config is used. Correct?
@peter-bannerflow 1: A cluster-aware router is a piece of infrastructure that makes it easier for you to communicate with the cluster as a whole. It adds a level of abstraction. You can communicate with nodes in your cluster directly if you want. But in order to do this properly you'd end up rebuilding alot of the management stuff that a cluster aware router already does for you. But if the out-of-the-box (OOB) cluster routers dont fit your use-case. You can certainly do this. 2: Yes 3: Yes
@Danthar ok, thanks for verifying my assumptions
What about if I pass an IActorRef in a message to some other node in the cluster, will an actor receiving that message be able to send a direct message to that IActorRef?
I'm looking at some logs here, and I'm noticing that the "Association failure ---> Akka.Remote.Transport.AkkaProtocolException: The remote system has a UID that has been quarantined. Association aborted." eventually turns into a "Akka.Remote.Transport.InvalidAssociationException: Association failure ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown."
Another odd behaviour is that I'm still getting Association failures after I downed the address. The cluster state shows the status is down. Do I also have to call leave on the address to stop association attempts?
Hi! I have just left a question on stackoverflow. Basically is which is the best way to assure that a timeout message is sent, maybe some could help. Thanks!
this is hard case when you try to think about consistency i.e. should it be allowed to call the same scheduled timeout twice?
that would be ok. The actor could discard the second message. But I have to make sure it gets there, we have business timeouts
another option could be to make sure certain actors are recreated after a reboot or a machine missed? :S
this would require to have some scheduler working on each node and distributed "database" where the timeout requests would we written to, so they could be taken over by other nodes in case of unexpected crash
@pablocastilla with cluster sharding I guess you could
(but I haven't checked if actors would be recreated in case of crash, only when migrated between machines)
Bart de Boer
@pablocastilla I suggested a solution at SO
so I would have to write it, wouldn't I?
also for the first case ddata module would be good, but it's still in development
eventually something like redis would do the job
@boekabart I think I got the idea and it should work. Thanks so much. Tell me what you think about the comments plz
Bart de Boer
After wrapping my Akka.Remoting application in a Topshelf service, it won't quit anymore. CTRL-C does 'stop' the service OK, but then the process hangs (with the console window open). Attaching a debugger shows 6 threads waiting for UnfairSemaphore.Wait(): Not Flagged > 12944 8 Worker Thread akka.remote.default-remote-dispatcher_1 Akka.dll!Helios.Concurrency.DedicatedThreadPool.UnfairSemaphore.Wait Normal any clue what might cause this?
Bart de Boer
@Aaronontheweb any idea what those threads are actually waiting for?
@boekabart that's what the ForkJoinDispatcher runs on top of
as for why they're all waiting - should be because they're expecting work
however, if you're terminated the actor system by then
and they still aren't shutdown
it means we're not properly disposing of them
Bart de Boer
according to the log, remoting is correctly shut down