[FLINK-32468][rpc] Switch from Akka to Pekko

[zentol]

Switch to the Apache fork of Akka. Akka support ends in September, so 1.18.x would eventually be affected.

I decided not to rename classes/modules because it feels like a lot of noise in the git history for virtually no gain.
May also make it easier to revert things if we do run into a problem during release testing.

[flinkbot]

CI report:

• c845c0d UNKNOWN
• b54a069 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[XComp]

flink-rpc/flink-rpc-akka-loader:pom.xml -> "Prevent akka and scala from being visible ..."
flink-rpc/flink-rpc-akka:pom.xml -> "For dependency convergence in Akka 2.6.20"
AkkaBasedEndpoint JavaDoc: "Interface for Akka based rpc gateways."
AkkaInvocationhandler JavaDoc: "The Akka (RPC) address of {@link #rpcEndpoint} ..."
AkkaInvocationHandler log: "... This is usually caused by: 1) Akka failed sending ..."
PriorityThreadsDispatcher JavaDoc: "Akka dispatcher threads creates..."
RemoteAddressExtension JavaDoc: "{@link akka.actor.ActorSystem} {@link Extension} used ..."
RobustActorSystem comment: "some parts of the akka shutdown procedure ..."
flink-table/flink-table-planner-loader/pom.xml: "Prevent akka and scala from being visible to ..."

I guess, the comments should be properly converted, though. Don't you think?

[XComp]

I decided not to rename classes/modules because it feels like a lot of noise in the git history for virtually no gain.
May also make it easier to revert things if we do run into a problem during release testing.

I see your point. But in my opinion, there are even more examples (besides the ones I mentioned in my previous comment) where we should switch to pekko, e.g. see AkkaOptions:361 which should actually point to https://pekko.apache.org/docs/pekko/current/remoting-artery.html#failure-detector

[zentol]

I did another pass over all references containing akka that aren't modules/classes/variables; this was mostly cosmetic but there were also genuine issues.
I also renamed all akka related config keys (with deprecated akka keys of course)

[XComp]

Renaming everything would make the review easier. 😇

Anyway, I'm wondering whether we could add a README to the flink-rpc-akka module where we could explain the history behind the Akka classes and Pekko documentation. But I understand that this could be also covered by the git history. I just think that having akka and pekko in the codebase side by side might be confusing to readers in the future.

Other code location I found:

• There is a config parameter TaskManagerOptions.EXIT_ON_FATAL_AKKA_ERROR that contains akka
• ActorSystemExtension and AkkaActorSystemTest have invalid references in its JavaDoc
• RpcEndpoint's JavaDoc mentions Akka
• nit: MessageSerializationTest mentions akka

[zentol]

There is a config parameter TaskManagerOptions.EXIT_ON_FATAL_AKKA_ERROR that contains akka

Which is deprecated.

[XComp]

I couldn't find any other occurrences except for the AkkaOptions which is @PublicEvolving. Shall we add a deprecation flag here and plan to rename it with 2.0? A spotless:apply run is missing. But it looks good otherwise.

On the other note: Have we thought of providing a separate module flink-rpc-pekko and providing that one along flink-rpc-akka in 1.18 with pekko being the default one? Or is this too much of an effort and we're comfortable enough that Pekko works as is?

And we might want to brief the 1.18 release managers on that PR considering that we missed the feature freeze for 1.18 last weekend.

[zentol]

Have we thought of providing a separate module flink-rpc-pekko and providing that one along flink-rpc-akka in 1.18 with pekko being the default one?

Yes, but that implies duplicating all classes and increasing the dist size by ~30mb.

Or is this too much of an effort and we're comfortable enough that Pekko works as is?

I wouldn't say I'm comfortable, but I think it's better to potentially break things now than doing this in a bugfix release or running with an unsupported Akka version,

Shall we add a deprecation flag here and plan to rename it with 2.0?

That's a separate discussion I believe because it's an API breaking change. But the idea itself is good.

[XComp]

The changes look good now. I will bring this PR up in tomorrows 1.18 release sync. Would we break anything if we also rename pom modules? ...now that we've renamed the packages and classes as well.

[zentol]

Would we break anything if we also rename pom modules?

I think it'd be annoying for devs, because that implies having to rebuild the rpc system whenever you switch between the pre and post pekko state of the project.

[XComp]

That's a good point. Nothing to add from my side. 👍 Let's wait for CI to become green and the release sync tomorrow.

[XComp]

fyi: the e2e1 test failure is fixed with FLINK-32632 in master

[XComp]

@mdedetrich pointed out today that there is a Pekko 1.0.1 release on the way. It includes a fix in pekko-remote which we use. It's not 100% clear whether the issue actually affects Flink users (it's about Scala class names with $). But considering that we have to do another CI run, anyway (due to the runtime-web test instability), it might be easy enough to bump the version to 1.0.1 right away. They triggered the publishing of the jars today (ML thread) and expect it to be done by tomorrow morning latest. WDYT?

On the topic of merging the PR: We got the verbal 👍 to merge this issue by the release managers in today's release sync. I was waiting for a summary of the meeting in the ML which didn't happen, yet.

[zentol]

I already restarted CI 30 minutes ago and would like to get this in today. If we haven't run into any issue so far I doubt we're affected by it (which seems more likely if you actually use Scala).

[zentol]

We can still bump it in the following days if needed.

[pjfanning]

I will release Pekko 1.0.1 jars early tomorrow (UTC). They are up for 24 hours for review. The pekko-remote issue is in an internal class but it is better to use the new release.

[pjfanning]

@zentol Pekko 1.0.1 is available now

[mdedetrich]

PR that bumps Pekko from 1.0.0 to 1.0.1 has been created at #23080

[He-Pin]

Hi team, I want to upgrade the current classic transport from netty 3 to netty 4 ,do you think that's ok?
I just asked on maillist https://lists.apache.org/thread/grzp3jw398rtpc6oqfybzxnry2mtyh64

[pjfanning]

Pekko 1.0.x will be maintained for a while. It is only Pekko 1.1.x where we are considering changing to netty 4 (or even dropping netty and just keeping Artery remoting).