https://metaplay.io logo
Async call in MessageHandler
# questions-and-feedback
a
Hey, should I use async-await or PipeTo(Self) in server actor message handlers that do calls to async methods? I read some akka.net info and decided to try PipeTo out but then saw this: > 'MetaReceiveActor.Self' is obsolete: 'Hiding ActorBase.Self on purpose because it is dangerous when used with .ConfigureAwait(false). Please use _self instead (from MetaReceiveActor).' does that mean that this (old) style:
_feedFactory.CreateFeedAsync(feed.FeedUri).PipeTo(Self);
from https://petabridge.com/blog/akkadotnet-async-actors-using-pipeto/ is not recommended? i was reading the newer info from https://petabridge.com/blog/async-await-vs-pipeto/ but understood that PipeTo might still be useful. i didn't read carefully yet though
n
It is generally better to do async await to avoid any concurrency issues inside the actor and keep the code simpler. If you need to do a long-running task in the background and you want to keep the actor mailbox open for new requests, you can use
ContinueTaskOnActorContext
instead of PipeTo. For example:
Copy code
C#
// Run on thread pool and route back
 int MyComputeHeavyTask(int param)
 {
    return FindNextPrime(param);
 }
 ContinueTaskOnActorContext(Task.Run(() => MyComputeHeavyTask(param)), result => {}, failure => {});

 // Run deferred on background on the actor context (does not block the mailbox).
 async Task<int> MyLongRunningActorTaskAsync(int param)
 {
   await Task.Delay(1000);
   await EntityAskAsync<>(param);
   return 1;
 }
 ContinueTaskOnActorContext(MyLongRunningActorTaskAsync(param)), result => {}, failure => {});
a
yep i've been using ContinueTaskOnActorContext in PlayerActor a lot
n
And as the warning says, if you need to access Self, use
_self
a
in this case i'm sending a message from PlayerActor to another server entity which calls externals APIs and that can apparently take time
but the order of those api calls doesn't matter so there are no concurrency issues in that sense .. but it's a single entity that should do these api calls for all players, so it should keep receiving new messages while it's processing previous ones
hm actually the client that's used for the api calls there might not thread safe so perhaps doing the task spawning is not a good idea
n
Maybe you can have a Queue or something then? Or multiple clients to call the api
Or use a ThreadLocal and ContinueOnActorContext
a
hm, yes thanks for the ideas i guess i'll need to investigate how it is with that client actually
3 Views