akkadotnet/akka.net

Port of Akka actors for .NET

Natan Vivo

@nvivo

you can just ask the actor to stop after your're done

it's already part of the actor system

Nikita Tsukanov

@kekekeks

It's not the part of ASP.NET

Roger Johansson

@rogeralsing

Actor lifecycle should never be handled by anything else than akka itself. Actors can restart and thus need its own pipeline into the DI container to resolve its own dependencies

Nikita Tsukanov

@kekekeks

ASP.NET won't tell the actor that it's no longer needed

ASP.NET won't tell the actor that request is completed

So if one wants to have an actor per-request, he has to wrap an ActorRef into something that provides that glue

This shouldn't be used inside actor code however

Only by external consumers

Natan Vivo

@nvivo

You can have an actor per request and never have to let asp.net know about that

Nikita Tsukanov

@kekekeks

Generally a bad idea in terms of ASP.NET

Since in this case you have to manually manage actor's lifetime

instead of letting DI-container to do its work

Natan Vivo

@nvivo

@kekekeks you need to consider actor lifetime is a feature of akka. it's not a burden.

Nikita Tsukanov

@kekekeks

If external code claims some resource (actor in our case), it should free it at some point

Otherwise you'll get a lot of actors not being using and just eating the memory

Or you'll have to use RecieveTimeout to kill the actors

which isn't a good solution either, since it may kill the actor before request completes

Roger Johansson

@rogeralsing

That is done using either .stop or sending poisonpill, not by calling dispose

See the actor system as its own container, bad idea to try to have two competing containers decide when to kill things

The same things that is

Roger Johansson

@rogeralsing

You can create a factory that creates the actor for you, and if the factory is disposed, you send poisonpill to kill the actor. That way, the ActorSystem is in charge all the time, while you still can inject the factory and get the actorref

Natan Vivo

@nvivo

@rogeralsing Is Pigeon.conf really always loaded by the actor system, or is it just a reference?

Roger Johansson

@rogeralsing

Then DI the factory whereever you need it

Arjen Smits

@Danthar

and back. catching up on reading

Roger Johansson

@rogeralsing

Always loaded , its the fallback for properties that the user config didnt supply

Natan Vivo

@nvivo

thanks

Roger Johansson

@rogeralsing

There are probably some old JVM gunk in there still

Natan Vivo

@nvivo

@rogeralsing about the dispatchers, do you have any other common use case for them, so I can mention in the documentation?

Roger Johansson

@rogeralsing

Yes, we have one dispatcher that captures current synchronizationcontext , so you can run actors in gui threads and update controls and such w/o threading issues

Eg if you want to async fill a grid or something

Natan Vivo

@nvivo

hmm. ok!

that's important

Roger Johansson

@rogeralsing

(Those actors should ofc not do heavy work, just update gui in a reactive way)

Maybe a reactive gui app for stock prices are a good example

There is also a pinned thread dispatcher, if you want to dedicate an entire thread to a specific actor

And the forkjoindispatcher, that has its own dedicated threadpool, to avoid noisy neigbours. Eg if some actors are more important than others, it can be isolated from the default shared threadpool

Natan Vivo

@nvivo

Thanks! that helps a lot, gave me already some direction

Arjen Smits

@Danthar

@rogeralsing You basically confirmed what I already expected. Akka uses the DI container to create an instance of your Actor, and after that, Akka is responsible for the lifecycle of the Actor. And not the DI container.

So that confirms my remarks about not supporting any DI lifetime scope except Transient/InstancePerDependency

Roger Johansson

@rogeralsing

it depends on what you mean with scope i guess, lets say you have one dependency that should be recreated for each usage in a dependency graph, that ofc works, and of there is some dependency that should be unique per resolve, that would work too... Eg if a foo have a ref to 5 bars and 3 baz. It could be resolved as 5 bars and one single baz. For the same foo, if foo is injected to the actor

Natan Vivo

@nvivo

@rogeralsing please correct if I'm wrong. Most of the JVM akka docs say that hocon configuration overrides code config. But some tests I did here shows the opposite. For example, if you specify WithRouter(...) in code, it overrides any hocon config. Is it correct that Akka.net gives preference to code over config or I missed something?

Arjen Smits

@Danthar

@rogeralsing I'll do a write-up about this for the http://getakka.net/docs/Dependency%20injection page. Ill run it by you guys when im done.

Arjen Smits

@Danthar

General question to whomever can answer this :P. My ActorSystem behaves in such a way, that it can be in an 'idle' state. Which effectively means that the mailboxes for a few key Actors in my system are empty. Does Akka currently has a way for a user of the framework to monitor this kind of state for an actor ?

So something along these lines:

    actor1.Ask<bool>("areyoubusy")

where the "areyoubusy" is a system(?) message which tells me if there are messages in the actor1's mailbox

Alexander Prooks

@aprooks

I'd beter save info when last message is processed, and on 'areyoubusy' report if any message is processed for the last second/minute whatever you need

Natan Vivo

@nvivo

@Danthar It's a good idea to leave a note on akkadotnet/getakka.net#7 to help coordinate the efforts

depending on the size of your changes

Where communities thrive

People

Repo info

Activity