Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 11 23:52
    scptre commented #4082
  • Dec 11 14:26
    nagytech commented #3954
  • Dec 11 11:18
    nagytech edited #4089
  • Dec 11 11:17
    nagytech opened #4089
  • Dec 11 11:00
    nagytech commented #4083
  • Dec 11 08:34
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 07:57

    dependabot-preview[bot] on nuget

    (compare)

  • Dec 11 07:57

    dependabot-preview[bot] on dev

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:57
    dependabot-preview[bot] closed #104
  • Dec 11 07:52
    dependabot-preview[bot] synchronize #104
  • Dec 11 07:52

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:52
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    Aaronontheweb commented #104
  • Dec 11 07:43

    dependabot-preview[bot] on nuget

    (compare)

  • Dec 11 07:43

    dependabot-preview[bot] on dev

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

  • Dec 11 07:43
    dependabot-preview[bot] closed #102
Arjen Smits
@Danthar
Oh
I think I know what you mean
Your talking about implicit support for DI. So you don't have to do context.DI().ActorOf<IMyInterface>
and you can simply do this: context.ActorOf<IMyInterface>()
Is that what you mean?
what I mean is: it should be possible to use context/system.ActorOf<T> anywhere and not care about DI
DI is an implementation. The default props resolver could just complain "hey, I cannot resolve this type, it requires parameters", while if you set the DI resolver it would work
Arjen Smits
@Danthar
Ah yep. Thats exactly what I meant just now.
But this is not the first time we are having this particular discussion :P
Natan Vivo
@nvivo
oh, sorry. yes.. that's it =) I was writing in the gist, didn't see your comment
Arjen Smits
@Danthar
np
Natan Vivo
@nvivo
currently, DIExt lives in an external assembly
if only that interface (or some new interface) was moved to Akka, some simple logic could be used inside the actor system and any children to use that automatically
I'm trying to understand if that would break anything. Can you think of something?
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