yeah I'd just have the actor fire up a new client on each request like you're doing then
the joys of prototyping :smile:
we use them in NBench / Helios / DotNetty
all of those can run on Mono
Hi I'm using the Supervisor to catch the exception. But How can I get the message in Supervisor so that I can re-read the message again? thank you.
@Silv3rcircl3 thank you. i read it later. I'm writing the demo with books.
@Aaronontheweb reading the documentation on Akka.Cluster in the web crawler example project, in the section on ASP.NET integration (https://github.com/petabridge/akkadotnet-code-samples/tree/master/Cluster.WebCrawler#best-practices-for-aspnet-and-akkanet-integration) the router is created with a RemoteJobActor. But that don't match the actual code in the repo, where the router is created with Props.Empty (https://github.com/petabridge/akkadotnet-code-samples/blob/master/Cluster.WebCrawler/src/WebCrawler.Web/Global.asax.cs#L23). Maybe the readme should be updated to reflect this to avoid confusion
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
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
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 option could be to make sure certain actors are recreated after a reboot or a machine missed? :S
@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)
eventually something like redis would do the job
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():
any clue what might cause this?
Not Flagged > 12944 8 Worker Thread akka.remote.default-remote-dispatcher_1 Akka.dll!Helios.Concurrency.DedicatedThreadPool.UnfairSemaphore.Wait Normalany clue what might cause this?
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