Akka Typed: How to break all the things?

[rkuhn]

Once the scope is decided in #18 we need to start the implementation, and there I can see two possible paths:

1. start out from what we have in akka-actor, copy it over, and start modifying it (beginning with the removal of the Envelope :-) )
2. start from scratch, write a completely new ActorSystemImpl, in part inspired by what we have in akka-actor

The second one sounds attractive because it is easier to avoid adding something that is obsolete, but I fear that this approach is also too much waterfall, just like Akka Streams aimed to do all at once (yes, I appreciate that the situation was not exactly the same).

I am currently leaning towards the first approach because it will allow us to make incremental improvements while keeping the tests green. And the system remains shippable at all times—a brave move would be do actually do this on the master branch, but that means being absolutely clear that features are going away over time … this is unusual, if not unorthodox. But Akka has always done things a little differently.

Also in this case @akka/akka-team @MichaelPNash @hseeberger and all others please comment so that we can decide on a way forward.

[hseeberger]

From my personal experience a rewrite usually leads to better results for such a substantial change than a modification. By building the new solution step-by-step we could keep tests green, too.

[notxcain]

Agreed with @hseeberger!

[rkuhn]

The difficulty is that the first step will be a rather large one because the machinery to let an actor run is not that simple. But we can of course try that out (time-boxed).

[hseeberger]

Hmm ... a minimal runtime for a minimal actor shouldn't be too large.

[rkuhn]

To pass the tests it must support child actor creation, but perhaps you are right. I have three hours on a train now, let's see …

[patriknw]

It should be done in a way that it can be reviewed piecemeal. If that is done by adding piece by piece or removing/rewriting piece by piece doesn't matter for me.

[rkuhn]

I’m currently sketching it out in my head (and taking some notes): if all those things mentioned in #18 are actually removed, then the initial step might actually be of tolerable size, and then adding things one by one is easier to review than disentangling the old code—where things can easily be forgotten.

[viktorklang]

@rkuhn The entire Dispatcher setup can be dramatically simplified if configurability is reduced and using it as an ExecutionContext can be removed.

[rkuhn]

@viktorklang Yes, that was my plan: just use an Executor and be done with it.

[drewhk]

I agree on the high level goal of pushing people away from messing with Dispatchers but I have two use cases that I don't want to forfeit so easily:

• providing simulation/debugging capabilities. Maybe these can be done in other ways but currently hooking into mailbox+dispatcher is the most versatile option. This does not mean though that this should be through configuration, nor that it should be exposed to the general public.
• optimize dispatcher logic by being able to access more than a simple Runnable interface. I.e. try pinning actors to threads and moving them around less frequently, or any other domain driven heuristics. This requires something that is richer than an Executor.

[viktorklang]

@drewhk Yes, affinity and migrations etc would be interesting. There are a lot of research papers on that topic (OS Schedulers etc)

Personally I'd find it interesting to have a more «intelligent» scheduler—possibly with a custom backing thread pool.

[rkuhn]

Do these concerns really need more than a stable Runnable? My plan is that ActorCell extends Runnable directly. Then a stupid Executor is enough but a smart one has all the necessary information.

[drewhk]

Ok, casting down can work, the point is to be able to access more information if heuristics need it.

[drewhk]

Since it came up elsewhere, and since major changes are outlined here, I propose an addition:

• Make ActorRef's cryptographically unforgeable.
• Identify should be a service provided by an explicit actor and hence become a locked down service that needs to be explicitly exposed.

This can be a basis for a more fine grained capability based access control system (especially with composable behaviors).

[rkuhn]

The result of trying the “minimal” rewrite approach can be seen in akka/akka#21128. It is quite large since it is a fully working implementation that covers all the ground that the test suite verifies (apart from the Restart supervision behavior that is now missing).

@drewhk would you please ticketify your ActorRef identity proposals with a precise definition of what is meant? (we can then discuss over there, but my assumption is that using a strongly random Long UID should suffice—Identify will not exist anyway due to the change to explicitly exposed services and Receiptionists)

[drewhk]

would you please ticketify your ActorRef identity proposals with a precise definition of what is meant?

Done

Identify will not exist anyway due to the change to explicitly exposed services and Receiptionists

This is what I meant, yes. Otherwise you could just use Identify to get the ActorRef to anything, removing any protection the extended UID would give.

[drewhk]

Ah, the link: https://github.com/akka/akka-meta/issues/25