Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 12:20
    IgorFedchenko commented #3973
  • 12:17
    IgorFedchenko commented #3973
  • 11:58
    IgorFedchenko synchronize #3973
  • 11:33
    IgorFedchenko commented #3973
  • 11:25
    IgorFedchenko synchronize #3973
  • 07:04
    dependabot-preview[bot] labeled #3996
  • 07:04
    dependabot-preview[bot] opened #3996
  • 07:04

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • 07:04
    dependabot-preview[bot] labeled #3995
  • 07:04

    dependabot-preview[bot] on nuget

    Bump BenchmarkDotNet from 0.10.… (compare)

  • 07:04
    dependabot-preview[bot] opened #3995
  • Oct 17 22:42
    Aaronontheweb commented #3944
  • Oct 17 22:41
    Aaronontheweb commented #3973
  • Oct 17 21:17
    IgorFedchenko commented #3973
  • Oct 17 21:08
    IgorFedchenko commented #3973
  • Oct 17 19:59
    IgorFedchenko synchronize #3973
  • Oct 17 19:34
    IgorFedchenko synchronize #3973
  • Oct 17 16:12
    Aaronontheweb commented #3993
  • Oct 17 15:51
    dependabot-preview[bot] synchronize #3991
  • Oct 17 15:51

    dependabot-preview[bot] on nuget

    Bump Microsoft.Extensions.Depen… (compare)

Natan Vivo
@nvivo
=)
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
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