> Supporting users who want to have mixed Akka and Pekko clusters - testing that will be hard. If anyone truly needs that then I think we will need dedicated extra resources for this work. With the current community size, it is hard to see us spending a lot of effort on this - or we will seriously delay a v1.0.0 release.
Take this with a grain of salt because I don't have a lot of experience here, but I don't think that supporting mixed cluster setups are technically difficult if we do the remote wire incompatibility changes (i.e. https://github.com/apache/incubator-pekko/issues/108). The biggest issue here is actually testing it, irrc there was some mixed cluster tests that are not running right now that also (before pekko) also had reliability issues. I would imagine that if someone was willing to test these mixed cluster cases and/or get these mixed cluster tests working then its not insurmountable barring that it does seem wise to not delay the release because of this. On Wed, Feb 15, 2023 at 4:58 PM PJ Fanning <[email protected]> wrote: > My preference is to update all 'akka' anything in Pekko code to > 'pekko'. This breaks compatibility but is cleaner (IMHO). > > Documenting and ideally, automating migrations from Akka to Pekko is > the way forward. > > Having Pekko code log warnings if it detects Akka on the classpath - > this is probably prudent. If we get news from users, that having both > libs on the classpath is not working, we may need to consider making > Pekko refuse to start. I do see a use case where someone wants to read > a message from an Akka actor instance and then forward it to a Pekko > actor instance. > > Supporting users who want to have mixed Akka and Pekko clusters - > testing that will be hard. If anyone truly needs that then I think we > will need dedicated extra resources for this work. With the current > community size, it is hard to see us spending a lot of effort on this > - or we will seriously delay a v1.0.0 release. > > On Wed, 15 Feb 2023 at 16:30, Matthew Benedict de Detrich > <[email protected]> wrote: > > > > Regarding making Pekko automatically handle Akka configuration, I have > > doubts as to whether this feature provides as much benefit as is implied. > > Configuration tends to be static and I have the impression that a far > nicer > > solution to the problem would be to write a script that generates any > > existing akka config to pekko config rather than making pekko handle akka > > config > > > > On Wed, Feb 15, 2023 at 4:27 PM Jean-Luc Deprez < > [email protected]> > > wrote: > > > > > The moment that the "can also parse akka HOCON prefix compat"-feature > gets > > > introduced things can turn rapidly sour though. > > > > > > Having both in a single JVM/Classloader tree structure is doubtedly > part of > > > any future ideal, but I a straight line towards that ideal could be > wishful > > > thinking. > > > Yet, I have sort of set my mind to doing exactly that 🤭 (so avoiding > the > > > duo) > > > > > > On Wed, Feb 15, 2023 at 3:33 PM Matthew Benedict de Detrich > > > <[email protected]> wrote: > > > > > > > Akka already has checks to make sure users don't mix and match > > > > different artifacts on the class path. There is undergoing work in > Pekko > > > to > > > > remove/fix these checks (i.e. see > > > > https://github.com/apache/incubator-pekko/pull/189) however it does > > > bring > > > > a > > > > general point about whether we should check if there are any Akka > > > artifacts > > > > on the classpath for users running Pekko and produce warnings in > such a > > > > case. > > > > > > > > I would predict that generally speaking if you are mixing Pekko and > Akka > > > > artifacts then this is likely a mistake and you are doing something > wrong > > > > even though technically speaking with all of the class/package/conf > > > changes > > > > there shouldn't be any conflicts (basically both ecosystems would > sit in > > > > their own silos). > > > > > > > > Thoughts? > > > > -- > > > > > > > > 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] > > -- 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]
