Akka 2.4 has been EoL since end of 2017. I don't think it is likely that a significant portion of Akka 2.4 users would update to Pekko any time soon if the couldn't update to Akka 2.5/2.6.
Is it really worth spending any time to support classic remoting? Users would be better served to switch to Artery. On Wed, 2 Aug 2023 at 10:04, Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> wrote: > > If you manage to move to Pekko and were still using classic remoting, > it's likely you are still on Akka 2.4 or 2.5. If you manage the update > to Pekko, going to Artery TCP is a small step. > > One of the reasons why I was saying this is that I was under the impression > that there are a non-trivial amount of users still on Akka 2.4 (not sure > why > this is the case but kerr was telling me this). > > > If people are interested in keeping it around and also opt in to > maintaining it (which in the first place means, making the tests for > it work *now*), than fine, but otherwise, being able to use it on > 1.0.x is already a big benefit. > > Since classic remoting is currently using Netty 3 which has CVE's > I don't think it's wise to encourage people that still happen to be > using classic remoting to stay on 1.0.x. If it wasn't for final > version of netty 3 having CVE's then I would have no qualms > for dropping it in the 1.1.x series (in fact if there was a > hypothetical netty 3 without CVE's we would have already > updated to it in the 1.0.x series and dropped classic remoting in > 1.1.x without a heartbeat). > > I would propose that if we do accept keeping classic remoting > and updating to Netty 4, we would mark the feature to be > dropped in 1.2.x and aside from that Netty 4 upgrade that > part of code would be untouched unless there are critical > bugs/regressions. > > On Tue, Aug 1, 2023 at 1:38 PM Johannes Rudolph < > johannes.rudo...@gmail.com> > wrote: > > > We definitely should remove it for 1.1.x. There's no technical reason > > to keep it because the newer artery TCP transport just supersedes it. > > As discussed before, the problem with keeping old features around is > > "death by a thousand cuts". The classic remoting backend is the prime > > example of it because it is basically unmaintained for years and > > there's basically no expert knowledge available about how to maintain > > it or how to fix the existing bugs. Testing remoting backends has > > shown to be very complicated and often unreliable and being able to > > remove this particular component from the test matrix will be a huge > > improvement. > > > > On Mon, Jul 31, 2023 at 11:28 PM Matthew de Detrich > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > I would prefer adding in netty 4 support for the classic transport > > > mechanism because it gives > > > people an upgrade path while allowing them to resolve the CVE issues. > If > > > Pekko 1.1.x didn't > > > support the classic transport mechanism then it forces Pekko users to > be > > > stuck on 1.0.x > > > with no easy upgrade path. > > > > We are not responsible for giving people an easy upgrade path when > > they were stuck on features like classic remoting which has basically > > been outdated for years. It is very important that, going forward, > > that we focus our attention on the most important features and make > > sure to not get stuck in maintaining old parts that we cannot (or > > don't want to) care for. > > > > If people are interested in keeping it around and also opt in to > > maintaining it (which in the first place means, making the tests for > > it work *now*), than fine, but otherwise, being able to use it on > > 1.0.x is already a big benefit. > > > > Apart from that the update path is pretty clear: > > * move to Pekko 1.0.x > > * move to Arterty TCP > > * move to Pekko 1.1.x > > > > If you manage to move to Pekko and were still using classic remoting, > > it's likely you are still on Akka 2.4 or 2.5. If you manage the update > > to Pekko, going to Artery TCP is a small step. > > > > Johannes > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >
