> 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
