Akka.net: Dependency injection for remote deployment

[Horusiath]

At the present moment DI is not supported in remote deployment scenarios. This is a thread to discuss potential solution for such cases.

[rogeralsing]

My impression was that it was supposed to work with remote deployment as it is based on DIActorProducer : IndicrectActorProducer IndirectActorProducers are supposed to be possible to pass over the wire with the Props.
So if the same DI plugin exists on the remote system, it should in theory work.
Is this not the case?

(never used the DI support myself, never been a fan of DI containers)

[Aaronontheweb]

No, that stuff doesn't get serialized (correctly?) today

[rogeralsing]

The current design of DI is broken for remoting scenarios.

Each resolver have a constructor that takes a container and a system.
Thus, the resolver can not serialize. the serializer needs to be able to pass just the resolver Type to the remote system and instantiate it there.

public AutoFacDependencyResolver(ILifetimeScope container, ActorSystem system)
{
      if (system == null) throw new ArgumentNullException("system");
      if (container == null) throw new ArgumentNullException("container");
      this.container = container;
      typeCache = new ConcurrentDictionary<string, Type>(StringComparer.InvariantCultureIgnoreCase);
      this.system = system;
      this.system.AddDependencyResolver(this);
      this.references = new ConditionalWeakTable<ActorBase, ILifetimeScope>();
}

That being said, I think there might be some workarounds to make this work.
First, if we use surrogates on the resolvers, we can easily get access to the current actorsystem when deserializing, as the system is one of the args passed to the surrogate mechanism.
But we still somehow need to get access to the container instance, so that can be injected into the resolver also.
Here I'm thinking that the DI plugin somehow could provide a container factory of some sort.

If the DI plugin can give us the container, and surrogates gives us the actor system, then I think we can make this fly for remote deployment too.
And I really think we should put some effort into this as IndirectActorProducers are designed to work for remote deployment..

Thoughts?

[SeanFarrow]

Now that we have wire, does this change the status of this issue?
I'm looking in to being able to do this fairly soon.
Also, as per roger's container factory idea, how would the factory know what container to return, this would probably need to take in, or hang off the DependencyResolver. I'm just thinking out loud!

[Gradi]

Is there any news about DI support in akka-remote?

[psandler]

I second @Gradi question. Asked on gitter but no response yet.

[Aaronontheweb]

This is a scenario we're unlikely to support. Remote deployment isn't used all that often as-is today, let alone in combination with DI. If you _really need_ to do this, you can do it yourself by using the remote fan-out pattern: remotely deploy a parent who then locally deploys a child using the Context.DI.Props method.

[alireza267]

Will dependency injection for remote system problem be solved in version 1.4.15 by module Akka.DependencyInjection ?
@Aaronontheweb

[Aaronontheweb]

@alireza267 I don't think so, at least not in this iteration. In theory we could do it, but we'd have to take a dependency on Micrsosoft.Extensions.DependencyInjection in the core library, which I've been wanting to avoid...

[SeanFarrow]

Could we not have a contracts project in the core library and then have separate implementations?
Thanks,
Sean.

From: Aaron Stannard [e-mail]
Sent: 18 January 2021 13:10
To: akkadotnet/akka.net [e-mail]
Cc: Sean Farrow [e-mail]; Comment [e-mail]
Subject: Re: [akkadotnet/akka.net] Dependency injection for remote deployment (#1267)

@alireza267https://github.com/alireza267 I don't think so, at least not in this iteration. In theory we could do it, but we'd have to take a dependency on Micrsosoft.Extensions.DependencyInjection in the core library, which I've been wanting to avoid...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/akkadotnet/akka.net/issues/1267#issuecomment-762240930, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALDK7SAJDZJ7LGQLAMIVG3S2QXMHANCNFSM4BN2YKAA.