没仔细看，几个建议： * epoll 打开与否目前只和 netty4 绑定，合理的做法是和 protocol 上的 transporter 绑定。或者在应用级别来控制(虽然现在只有 netty4 才支持)。也就是说没有必要在 provider, consumer, protocol 上都有是否支持 epoll 的判断 * epoll 只是对 linux 平台上 native transport 的支持而已，更合理的做法是把 `AbstractSupport` 和 `NettySupport` 合并成 `NativeTransportFactory`，用来根据配置和平台自动返回对应的 `SocketChannel` 和 `EventLoopGroup` 的实例，当然出错情况下自动 fallbak 回 nio
综上所述，看起来 Transporter 应该有一个 TransporterConfig，或者干脆在 app 级别上定义。如果想不清楚，暂时通过 system properties 指定也是可以的。Native Transport 的支持需要考虑全平台，而不是只有 linux 上的 epoll，做成 factory 模式，出错 fallback 到 nio --- I have a couple of suggestions after take a glance at the implementation: * Right now, epoll support is tightly coupled with transport `netty4`, which I think it is fine, but from the perspective of its configuration, I believe more reasonable place for this configuration is transporter, or in my own opinion this configuration for whether enable native transport or now is global configuration, and should be applied to application level, even though currently we will only have its support for linux on netty4. It is unnecessary and unreasonable to have the individual configuration for enabling epoll on different levels like provider, consumer, and protocol. * Right now the implementation focus on epoll support only, we should consider more. Besides epoll on linux, we should also support kqueue on Mac/BSD, see https://netty.io/wiki/native-transports.html for more details. What I suggest is to implement a `NativeTransportFactory` by combining and enhancing the code in `AbstractSupport` and `NettySupport` together to produce the appropriate instances for `SocketChannel` and `EventLoopGroup` according to the platforms and the configurations the current application is running on. Of course, this factory should fallback to return the nio instances if anything goes wrong. In summary, we should either define 'native-transporter' on ApplicationConfig or TransporterConfig (not introduced yet). It is also reasonable to introduce it with a system property if we cannot make the decision now. For native transport support, we should consider not only epoll on linux, but also others. [ Full content available at: https://github.com/apache/incubator-dubbo/pull/2738 ] This message was relayed via gitbox.apache.org for [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
