Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:56
    ismaelhamed commented #3723
  • 05:45
    dependabot-preview[bot] labeled #4650
  • 05:45

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • 05:45
    dependabot-preview[bot] opened #4650
  • 05:42
    dependabot-preview[bot] labeled #165
  • 05:42
    dependabot-preview[bot] opened #165
  • 05:42

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.11.4… (compare)

  • 05:42
    dependabot-preview[bot] labeled #164
  • 05:42
    dependabot-preview[bot] opened #164
  • 05:42

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • 05:37
    dependabot-preview[bot] labeled #181
  • 05:37
    dependabot-preview[bot] opened #181
  • 05:37

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • Dec 02 23:26
    zbynek001 synchronize #4649
  • Dec 02 21:53
    motmot80 synchronize #4643
  • Dec 02 21:44
    zbynek001 opened #4649
  • Dec 02 21:25
    motmot80 commented #4643
  • Dec 02 21:18
    motmot80 commented #4643
  • Dec 02 21:15
    Arkatufus commented #4643
  • Dec 02 21:15
    Arkatufus commented #4643
Aaron Stannard
@Aaronontheweb
and neither needs to know about each other's constructor arguments
they just need to acquire a remote actor reference to each other
which you can via an ActorSelection initially
AnchishkinAlex
@AnchishkinAlex
Ok, we tried to use ActorSelection but it needs hardcode address of actor.
Is it possible to get address of actor from HOCON?
Aaron Stannard
@Aaronontheweb
yep, you can create a custom HOCON field
to store the address a remote node
I do this inside the client-server app from our Akka.NET trainings
let me see if I can grab it...
akkatime{
             sessions{
              handshake-timeout = 4.0s #max time to complete the handshake timeout process
              verify-timeout = 1.0s #max time to authentication an end-user locally on the server
              verify-chat = on
             }
             server = "akka.tcp://akkatime@127.0.0.1:14445"
          }

          akka {
the akkatime section is custom
and I have a akkatime.server property that the client reads from configuration in order to figure out how to contact the server
var actorSystem = ActorSystemRefs.AkkaTimeSystem = ActorSystem.Create("akkatime");
            var serverAddress = ActorSystemRefs.ServerAddress = Address.Parse(actorSystem.Settings.Config.GetString("akkatime.server"));
            var serverStatus =ActorSystemRefs.ServerConnectivityActor =
                actorSystem.ActorOf(
                    Props.Create(() => new ServerConnectivityStatusActor((Address)serverAddress.Clone(), ServerConnectivityStatus.Disconnected)),
                    ActorPaths.ServerConnectivity.Name);
which I then read in here when I'm starting my ActorSystem
and that serverAddress gets passed to an actor that uses an ActorSelection to contact another actor on the server
AnchishkinAlex
@AnchishkinAlex
Thank you. Could you provide link to this example? I'll explain it
explore*
Aaron Stannard
@Aaronontheweb
wish I could, but it's part of the training materials we distribute to our customers
that being said, we do have all of these ones
the WebCrawler one for Akka.Cluster is probably the most relevant there
AnchishkinAlex
@AnchishkinAlex
Thanks! I saw Akka.NET Bootcamp, Chat Server Example but not this samples :smile:
Aaron Stannard
@Aaronontheweb
you're welcome!
AnchishkinAlex
@AnchishkinAlex
And I know about your post "When I should use Actor Selection?". Is this situation relevant, isn't it?
Aaron Stannard
@Aaronontheweb
yes it is
generally, IActorRef is going to be both more performant and flexible at run-time
since it has the benefit of location transparency and doesn't need to be "resolved"
but ActorSelection is ideal in situations where you don't have a reference to an actor yet but still need to contact it
and you know roughly where it is in the hierarchy
most people build their actor hierarchies top-down
where the top level actors filter messages down to their children and so forth
so by convention, most developers treat their top level actors like "public APIs"
therefore, it's usually safe to select those and trust that your message will eventually be routed to the correct concrete actor who will actually do the processing
and that actor will send you a reply back directly
you can also do some cool stuff with wildcard actor selections
i.e. akka.tcp://mysys@127.0.0.1:9110/user/myParent/*/myGrandChild
you can dynamically select all of the grand children of myParent named myGrandChild without knowing what the parent's name is
I used that to build our actor hierarchy visualizer in Petabridge.Cmd: https://cmd.petabridge.com/articles/commands/actor-commands.html#actor-hierarchy
AnchishkinAlex
@AnchishkinAlex
it's interesting
So well! We will try Actor Selection for this moment. Thanks again! All the best! :smile:
vicosoft4real
@vicosoft4real
Can some please explain the philosophy behind this Cluster Sharding shenanigans.
Aaron Stannard
@Aaronontheweb
@vicosoft4real Cluster.Sharding tries to guarantee that there is exactly one copy of a given entity inside your cluster at any given time
where each entity is represented as its own actor
it has tooling in place to do things such as redistribute entities when the cluster changes
buffer messages being sent to a given entity while it's being moved
and a placement algorithm for figuring out where it should spawn new ones
each entity should, ideally, persist its state somewhere
vicosoft4real
@vicosoft4real
sounds good
Aaron Stannard
@Aaronontheweb
so in the event that the entity passivates (shuts down after a period of inactivity) and needs to be recreated in the future
vicosoft4real
@vicosoft4real
but we cannot have full control of the created entity/actor