I just read To switch a full cluster restart is required and any overrides for classic remoting need to be ported to Artery configuration. Artery has a completely different protocol, which means that a rolling update is not supported. So for Flink use case is that ok? 何品
kerr <[email protected]> 于2023年9月8日周五 17:10写道： > I did a poll on reddit and get the result of > [image: image.png] > 何品 > > > kerr <[email protected]> 于2023年8月6日周日 00:33写道： > >> > Is it really worth spending any time to support classic remoting? Users >> would be better served to switch to Artery. >> >> I'm one of the user and the China Scala User group may not talk much on >> web but most of us is using the netty transport, even Lightbend say the >> `Artery is the best`. >> >> Another online product with large scale nodes(here) is running with Akka >> 2.4.x with the classic transport, and Flink is using the netty.tpc >> transport at least for now too. >> >> I think the community can choose when they migrate the nodes to artery is >> essential, especially when otherwise your cluster need a hard reboot. >> >> AFAIK, the Artery transport is not wire compatible with the classic one. >> >> I suggest: >> 1. Start to send PRs to open sources projects like Flink with the help >> for migrating to the artery transport. >> 2. Upgrade to the new version of Netty for bugfix and better performance. >> 3. Suggest all the new community move to the Artery transport. >> >> Even Akka was removed it in Akka 2.8.x not Akka 2.7.x. >> >> Anyway, different company has different requirements, that just my 2 >> cents. >> >> 何品 >> >> >> PJ Fanning <[email protected]> 于2023年8月2日周三 17:29写道： >> >>> This will end up in a vote. >>> >>> For me, we shipped 1.0.x. Users who don't want big changes can use >>> that version. We can agree to support 1.0.x with critical fixes. >>> >>> We can now start improving the code for the improvement release >>> (v1.1.x or v2.0.x). Improvements include getting rid of deprecated >>> code and most of us appear to believe that classic remoting is long >>> deprecated. >>> >>> >>> On Wed, 2 Aug 2023 at 09:51, Matthew de Detrich >>> <[email protected]> wrote: >>> > >>> > > 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 <[email protected]> >>> 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 >>> > > <[email protected]> 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 < >>> > > > [email protected]> >>> > > > 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 >>> > > > > <[email protected]> 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: [email protected] >>> > > > > For additional commands, e-mail: [email protected] >>> > > > > >>> > > > > >>> > > > >>> > > > -- >>> > > > >>> > > > 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:* [email protected] >>> > > > >>> > > >>> > >>> > >>> > -- >>> > >>> > 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:* [email protected] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>>
