AlbumenJ commented on issue #11716:
URL: https://github.com/apache/dubbo/issues/11716#issuecomment-1926076147
> > > > Metadata 这个服务目前是已知的不加载 Filter 的，建议在你们的 Filter 中也排除掉这个服务
> > >
> > >
> > > 这个是从哪个版本开始调整的？`dubbo-3.1.1`使用中没出现这个。
> > >
原来如此，这样会有问题。因为业务应用都是通过`dubbo.provider.filter=xxx`统一配置自定义Filter，Filter中会使用`RpcContext.getServiceContext().isConsumerSide()`，而请求getMetadataInfo会走到这些Filter。
> > > 既然Metadata这个服务不加载Filter，为何其服务请求还要走Filter呢，建议两边保持一致语义。
> >
> >
> >
> > 1. 3.2.4
> > 2. 因为使用的是 `serviceConfig.setFilter("-default")`, 只能保证 Dubbo 内部的 Filter
被排除
> > 3. 如果全部的 Filter 包括用户侧的，如果有的用户期望注入一些自定义的东西就没办法工作了
>
> 2.
Filter被排除的意义有哪些？影响范围有哪些？我的理解，getMetadataInfo只会在节点上下线或动态伸缩时才会触发请求，调用量不大，性能损失带来的收益比不是很高
> 3.
另一种使用场景，业务自定义Filter若依赖系统层面的Filter做的事情，升级后会一大堆出现提供者元数据获取失败，牵一发而动全身。我们现在是通过在自定义Filter运行之前先运行`ContextFilter`解决，`dubbo.provider.filter=context,xxx`，因为改代码让业务方配合升级，每个应用都复制了一份这样的Filter，难度增加容易遗漏。这个是框架层面未向前兼容，是框架层面的事情，还是用户层面？若是用户层面的事情，如何调整自定义Filter代码，绕过context配置。尝试了`RpcContext.getServiceContext().isConsumerSide()`或`RpcContext.getServerAttachment().isConsumerSide()`都报NPE，可以把URL中的provider参数拿出来，`invoker.getUrl().getSide(PROVIDER_SIDE).equals(CONSUMER_SIDE)`，这样判断
> 4. 提个建议，getMetadataInfo也没必要使用这些Filter，内部服务能否一起屏蔽掉所有Filter（包括用户侧）？
2. 之前有些用户定义的默认 FIlter 被加载，导致非预期行为（和这个 issue
很像，区别是之前的是默认加载你这个是指定加载；之前修复的时候留了个指定加载的口子）
3. 4. 是的，所以可以考虑在 3.3 这种大版本升级引入改动
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
