Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:40
    cptjazz synchronize #3974
  • 14:07
    cptjazz opened #3974
  • 08:30
    ismaelhamed commented #3937
  • Oct 12 15:50
    IrvinDominin opened #127
  • Oct 11 18:21
    Aaronontheweb commented #3973
  • Oct 11 18:20
    Aaronontheweb commented #3937
  • Oct 11 18:16
    Zetanova commented #3937
  • Oct 11 18:11
    Zetanova commented #3937
  • Oct 11 15:09
    Aaronontheweb commented #3937
  • Oct 11 15:08
    Aaronontheweb commented #3937
  • Oct 11 14:36
    Aaronontheweb commented #3973
  • Oct 11 01:00
    Horusiath commented #3057
  • Oct 10 20:02
    IgorFedchenko synchronize #3973
  • Oct 10 19:59
    IgorFedchenko synchronize #3973
  • Oct 10 19:58
    IgorFedchenko commented #3973
  • Oct 10 19:53
    IgorFedchenko opened #3973
  • Oct 10 14:04
    stijnherreman commented #3057
  • Oct 10 13:54
    Aaronontheweb commented #3970
  • Oct 10 13:54
    Aaronontheweb synchronize #3970
  • Oct 10 10:10
    Zetanova commented #3937
Arjen Smits
@Danthar
@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.
jameswilddev
@jameswilddev
Ah, thanks. In this case, it is just sending a message to itself.
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.
jameswilddev
@jameswilddev
Is it specified anywhere what the scheduler will do if I start a repeating tell and then the actor which started it crashes (or otherwise stops)? Will it just schedule messages until the node is restarted (it seems this is the case from my testing)?
Vagif Abilov
@object
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?
Aaron Stannard
@Aaronontheweb
@oeaoaueaa I'll take a look at it
Jose Carlos Marquez
@oeaoaueaa
thanks!
Aaron Stannard
@Aaronontheweb
left you a comment on there
just need to add multi-targeting back to the csproj file
Jose Carlos Marquez
@oeaoaueaa
thanks, I'll correct that now
mmansouri
@mmansouri
Hello all, newbie question , where to put hocon config when using asp net core thanks
Aaron Stannard
@Aaronontheweb
@mmansouri what I'm doing is putting the HOCON in its own text 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
mmansouri
@mmansouri
ok thanks :smile: i will try this
Aaron Stannard
@Aaronontheweb
you'll want to set the text file to be treated as Content by MSBUILD
and then set it to Copy Always or Copy If Newer
mmansouri
@mmansouri
yeah an easier way to manage hocon in net core will be awesome
Jose Carlos Marquez
@oeaoaueaa
@Aaronontheweb PR updated: AkkaNetContrib/Akka.DI.Ninject#10 will bear that in mind next time
AnchishkinAlex
@AnchishkinAlex
@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?
Bartosz Sypytkowski
@Horusiath
@AnchishkinAlex probably some problem with serializer. You may need something non-standard.
@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
AnchishkinAlex
@AnchishkinAlex
@Horusiath does it mean asking of actor for EnumType is non-standard? For example, is it better to create Message class with Enum field?
Bartosz Sypytkowski
@Horusiath
@AnchishkinAlex I mean, you may try to use custom serializer for the enum type. Usually actors exchange more complex messages, afaik enum field in complex object should be deserialized correctly
AnchishkinAlex
@AnchishkinAlex
@Horusiath ok. I asked it because this problem occurs only with remote actor. Actors from one actor system can return enum type without exception. So I need explore near custom deserialization and serialization?
Bartosz Sypytkowski
@Horusiath
yes, messages exchanged between actors on the same node are not serialized.
AnchishkinAlex
@AnchishkinAlex
@Horusiath thanks! The last question: has Akka.Cluster some implementations for serialization? Does it make sense to realize Akka.Cluster only for fixing it?
Bartosz Sypytkowski
@Horusiath
@AnchishkinAlex I don't quite get your question.
AnchishkinAlex
@AnchishkinAlex
@Horusiath I'm sorry. If I'll make connection between actors through Akka.Cluster this problem can be fixed automatically? Or it needs custom serializer anyway?
Bartosz Sypytkowski
@Horusiath
Akka.Cluster is a layer on top of Akka.Remote - it doesn't replace transport
AnchishkinAlex
@AnchishkinAlex
Ok. Thanks a lot! All the best!
Bartosz Sypytkowski
@Horusiath
no problem ;)
Vagif Abilov
@object
Thanks @Horusiath
Bart de Boer
@boekabart
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?
Bart de Boer
@boekabart
Hook into Dispatcher somehow?
Aaron Stannard
@Aaronontheweb
the ActorCell or mailbox maybe
ActorCell has the best information probably
if not there then overriding the AroundReceive base method
on your actors
Bart de Boer
@boekabart
The thing with AroundReceive is that... it's actually the moment of telling that's interesting as well
most interesting and consistent, as multiple Tells will always be in the right order then.
But Dispatcher can't have the hook as it handles entire mailboxes, and Monitoring , well, requires changes to each actor as well...
Going to look at Cell
Andrew Young
@ayoung
as far as you guys know, compatibility between nodes running in .NET Framework and .NET Core isn't a problem, right?
Cluster nodes, that is.