however, if my ability to process those real-time order book events is slow
then my application can't really do its job properly
we will use the stronger delivery guarantee in the execution engine though
because my view of an account balance and the exchange's view of the account balance have to be identical
otherwise the trading algorithms are going to try to execute trades that can't be filled or might otherwise blow away the liquidity (cash-on-hand) parameters the users set... which would be bad
hi! I have a problem: there are two independent projects and I am using Akka Remoting for connection. I am also using Autofac DI.
Two projects. Two actor systems. Two Autofac DI containers.
Actor of the first ActorSystem calls actor of the second ActorSystem which should have constructor injection.
But the first actor system doesn't know (and shouldn't know) about this dependencies.
Is it possible to call this actor after resolving dependency through the second actor system?
Two projects. Two actor systems. Two Autofac DI containers.
Actor of the first ActorSystem calls actor of the second ActorSystem which should have constructor injection.
But the first actor system doesn't know (and shouldn't know) about this dependencies.
Is it possible to call this actor after resolving dependency through the second actor system?
if not, then none of this stuff matters - both actors are started independently
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
Is it possible to get address of actor from HOCON?
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
explore*
that being said, we do have all of these ones
the WebCrawler one for Akka.Cluster is probably the most relevant there
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
So well! We will try Actor Selection for this moment. Thanks again! All the best! :smile:
