this is Akka.NET
C# / F# port
@eaba please file an issue with a description of what you're observing and a minor reproduction case if you can
I have a ReceivePersistentActor that talks to an IOT device. My real-life use case is surprisingly similar to the Device Actor in the introduction tutorials but, I need to throttle calls to the device to no more than 1 call for every 250ms. Can anyone provide some guidance on how I might accomplish this?
The source is a webapi implemented with Giraffe. There's also a job that will run on a schedule of every 15 minutes. The device I'm talking to has several commands that need to be called in sequence, and each command needs to be about 250ms apart. Ex. The job reads the temperature from the device, then reads the power levels of the device. Right now I have the actor doing this and storing the results of the read operation. I have an actor for each device. What I don't have at the moment is a way to prevent the actor from executing more than on command within that 250 window.
You would neeed to implement a class with BaseClass GraphStage<SourceShape<T>>
And most importantly a GraphStageLogic class
I think the one way to solve it is to use a Queue inside actor. Push requests\commands to this queue and use Akka's Scheduler to dequeue next command every 250ms. If requests are not frequent, then there will be no problem. Otherwise actor will not handle the load and queue will grow until OutOfMemory Exception occur. You can limit a size of this queue and deny new commands until existing commands processed.
You could have a pauze Flow stage between every step. SourceActor would be job to get all calls from 1 IOT device, every Outlet could be given to a wait Flow Inlet, Passing the result to the next Inlet
and wait 250ms after each result and use (await Thread.Delay (250)).ContinueWith(t => EVENT To Trigger Next Stage).PipeTo(Self)
@vasily-kirichenko Nice ;) but I raised this idea because of this message: "I may have to change my architecture approach a bit"
And after reading the question twice The OnPull would be non trivial, as I suspect the event/message is different in the sequence
GetTemp(); wait 250ms GetPowerLevels() wait another 15 minutes
Hello, I noticed that remote ActorSelection from a cluster node does not work the same way as when executed from a standalone app. From a Cluster node I am trying to remotely select an actor using fully qualified remote address with machine name, and selection resolution times out. But if I first create a new actor system and execute the same code with the same remote address from the newly created system it will works fine. Is there anything to be aware of when doing remote actor selection in a cluster?
@AndreSteenbergen that's pretty much it. But it's RecordTemp();wait 250ms;RecordPowerLevels(); and the events are recorded to EventStore with TempRecorded, and PowerLevelsRecorded. The hardware is my problem point because if a call is made while another is processing it'll either be ignored or worse cause the device to hang.
gets lost
I haven't used it, but if I am correct you can also use async methods in actors since 1.??.?? don't know the exact version
await iotClient.RecordTemp();
await Thread.Delay(250);
await iotClient.RecordPowerLevels();
So I can route the messages sent to this round-robin-group to an actor on a separate cluster. Tried something like routees.paths = ["akka.tcp://MyActorSystem@Machine:port/user/myactor"], but it throws "is not a valid relative actor path. Parameter name: routeesPaths"
@Horusiath answered it on stackoverflow: https://stackoverflow.com/questions/47709420/is-it-safe-to-use-async-await-inside-akka-net-actor It stops taking in new messages. What basically is what you want if I am reading your question correctly
The PipeTo method is what I recall is recommended; but both methods should work fine
The last MEAP is rather outdated, it uses Helios in snippets, etc.