apache
Extract classical transport to dedicated modules and provide both Netty 4.1 and Netty 4.2 implementations?
Some users are using an old version of Netty, eg, Netty 4.1.x. If the user upgrades to the new version of Pekko 1.2.x but does not upgrade other dependencies, then an error will happen...
We encounter this problem at $Work and have to exclude the Netty 4.2 dependency.
Should we split the Netty transport into two modulestransport-netty41 and transport-netty42?
refs: https://github.com/apache/pekko/pull/1794
- pekko 1.1 supports netty 4.1 - users who like netty 4.1 can just simply not use pekko 1.2
- we wouldn't make a major refactor like this in this 1.x line
- by the time, we release pekko 2.0.0, most people will have upgraded to netty 4.2
- netty 4.2 is not even a big upgrade - most netty 4.1 users should be able to upgrade with little or no code change
- We encounter this at $Work just now, we have to set
-Dio.netty.allocator.type=pooledto avoid that, there user's Netty version is been overrided by Pekko 1.2.0-M2
We can have 3 modules, pekko-remote-transport-netty-base pekko-remote-transport-netty41 and pekko-remote-transport-netty42, which only need to adust 1/2 lines of code.
We can't refactor pekko like this in a minor release. Stick with pekko 1.1 until you can sort out the netty issues. You can also fork pekko and do whatever you like to the fork.
Can you link the netty issue tracking this so other users can follow what is going on on the netty side?
https://github.com/apache/pekko/pull/1555 , another option is backport this to 1.1.x
- we may end up dropping netty altogether in pekko 2
- by the time pekko 2 is released (6 months or more), won't netty team have fixed their issues?
- Extracting the classical transport will make the Pekko-remote not depend on Netty anymore, Not sure about this, Flink is still using the classical transport, I suggest we extract it to a dedicated module.
- Yes, but the user can have complex dependencies....
One possible workaround is to use Pekko 1.2.0-M1. We haven't heard anything bad about this release. It uses netty 4.1 and has the #1555 change too.
If we choose to keep the netty code in Pekko 2.0.0, I wouldn't be against putting it in a separate pekko-remote-netty module that extends on pekko-remote but has the netty specific classes. I don't think we should support multiple netty versions though (by having multiple modules, one for each netty version).