@Aaronontheweb I'm beginning my work on that "ReliableMessageBroker" that we spoke about a few weeks ago. Where should that live? In the pubsub as above?
Or should this be in its own folder?
@Aaronontheweb Thanks, I am looking forward to 1.1.1. Meanwhile I could solve all leaving issues. As you said before, it is very important to give the actor system the time to complete the leave process. Also I have built myself a helper app which can down abandoned nodes.
So the last problem was that I got one ASP.NET core project which seemed not to be able to complete the leave. It was different in how the ActorSystem was created. In the problematic project I created the ActorSystem inside a lambda which worked as implementation factory to the IServiceProvider of ASP.NET. My ActorSystemProvider is now a separate service class and it now works out. Not sure, maybe it got something to do with the thread context where the actor system had been created.
Would you like to investigate on that? I would then try to add a sample for the failing to the GitHub repo.
So the last problem was that I got one ASP.NET core project which seemed not to be able to complete the leave. It was different in how the ActorSystem was created. In the problematic project I created the ActorSystem inside a lambda which worked as implementation factory to the IServiceProvider of ASP.NET. My ActorSystemProvider is now a separate service class and it now works out. Not sure, maybe it got something to do with the thread context where the actor system had been created.
Would you like to investigate on that? I would then try to add a sample for the failing to the GitHub repo.
If I want to broadcast a message to all children of an actor, what would the preferred way of doing that be? Would it be to do a Context.GetChildren() and then iterate over that. Or is it more efficient to use a broadcast-group-router? The children needs to be created excplictly in a specific workflow so I cannot use a pool router.
Hi. I'm evaluating Akka.net, and I'm trying to figure out on what level to use it in a WPF application. I cannot find any solid info about it, so I hope to get some input here.
As it stands, I'm using an CQRS approach, in which I send commands to PersistentActors, and PersistentView (to be PersistenceQuery I believe) to get the data. Is it "the wrong way" to have my viewmodel depend on the IActorRefFactory, and create the View/Query actor to populate the viewmodel with data?
@peter-bannerflow I would go with the iterate over Context.GetChildren approach()
@Danthar for efficiency or just because it's less work than configuring a router?
@hvidgaard I have watched a nice Pluralsight course on WPF MVVM and Akka.NET. If you got a pluralsight subscription I would recommend that.
@hvidgaard If you are familiar with WPF and MVVM, it is basically having the actor system doing the work and where you have interactions between UI and worker actors, those viewmodels get dedicated actors which get the VM in their constructor. These bridges will populate changed to the UI by changing the viewmodels where PropertyChanged will doing necessary marshalling. Other approaches might have actors bound to the UI dispatcher but this bridge approach per VM is working quite nice at the moment for me.
@ZoolWay So using a prop to pass VMs to the actor - but that means coordinating it such that when creating a view, a VM and actor pair needs to be created as well. It doesn't seem like a fit for Prism with SimpleInjector, unless the VM creates the actor. I can see that work, albeit some abstraction and indirection is lost.
I am not familiar with Prism here but using Caliburn.Micro with a VM-first approach. Does feel really easy to have those VMs which interact create their bridge actor.
Also there might be other approaches as well.
Also there might be other approaches as well.
I'll try to have the VM create the actors it need through a factory. How about lifecycle management in this case? When a view is recycled, the VM and Actor is now dead in the water. I could use a weakref in the actor to the VM and send a Stop in the destructor of the VM. It just feels too manual. Any insight on this?
Hello I would like to know when I have this in my App.Config file
akka { stdout-loglevel = DEBUG loglevel = DEBUG log-config-on-start = on actor { debug { receive = on autoreceive = on lifecycle = on event-stream = on unhandled = on } }Do I need to call _log.Debug("Some message"); in my Actors? Or Akka take cares of that for me.
Please can anyone advice me on that.
@Tochemey Those logging settings are for things, you cannot reach out by yourself (or it would require some amount of work). But beside that, how is akka supposed to know what you want to log?
@hvidgaard Again specific to MVVM framework. I got event or ViewDettached or OnDeactivate() which can be appropiate for stopping.
@ZoolWay I figured as much, speciel care is necessary for transient views.
@peter-bannerflow The broadcast-group-router does the same. Only then it manages its childs for you. If you already have an actor which manages a list of child actors using some custom logic, then iterating over the children collection and dispatching messages to them works just as well.
@ZoolWay I went a slightly different route. I added a behaviour to prism such that views and viewmodels that implement IDisposable will be properly disposed, and then I put the actor shutdown in the dispose method. It seems reasonable that if you create an top level actor, you shut it down as well.
Is there a way to turn off the cluster debug logs so that my application's debug logs aren't so drowned out?
@wdspider haven't checked, but you may try
akka.remote.log-remote-lifecycle-events = off
while the setting removed some things, it didn't really remove the most "spammy" cluster ones. I seemed to have managed to filter them out via nlog though:
<rules>
<logger name="*" minlevel="Debug" writeTo="console">
<filters>
<when condition="contains('${message}', 'Received Akka.Cluster.GossipStatus')" action="Ignore" />
<when condition="contains('${message}', 'Received Akka.Cluster.GossipEnvelope')" action="Ignore" />
<when condition="contains('${message}', 'Cluster Node') and contains('${message}', 'Receiving gossip from')" action="Ignore" />
</filters>
</logger>
</rules>I do think it would be a nice feature to have a "master switch" of some sort that turns the framework debug logs on/off rather than having to manually filter them or just use Info+ in your app.
Where's the best place to report "false statements" within the docs? For example, http://getakka.net/docs/clustering/cluster-routing#clustered-group-router-config states that
You do not need to specify /user at the start of each path. It is implied. which very much seems false as the message goes to dead letters rather than the routee when I leave the /user prefix out.
I noticed that IWithBoundedStash is marked obsolete. Does this mean that we should no longer use it to pickup the bounded stash implementation (once it's done) ?
@Aaronontheweb think I sorted my issue and don't think there is an Akka.Cluster bug. Providing more time for Actor System to shut down seemed to solve things. However, a question came up about what to do if a cluster member has a catastrophic failure (server sudden power out, etc.). In the case of my 2 seed node cluster, should the UP server explicitly remove that node based on a certain exception sequence or something? What's the best practice?
@skills0 best practice is to call
Cluster.Down for the unreachable node
that call can be made anywhere in the cluster
it's built for that scenario
https://github.com/cgstevens/Akka.Cluster.Monitor - by @cgstevens
that will give you a Web UI you can use for downing it
difference between
Down and Leave is that Leave is graceful; Down is for forcing the cluster to evict a node if it's died and is never coming back
FYI. 1.1 doesn't seem to work when I upgraded. Not sure yet but just found out. Will be lookin at it tomorrow.
think it might be because of how we made
ReadView internal?
you can use
CurrentClusterState instead now - it's exposed as a public readable property on the Cluster object
Not that we are production I am going to push for my cluster now. So I need to get his working. Plan on doing somethin a little different but still thinking.
I'm pretty desperate to start building a couple of my own services on top of Akka.Cluster and SF soon
as much as I love working on the framework, I'd like to be a user of it again :p
I like how ?? Did the visualizer. Put that on top of the light house is my plan.
I still need to update lighthouse, bootcamp, webcrawler, all of my training samples
Or any node I suppose. But the leader should be the governor
and just use it everywhere
lol
Yeah I saw that. I spent all day getting lighthouse redone to work in my environment. Had to make a few tweaks for it to know what valid up address to use dynamically.
I really like the "Highlander" , the singleton actor for what I'm working on so need my cluster now. Before I just use the remote and now that skngleton solved a few issues.
that's a good name
THERE CAN ONLY BE ONE
Yeah. I love it. It only took me a couple hours to get my github example up and running.
Tomorrow is Codestock. Wish in got enough votes to talk. Maybe next year. I will sure be taking my laptop to demo Akka when I can :)
@Aaronontheweb also thank you for working on the framework though. Your and everyone else hard work has made this come to life. THANK YOU!
@cgstevens thanks man; the entire team puts a ton of work into Akka.NET
we all get a lot of value out of working on it
the community around Akka.NET is a nice intersection of enterprise developers working on really important, challenging problems using some outside the box tools and thinking
Don Syme mentioned to me at .NET Fringe he saw Akka.NET as a gateway drug for getting C# developers into functional programming
never thought of that before
either way though, point I meant it make is that it's a nice place to work