akkadotnet/akka.net

Port of Akka actors for .NET

Vasily Kirichenko

@vasily-kirichenko

ActorSelection would be too slow I'm afraid

it should be avoided in most cases

Bartosz Sypytkowski

@Horusiath

@snekbaev if you're using clusters, akka cluster sharding gives you exactly that

Vasily Kirichenko

@vasily-kirichenko

yeah, but I'm afraid he does not use cluster.

Bartosz Sypytkowski

@Horusiath

then a simple user coordinator can work

Vasily Kirichenko

@vasily-kirichenko

which holds a userid -> actorref dictionary?

I mean using ActorSelection is not good for this

@snekbaev

Bartosz Sypytkowski

@Horusiath

@vasily-kirichenko @snekbaev if a coordinator is a single purpose, you don't need dictionary or anything:

Receive<SendTo>(send => {
  string recipient = send.Recipient;
  object message = send.Message;
  var child = GetChild(recipient);
  if (Equals(child, ActorRefs.Nobody)) 
  {
    child = Context.ActorOf(childProps, recipient);
  }
  child.Forward(message);
});

Vasily Kirichenko

@vasily-kirichenko

ah, GetChild

cool

Shukhrat Nekbaev

@snekbaev

no cluster, no remoting so far, just a test app :)

Vasily Kirichenko

@vasily-kirichenko

I hope it's O(1) ;)

Shukhrat Nekbaev

@snekbaev

@vasily-kirichenko ActorSelection, I've been battling to avoid it, but then I'm left either pass it via constructor and the chain can be long, or try to init the actor with some message, which shifts those actors to use "Become", also they will probably use some "discovery" actor by ActorSelection anyway...

@Horusiath hm, I don't seem to have GetChild in Akka 1.3.8, did you mean: Context.Child( )?

Aaron Stannard

@Aaronontheweb

@eaba what persistence driver are you using?

@snekbaev yes he does

Context.Child is O(1) - it's a dictionary lookup

Vasily Kirichenko

@vasily-kirichenko

great

Ebere Abanonu

@eaba

@Aaronontheweb sqlserver

Aaron Stannard

@Aaronontheweb

yeah, so color me really, really skeptical that it's missing sequence numbers

it's the most heavily used

catalinrolea

@catalinrolea

@catalinrolea
guys, i'am still having this error when i try to build an akka HttpListener to cloud foundry:" org.cloudfoundry.security.CloudFoundryContainerTrustManagerFactory getSystemTrustManager
org.cloudfoundry.security.CloudFoundryContainerTrustManagerFactory getSystemTrustManager
org.cloudfoundry.security.CloudFoundryContainerTrustManagerFactory getContainerTrustManager
2018-07-23T14:27:21.67+0300 [APP/PROC/WEB/1] ERR INFO: Adding TrustManager for /etc/ssl/certs/ca-certificates.crt"
You can see the code here:
https://github.com/catalinrolea/cf-akka-http
I have tried a lot of examples from akka but still not working
many thanks.

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 |> ..

Where communities thrive

People

Repo info

Activity