akkadotnet/akka.net

Port of Akka actors for .NET

Arjen Smits

@Danthar

I think @jcwrequests already explored this route. I remember him saying something along the lines: Not possible due to inner workings of Akka or something like that.

Natan Vivo

@nvivo

actually, it's not possible because that involves changing the akka dll to know about this.

Arjen Smits

@Danthar

I have no idea if that that is the case.

Natan Vivo

@nvivo

if you change the right bits, it's possible to make akka cook hamburguers

Looking at the Props, it works almost like a DI resolver

So, in theory it could decide "i can create this type or I'll delegate this to someone who can (the DI)"

but I'm not sure if this is a good approach

currently, the DI is registered inside the actor system. So, maybe the actor system could decide that...

Arjen Smits

@Danthar

Well. Make an issue for it =) Better to have this discussion in the tracker then here anyway. Because then it will be documented.

Because we had this discussion, about integration the DI system. Multiple times now ;)

Natan Vivo

@nvivo

yeah, I'm trying to understand if this is possible before opening a ticket

Nikita Tsukanov

@kekekeks

I think that any DI scope which effectively takes away lifecycle management from the ActorSystem, are not supported. Because it would mean that an Actor could be disposed without the Actor system being aware of it

Just wrap your ActorRef in something that implements IDisposable and kills the actor after being disposed

interface IDisposableActor<T> : IDisposable
{
    ActorRef Actor{get;}
}

class DisposableActor<T> : IDisposableActor<T>
{
    public ActorRef Actor {get; private set;}
    public DisposableActor()
    {
          Actor = ActorSystem.ActorOf<T>();
    }
    public void Dispose()
    {
         Actor.Tell(oisonPill.Instance, ActorRef.NoSender);
    }
}

Roger Johansson

@rogeralsing

Im not sure i follow, its not the actors that are injected, its dependencies into actors. So the actor ref would never be wrapped in anything in the di

Nikita Tsukanov

@kekekeks

I think that @Danthar tries to inject ActorRef in ASP.NET controller

And have it's lifetime managed by DI-container

Roger Johansson

@rogeralsing

Oh, that is not supported, you inject into actors, not actors into other stuff

Nikita Tsukanov

@kekekeks

It shouldn't be ever supported by Akka itself

Natan Vivo

@nvivo

@kekekeks actors don't need to be disposable

the actor system already knows exactly when they stop

Nikita Tsukanov

@kekekeks

actors don't need to be disposable

If you want DI container to manage something's lifetime on per-request basis you need it to be IDisposable

So if you need an actor per request, you wrap it in something that creates an actor for you and then kills it when request is complete

Natan Vivo

@nvivo

yes, but you don't need to do it with idisposable

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

Where communities thrive

People

Repo info

Activity