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
