> Is it really worth spending any time to support classic remoting? Users would be better served to switch to Artery.
That depends on what you mean by "support". If agreed on, I would propose marking classic remoting as "to be removed" which would also mean that the code wouldn't be touched (i.e. no feature changes and no bug fixes unless extremely critical). I am in no way suggesting that we support remoting in a traditional sense and again the only reason why I am even contemplating this is because of the CVE's. > 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. I also had this impression but it's already come up a few times that people still use Akka 2.4.x. They likely haven't bothered updating because they didn't see a need to (quite famously Akka is quite stable and there are cases of companies using it for years without needing to update, as stated by Lightbend's CEO) but with the license change it created a catalyst/trigger for some users to consider moving to Pekko. On this note I would also be wary in making assumptions on what versions of Akka people happen to be using. As a corollary in the discussion on dropping JDK 8, when we suggested that we quite quickly got feedback that there are people still using JDK 8. And while I know all of the arguments that you really should not be using JDK 8 can be carried over to Akka. Admittedly it's quite hard to get good feedback on what versions people are using, just saying we should be a bit more careful in making these assumptions. After all, people are still using JDK 8 ;) On Wed, Aug 2, 2023 at 10:19 AM Nicolas Vollmar <nvoll...@gmail.com> wrote: > 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 > > > -- 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
