Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:23

    Aaronontheweb on dev

    Added TimeBasedUuid offset (#59… (compare)

  • 13:23
    Aaronontheweb closed #5995
  • 08:05
    ismaelhamed commented #5995
  • 08:05
    ismaelhamed ready_for_review #5995
  • 07:49
    ismaelhamed edited #5995
  • 07:47
    ismaelhamed edited #5995
  • 07:47
    ismaelhamed synchronize #5995
  • 06:53
    ismaelhamed synchronize #5995
  • Jun 24 21:02
    Arkatufus synchronize #6024
  • Jun 24 21:02
    Arkatufus synchronize #6023
  • Jun 24 19:48

    Aaronontheweb on dev

    Convert Akka.Streams.Tests to a… (compare)

  • Jun 24 19:48
    Aaronontheweb closed #5993
  • Jun 24 19:23
    Arkatufus synchronize #6023
  • Jun 24 18:58
    Arkatufus synchronize #6023
  • Jun 24 18:11
    Arkatufus synchronize #6023
  • Jun 24 18:04
    Arkatufus opened #6024
  • Jun 24 17:43
    Arkatufus synchronize #6023
  • Jun 24 17:43
    Arkatufus opened #6023
  • Jun 24 16:18
    Arkatufus synchronize #5993
  • Jun 24 16:10
    dependabot[bot] synchronize #5998
Aaron Stannard
@Aaronontheweb
@catalinrolea wrong framework
this is Akka.NET
C# / F# port
catalinrolea
@catalinrolea
sorry
Aaron Stannard
@Aaronontheweb
no problem
@eaba please file an issue with a description of what you're observing and a minor reproduction case if you can
Shukhrat Nekbaev
@snekbaev
@Aaronontheweb regarding the ConsistentHashingPool and naming issue I mentioned earlier, do you know why this happens?
Ebere Abanonu
@eaba
@Aaronontheweb I will give it a try
Rodger Brennan
@rodgerbrennan
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?
Shukhrat Nekbaev
@snekbaev
@rodgerbrennan maybe set a ReceiveTimeout for the given interval?
v1rusw0rm
@v1rusw0rm
@rodgerbrennan what is the source of calls to the device? Is device actor periodically calling it? Or another actor\external system sends request to the device actor and then the device actor sends\ask something from device?
Rodger Brennan
@rodgerbrennan
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.
AndreSteenbergen
@AndreSteenbergen
@rodgerbrennan you could implement a SourceStage for a Dsl source. It isn't all that hard actually. Check the AkkaContrib/Alpakka sourcestages for an example. You could implement it as a scheduled Task, every 250ms, or after each Push a wait of 250ms.
You would neeed to implement a class with BaseClass GraphStage<SourceShape<T>>
And most importantly a GraphStageLogic class
v1rusw0rm
@v1rusw0rm
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.
AndreSteenbergen
@AndreSteenbergen
That class can implement a Push. That Logic defines your Pull method. You can create a queue
v1rusw0rm
@v1rusw0rm
Another way is to use Streams as Andre suggests. Probably the existing Sources will be enough
AndreSteenbergen
@AndreSteenbergen
Reading this a second time over, I guess I would implement it with a graph.
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
Rodger Brennan
@rodgerbrennan
Yeah, it's looking like I may have to change my architecture approach a bit. Initially I was thinking there would be an easy way to set a timer on the actor and use stashing/unstashing.
AndreSteenbergen
@AndreSteenbergen
Very simple approach is to call your webservice per type of event
and wait 250ms after each result and use (await Thread.Delay (250)).ContinueWith(t => EVENT To Trigger Next Stage).PipeTo(Self)
Rodger Brennan
@rodgerbrennan
@AndreSteenbergen that would work :)
AndreSteenbergen
@AndreSteenbergen
While in the process I would Stash all "BeginRetrieving" events, otherwise to sequences could accidentily trigger 2 sequences running parallel
Vasily Kirichenko
@vasily-kirichenko
DeviceSource which asks the device on OnPull |> Source.pulse 250ms |> ..
AndreSteenbergen
@AndreSteenbergen
BTW don't use Self in the PipeTo (with CAPS), capture Self in a variable before that. var self = 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
Rodger Brennan
@rodgerbrennan
I've been keeping with traditional Req/Resp for the webapi/webclient. It seems like the problem would be solved more appropriately if I changed to aysnc (SignalR). But, that's one of those "I can do that in a weekend" paths :)
Vagif Abilov
@object
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?
Rodger Brennan
@rodgerbrennan
@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.
AndreSteenbergen
@AndreSteenbergen
I think I would go for the simple version at this moment; call and wait. The actor won't process stuff if I am correct in the meantime
Rodger Brennan
@rodgerbrennan
Thanks!
AndreSteenbergen
@AndreSteenbergen
Np; just don't forget to place Self in a variable first, as the reference gats lost
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();

Chandra Sekhar Manginipalli
@leo12chandu
Can grouped routers take in fully qualified routees.paths to remote actors on a cluster?
Rodger Brennan
@rodgerbrennan
I did that almost exactly in the job script. Would putting the delay in the actor's command handler have any ill effects I'm not considering?
Chandra Sekhar Manginipalli
@leo12chandu
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"
AndreSteenbergen
@AndreSteenbergen
@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
Rodger Brennan
@rodgerbrennan
I want better hardware to work with, but I'll settle for not breaking it in production :) But, yeah, this seems to be exactly what I need.
AndreSteenbergen
@AndreSteenbergen
We have to work with, what we are given sometimes.
Chandra Sekhar Manginipalli
@leo12chandu
So far from what I searched, sounds like the routees have to be in the same ActorSystem as the router (independent of nodes) when using grouped routers. Anyone know if the routees can be on a different actorsystem?
Vasily Kirichenko
@vasily-kirichenko
does anybody know if "Reactive Applications with Akka.NET" is gonna be released, finally?
The last MEAP is rather outdated, it uses Helios in snippets, etc.
Ebere Abanonu
@eaba
@vasily-kirichenko the publisher keep changing the release date
Vasily Kirichenko
@vasily-kirichenko
:(