@Aaronontheweb thanks for detailed explanation and the valuable video.
I understand the complexity of the problem. I'll try to port this sample to akka.net and see how things go: http://proto.actor/blog/2017/06/24/money-transfer-saga.html
I understand the complexity of the problem. I'll try to port this sample to akka.net and see how things go: http://proto.actor/blog/2017/06/24/money-transfer-saga.html
@jameswilddev no, if you want to be sure its delivered (it will be send to the IActorRef you tell it to, but that actor might not receive it because its remote), you will have to use mechanisms like AtLeastOnceDelivery. So instead of directly sending it to the remote actor (assuming here) you put an atleastoncedelivery actor in between or something.
Or whatever other reliable delivery mechanism you want to use
So what im saying is: emulating a failure to deliver by the Scheduler, is the wrong place to be handling this.
I guess I should mock out the scheduler itself, check that it sends that message, and then test that when the message is received (or not received) that it acts accordingly.
Hello. I remember being recommended to put actor initialization logic in PreStart (such recommendation is also contained in Akka Bootcamp). What are the reasons for that except that before PreStart is called, an actor is not yet capable of receiving messages? For example, if an actor creates some child actors can the child creation logic be executed prior its PreStart? What can go wrong?
just need to add multi-targeting back to the
csproj file
and then executing the following
/// <summary>
/// Used to load HOCON definitions from a dedicated HOCON file
/// </summary>
public static class HoconLoader
{
/// <summary>
/// Parses a HOCON <see cref="Config" /> object from an underlying file
/// </summary>
/// <param name="path">The path to the HOCON file.</param>
/// <returns>A parsed <see cref="Config" /> object.</returns>
public static Config FromFile(string path)
{
return ConfigurationFactory.ParseString(File.ReadAllText(path));
}
}
similar to how you'd use a .JSON file for
Microsoft.Extensions.Configuration
and then I pass that hocon object into the
ActorSystem.Create(string name, Config config) method
we'll probably add something to Akka.NET core to make that easier soon
and then set it to
Copy Always or Copy If Newer
@Aaronontheweb Hi! Thanks again for support yesterday! It works! There is another one problem with Akka.NET Remote.
I suppose it's enum serialization problem. We're expecting from remote actor enum return type but it returns long. (Of course Sender.Tell(EnumType))
Actor.Ask<EnumType>() //InvalidCastException
Google says about Akka.Cluster only. Is it right way for fixing this problem?
I suppose it's enum serialization problem. We're expecting from remote actor enum return type but it returns long. (Of course Sender.Tell(EnumType))
Actor.Ask<EnumType>() //InvalidCastException
Google says about Akka.Cluster only. Is it right way for fixing this problem?
@object sometimes there are actors, that are not fully initialized at the end of the constructor call i.e. ReceiveActor doesn't have it's handler behavior compiled yet, PersistentActor didn't trigger recovery procedure. PreStart is not always mandatory, but it's a good rule of thumb
I had this idea today that would greatly help debugging Akka applications (actually, unit tests) - a way to render all the interactions between actors as a sort of 'sequence diagram' . But in order to do this, I need some kind of hook that tells me about each message being
Telled. IIRC Monitoring does something like it - but is there a generic way to hook in somewhere in order to get the data I'm looking for?
ActorCell has the best information probably
if not there then overriding the
AroundReceive base method
on your actors
most interesting and consistent, as multiple Tells will always be in the right order then.