Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 07:27
    dependabot-preview[bot] labeled #3999
  • 07:27

    dependabot-preview[bot] on nuget

    Bump FluentAssertions from 4.14… (compare)

  • 07:27
    dependabot-preview[bot] opened #3999
  • Oct 20 17:25
    valdisz synchronize #3889
  • Oct 20 17:17
    valdisz synchronize #3889
  • Oct 20 15:44
    valdisz synchronize #3889
  • Oct 20 09:22
    ismaelhamed commented #3863
  • Oct 19 23:39
    valdisz synchronize #3889
  • Oct 19 23:08
    edvinasz commented #2947
  • Oct 19 13:36
    Aaronontheweb commented #3973
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3995
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump BenchmarkDotNet from 0.10.… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] edited #3995
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3993
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Google.Protobuf from 3.9.1… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3991
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Microsoft.Extensions.Depen… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3989
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump ApiApprover from 3.0.1 to … (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3992
Aaron Stannard
@Aaronontheweb
yeah, the ping pong example is a better benchmark for looking at context switching costs
they start to show up once the number of actors running exceeds the number of cores by some scalar value
in a typical Akka.NET system in production
you have a large number of actors, but at any given instant only a proportion of them have messages to process
the majority are idle, if you took a snapshot at any given millisecond
Ash R
@AshRolls
thanks for your help, I have some ideas now
Aaron Stannard
@Aaronontheweb
excellent, glad to hear it
Ash R
@AshRolls
reduce messages by batching
Aaron Stannard
@Aaronontheweb
please feel free to ask questions here or on StackOverflow
Ash R
@AshRolls
ty, very helpful. loving akka.net so thanks for the devs work on it
Aaron Stannard
@Aaronontheweb
thanks!
We have some cool stuff coming out again soon too
verilocation
@verilocation
I'd second that. Also it's nice to have such good support through this!
Ash R
@AshRolls
I just had nice speed boost by not creating a new object each time I need to create a message to send / return
Juan José De Arana
@juanjoarana
Hello, a colleague complained that it's not that easy to design an Actor model, where you can make any logical unit an actor. Specially when local message passing requires serialization, which I guess means a performance penalty. Is it possible to configure AKKA.NET to avoid message serialization when passing messages between actors in a local system? E.g.: passing messages objects by reference (ensuring they are immutable)... or doing a deep copy/clone of the message object? Thanks!
verilocation
@verilocation

The other day I asked a question regarding Ask... Someone kindly showed me a related link (http://bartoszsypytkowski.com/dont-ask-tell-2/). I have since been trying to position myself whereby I no longer have to use Ask but have come up against an issue.

Previously:

  • My ProcessActor Asked the GeocodeActor
  • The GeocodeActor Asked the GeocodeCacheActor for a cached geocode response, if it has one, Tell back to the ProcessActor
  • Failing that it would Ask the ReverseGeocodeActor to reverse geocode against Google, and then Tell to the GeocodeActor who would in turn Tell to the ProcessActor
  • At this point the GeocodeActor would Tell the GeocodeCache to cache the result

Since then I now do the following

  • My ProcessActor Tells the GeocodeActor to geocode
  • The GeocodeActor has a local cache, if its hit itll Tell the sender the geocode (the sender, ProcessActor, has a receive event for this, and stores a list of pending models)
  • If one doesn't exist it will Forward the request to ReverseGeocodeActor to reverse geocode. This would ideally then Tell the response back to the original sender, the ProcessActor.

Unfortunately I can't figure out how to cache the response without an Ask as the ReverseGeocodeActor will see that the sender is the original ProcessActor...

Ash R
@AshRolls
instead of forwarding why don't you get the GeocodeCacheActor to Tell the ReverseGeocodeActor, and send it the IActorRef of the process actor as a prop. The ReverseGeocodeActor can then send the response to the ProcessActor, as well as a Tell back to the GeocodeCacheActor with the data to cache?
verilocation
@verilocation

Ash dont suppose you have a code example? Currently I do this in the GeocodeActor when I ask the ReverseGeocode

this.ReverseGeocodeActor.Forward(p);

Which then Tells back to the ProcessActor like so

this.Sender.Tell(geocodedAddress);

In this case how would I tell the GeocodeActor to cache the result

Ash R
@AshRolls
In the geocode actor, take the contents of the message p, and put it in a new message type which contains those contents, as well as an IActorRef to Sender (which at this moment will be the ProcessActor). Then Tell that message to the ReverseGeoCode actor.
verilocation
@verilocation
ahhhh
I understand you now... Does it not seem.. wrong.. to store the sender in a POCO rather than use akka somehow itself.
Ash R
@AshRolls
In the ReverseGeoCode actor, you can then Tell Sender (GeocodeCacheActor) with the data to cache, and you also have the IActorRef so you can send ANOTHER message to tell the ProcessActor
as for structure... can't say sorry, I have been sending IActorRef around in my messages without problem, it seems pretty lightweight
if it's a set structure you can send it just once in the constuctor of the agent
verilocation
@verilocation
Oh now that sounds better
Ok that works a charm, I like that, thank you
Ash R
@AshRolls
np
Marc Piechura
@marcpiechura
@juanjoarana Akka.net only serialize messages if they are send over the wire and we use the object ref and don't do deep cloning because that would hit the performance, so we have by default the requirement for immutable messages
Andrew Young
@ayoung
@Horusiath issue created #2340
John Nicholas
@MrTortoise
@AshRolls re not creatign messages: so you used some kind of static instance? or do you mean you had a pool of messages to use?
himekami
@himekami
Hi, anyone knows how to create cluster singleton using FSharp API ? What should I pass to SpawnOption list (I'm guessing i have to use SpawnOpt) ?
Gregorius Soedharmo
@Arkatufus
question, since the async and await keyword is pretty much banned in akka.net, do i need to use PipeTo in ReceiveAsync?
and i'm not allowed to do something like... ReceiveAsync<MyClass>(async message => {}); ?
John Nicholas
@MrTortoise
you can still use tasks. They are useful in those cases.
when using tasks the ReceiveAsync seems to be the way if you do not want your actor to be reenterant (which is probably the case otherwise you can have state changes prior to the PipeTo or ContinueWith continuation
Juan José De Arana
@juanjoarana
@Silv3rcircl3 oh, great, was not able to find in the documentation these details. I'll try to review AKKA.net documentation to understand the details on serialization. Thanks so much.
Gregorius Soedharmo
@Arkatufus
@MrTortoise you mean by doing something in the line of Task.Run(MyAsyncFunc(param, Sender));?
Ash R
@AshRolls
@MrTortoise The messages I was referring to had no content, they were just useful for signalling, so instead of creating a new instance of the class each time I stored one, and used it repeatedly
Gregorius Soedharmo
@Arkatufus
i guess i'm just not getting the purpose of ReceiveAsync actors...
verilocation
@verilocation
I think that given that multiple Actors will run within a thread, using just Receive would be a blocking event. ReceiveAsync will allow multiple Actors to run concurrently with less blocking
When I switched to ReceiveAsync I saw a big performence boost
Gregorius Soedharmo
@Arkatufus
hmmm... so just switch the base type to ReceiveAsync but keep everything inside as non-async?
John Nicholas
@MrTortoise
@Arkatufus Well the case i was thinking of would be on an edge of the system where you hit a resource that is not in akka. Often that call might be async with a task continuation because you don't want to block the actor. However if you have a situation where you need something in the actors state and dont want to risk anything else coming in and trampling on it, then you would use it.
verilocation
@verilocation
@Arkatufus You would use it when your Receive method needs to call an external resource (such as use an Ask or call a database). Otherwise theres no point.
John Nicholas
@MrTortoise
hang on maybe i misunderstand ... In recieve when you start a task and put a continuation on it. my understanding is that the recieve handler ends before the continuation executes.
Gregorius Soedharmo
@Arkatufus
@MrTortoise yes, i was trying to figure out a way to do CRUD to a database asynchronously from akka
verilocation
@verilocation
in which case you'd use async on that i.e.
this.ReceiveAsync<DbRequest>(request =>
{
    var result = await this.dbContext.Where(user => user.Id == request.UserId);
});
Syed Hassaan Ahmed
@bannerflow-hassaan
Question: We have an Akka.Cluster deployment where one of our Nodes is hosted as a Topshelf service. The Node uses Akka.Persistence for Actor state recovery in case of Service restart/upgrades. Deployment script successfully performs these steps: stop->uninstall->reinstall new version->start the service. We're using Redis for persistence and can see that the "journals" are present with correct state. However, after the service is started, we see this error in NLog causing state loss. "Persistence failure when replaying events for persistenceId [workerSupervisorActor]. Last known sequence number [0]" Has anyone seen similar issue before?
Gregorius Soedharmo
@Arkatufus
@verilocation you're not supposed to use await inside Receive though, because when it is loaded later in a different thread, the context might have changed
at least thats what i've read so far