Can't start up Akka.Cluster.AutoDowning when using custom dispatcher

[Zetanova]

Version Information
akka 1.4.28
akka, cluster

Describe the bug
After update to akka 1.4.28 from 1.4.22 cluster startup fails
This is again related to the misuse of loading extensions with the Lazy-blocking feature.
Related to #5185

Akka.Configuration.ConfigurationException: Couldn't create downing provider of type [Akka.Cluster.AutoDowning]
Error: ValueFactory attempted to access the Value property of this instance.
System.InvalidOperationException: ValueFactory attempted to access the Value property of this instance.

I begun already to rework the whole Akka.Extensions loading system view month ago and will try to finish it.
Beside to support task-inlining, the goal would be to support akka-system startup lock-free on a single thread.

[Zetanova]

It's not the task inlining feature.
It seams to be a bit different order of ActorCell exaction

[Zetanova]

It does currently only work because both the internal dispatcher and remote dispatcher are not shared.
The issue is visible with a shared dispatcher.

[Aaronontheweb]

Beside to support task-inlining, the goal would be to support akka-system startup lock-free on a single thread.

This is a great goal. We absolutely need to be able to do this.

[Zetanova]

I tried to make a multi-phase startup process,
what is missing is a native support for IServiceProvider and IServiceCollection
already in AkkaSystem (Akka.dll) and not a separate extension.
then the startup and hosting would be much better to be implemented.

[Aaronontheweb]

Why is that necessary?

…

Sent from my iPhone

On Nov 24, 2021, at 12:52 PM, Andreas Dirnberger ***@***.***> wrote:  I tried to make a multi-phase startup process, what is missing is a native support for IServiceProvider and IServiceCollection already in AkkaSystem (Akka.dll) and not a separate extension. then the startup and hosting would be much better to be implemented. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Zetanova]

If the AkkaSystem would require an instance to an IServiceProvider in the constructor and offer one scoped IServiceProvider as Member field like the Scheduler Field, then it would bring some benefits

main differences it would bring (hope for the better):

1. AkkaSystem would require the main/parant SP from Microsoft.Extensions.Hosting and could include AkkaConfig, AkkaExtensions
2. The ActorSystemImpl.LoadExtensions() would create extensions with ActivatorUtilities.CreateInstance(sp, extensionType, this)
   and/or simply use the IServiceProvider to create all registered extensions
3. All components could get a reference to the AkkaSystem and its ServiceProvider and create or request instance.

Downside would be new external references to:
IServiceProvider in asm System.ComponentModel
Maybe IServiceScope in asm Microsoft.Extensions.DependencyInjection.Abstractions

[Zetanova]

@Aaronontheweb If to include external references would be no valid option,
we could abstract the ActivatorUtilities into an Interface
and rebase the already existing IDependencyResolver from Akka.DependencyInjection to Akka

The AkkaSystemImpl itself can then use it with a basic implementation
and the Akka.DependencyInjection could replace it with its extended version.

A new project (i saw it somewhere) Akka.Hosting could be made,
that could provide Microsoft.Extensions.Hosting extensions.

The main effect would be that all AkkaExtensions would be known pre AkkaSystem startup
and would/should not be lazy loaded after startup completion.

This current feature of lazy loading extensions after AkkaSystem-startup
makes the main problems and is never really required/used.

[Zetanova]

Related to the above description is this PR #5152

[Zetanova]

i tried now the nigthly build 1.4.29-betaX and it did fix this issue.