Handle mixed akka/pekko protocol names

[mdedetrich]

Resolves: #108

Some additional changes were made in #1112

Described in https://cwiki.apache.org/confluence/display/PEKKO/Pekko+Akka+Compatibility

[pjfanning]

There is also https://github.com/apache/incubator-pekko/blob/00c6bac1a70d2e0dc0408a4699d136d599855462/remote/src/main/scala/org/apache/pekko/remote/transport/PekkoProtocolTransport.scala#L76

[mdedetrich]

incubator-pekko/remote/src/main/scala/org/apache/pekko/remote/transport/PekkoProtocolTransport.scala

Thanks pushed, lets see if it breaks anything

[pjfanning]

is the intention to add some akka protocol tests in this PR or maybe in a follow up PR?

[mdedetrich]

is the intention to add some akka protocol tests in this PR or maybe in a follow up PR?

The intention is to add the tests in the same PR, hence why its a draft.

[pjfanning]

@mdedetrich what would you think of merging this soon more or less as is but we document it as experimental. Then we can release v1.0.2 with this and see if we can crowdsource the testing. Alternatively, we add it to main only, for now and release v1.1.0-M1 and again see if we can get people to test with it.

[mdedetrich]

@mdedetrich what would you think of merging this soon more or less as is but we document it as experimental. Then we can release v1.0.2 with this and see if we can crowdsource the testing. Alternatively, we add it to main only, for now and release v1.1.0-M1 and again see if we can get people to test with it.

Not really confident merging this as is because @He-Pin said that the issue is more complicated and we also need to do port roll-over to.

[pjfanning]

Ports are configurable already. For now, mixed cluster users can use Akka port numbers. They can even use Akka ports after the whole cluster is Pekko. We can add support for mixed port numbers later.

[pjfanning]

I think this PR is bettered targeted at main branch. We can backport it when we have something that we are confident in. We can merge experimental or partial impls to main.

[mdedetrich]

I think this PR is bettered targeted at main branch. We can backport it when we have something that we are confident in. We can merge experimental or partial impls to main.

@He-Pin Brought up an interesting point in that this may only be needed in 1.0.x because there is a presumption that once you migrate from an Akka cluster to a Pekko one running 1.0.x, there is no reason that the feature would be needed in 1.1.x (even though we are technically "breaking users").

Given this and the fact that there is a community agreement that all migration (from Akka) related features should land in Pekko 1.0.x I think leaving this to target 1.0.x is the right decision.

[pjfanning]

I disagree about having this as a v1.0.x only feature. We've already had users who have tried to switch to Pekko from a version of Akka newer than v2.6. In the real world, we will have Akka users who reach the size where they need to pay license fees. If we add this feature, there is no reason not to keep it for a while. And if we then agree that it is useful to support this for a while (maybe 2 years as an example) then that makes it tidier to develop this on main branch - especially since we can release milestone versions.

[mdedetrich]

I disagree about having this as a v1.0.x only feature. We've already had users who have tried to switch to Pekko from a version of Akka newer than v2.6. In the real world, we will have Akka users who reach the size where they need to pay license fees. If we add this feature, there is no reason not to keep it for a while. And if we then agree that it is useful to support this for a while (maybe 2 years as an example) then that makes it tidier to develop this on main branch - especially since we can release milestone versions.

I'm not disagreeing about it being in both versions, I am just saying that it has to land in 1.0.x as agreed upon and if it's going in 1.1.x as well then it makes sense for the feature to be complete and tested before the 1.1.0 full release otherwise we will have feature gaps

[pjfanning]

I want to see this in 1.1.0-M1. It makes it easier for people to try it out. M1 is also a release that we can caveat. A 1.0.3 release would be expected to have well tested, working code. This change still feels experimental but worth experimenting with nonetheless.

[pjfanning]

@mdedetrich noone seems to object to a 1.0.3-M1. Can we merge this? If we end up with an urgent 1.0.x bug fix issue, we could revert this again - but the likelihood is that the next 1.0.x release will be 1.0.3-M1. It would be nice to have these changes in a snapshot for some pre 1.0.3-M1 testing.

[mdedetrich]

@mdedetrich noone seems to object to a 1.0.3-M1. Can we merge this? If we end up with an urgent 1.0.x bug fix issue, we could revert this again - but the likelihood is that the next 1.0.x release will be 1.0.3-M1. It would be nice to have these changes in a snapshot for some pre 1.0.3-M1 testing.

Sure, changed it to review status. It just needs a review.

[pjfanning]

lgtm