We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Environment Dubbo version: 2.7.2 Operating System version: Mac OS Java version: 1.8 Steps to reproduce this issue
Infos:
When I config TagRouter like this (in Dubbo admin):
--- force: false runtime: true enabled: true priority: 1 key: hello-service tags: - name: hello addresses: ["192.168.1.8","192.168.1.9"] ...
when without match dynamic tag and static tag Hope Result:
192.168.1.5(DEV) => 192.168.1.7(STABLE)
Actual Result:
192.168.1.5(DEV) => [NO PROVIDER]
原因:
消费方初始化refer时,在ReferenceConfig中会将consumer的配置参数放入一个map(具体参考ReferenceConfig类中第303行appendParameters(map, consumer)),然后在创建代理的时候会合并消费方和提供方的配置参数(参考ReferenceConfig类中第371行urls.add(ClusterUtils.mergeUrl(url, map));),之后在ClusterUtils中尽管会保留提供方的配置,参数,但是在消费方设置了dubbo.tag参数,而提供方未设置dubbo.tag的情况下,导致加了消费方默认的dubbo.tag;
appendParameters(map, consumer)
urls.add(ClusterUtils.mergeUrl(url, map));
然后在进行标签路由时,由于设置了动态标签路由,但是又没有匹配的提供方实例,最后会获取动态标签中不存在,且动态标签为空的实例(参考TagRouter类中第125~127行,如下)
// FAILOVER: return all Providers without any tags. else { List<Invoker<T>> tmp = filterInvoker(invokers, invoker -> addressNotMatches(invoker.getUrl(), tagRouterRuleCopy.getAddresses())); return filterInvoker(tmp, invoker -> StringUtils.isEmpty(invoker.getUrl().getParameter(Constants.TAG_KEY))); }
但是由于之前在refer的时候合并了参数,这边尽管Stable下的实例192.168.1.7的ProviderConfig URL中不带Dubbo TAG,这里还是会获取到消费方的默认标签DEV。
解决: 修改判断条件:
return filterInvoker(tmp, invoker -> StringUtils.isEmpty(url.getParameter(Constants.TAG_KEY)? StringUtils.isEmpty(invoker.getUrl().getParameter(Constants.TAG_KEY)) : invoker.getUrl().getParameter(Constants.TAG_KEY).equals(url.getParameter(Constants.TAG_KEY)) );
另外,发现标签路由的常量跟官方文档中不一致,实际上是:
org.apache.dubbo.rpc.cluster.TAG_KEY org.apache.dubbo.rpc.FORCE_USE_TAG
能够统一修正为:
org.apache.dubbo.rpc.cluster.TAG_KEY org.apache.dubbo.rpc.cluster.FORCE_KEY
The text was updated successfully, but these errors were encountered:
[Dubbo-4525] fix Clusterutils.mergeurl, make sure specific keys from …
a5f6090
…provider side not override by that from consumer. (#4533) Fixes #4525
No branches or pull requests
Environment
Dubbo version: 2.7.2
Operating System version: Mac OS
Java version: 1.8
Steps to reproduce this issue
Infos:
When I config TagRouter like this (in Dubbo admin):
when without match dynamic tag and static tag
Hope Result:
Actual Result:
原因:
消费方初始化refer时,在ReferenceConfig中会将consumer的配置参数放入一个map(具体参考ReferenceConfig类中第303行
appendParameters(map, consumer)
),然后在创建代理的时候会合并消费方和提供方的配置参数(参考ReferenceConfig类中第371行urls.add(ClusterUtils.mergeUrl(url, map));
),之后在ClusterUtils中尽管会保留提供方的配置,参数,但是在消费方设置了dubbo.tag参数,而提供方未设置dubbo.tag的情况下,导致加了消费方默认的dubbo.tag;然后在进行标签路由时,由于设置了动态标签路由,但是又没有匹配的提供方实例,最后会获取动态标签中不存在,且动态标签为空的实例(参考TagRouter类中第125~127行,如下)
但是由于之前在refer的时候合并了参数,这边尽管Stable下的实例192.168.1.7的ProviderConfig URL中不带Dubbo TAG,这里还是会获取到消费方的默认标签DEV。
解决:
修改判断条件:
另外,发现标签路由的常量跟官方文档中不一致,实际上是:
能够统一修正为:
The text was updated successfully, but these errors were encountered: