qos 端口冲突 3.1.2发现此问题 3.1.1 3.1.0 未发现此问题
可以提供个 demo 吗，我这边测试是可以的
可以提供个 demo 吗，我这边测试是可以的
就是启动两个生产者 就报端口冲突了 用的都是22222端口
可以提供个 demo 吗，我这边测试是可以的
就是启动两个生产者 就报端口冲突了 用的都是22222端口
两个生产者都是 -1 动态端口 设置qos=false就不报错了
这个报错是正常的，因为您明确指定了两个qos的port都是22222。
您之前没有出现该错误，很大可能的原因是当时的服务没有依赖dubbo-qos（包括间接依赖），服务启动过程中就自动忽略，即不启动qos，所以没有报错。
我已在3.1.1版本上用dubbo-demo-xml-provider模块加入dubbo-qos依赖后做了验证，同样会报端口占用的错。
这个报错是正常的，因为您明确指定了两个qos的port都是22222。
您之前没有出现该错误，很大可能的原因是当时的服务没有依赖dubbo-qos（包括间接依赖），服务启动过程中就自动忽略，即不启动qos，所以没有报错。
我已在3.1.1版本上用dubbo-demo-xml-provider模块加入dubbo-qos依赖后做了验证，同样会报端口占用的错。
我没有明确指定 我说的意思是 启动之后自动的两个端口都是22222
这个报错是正常的，因为您明确指定了两个qos的port都是22222。
您之前没有出现该错误，很大可能的原因是当时的服务没有依赖dubbo-qos（包括间接依赖），服务启动过程中就自动忽略，即不启动qos，所以没有报错。
我已在3.1.1版本上用dubbo-demo-xml-provider模块加入dubbo-qos依赖后做了验证，同样会报端口占用的错。
我不清楚有没有dubbo-qos依赖 我只添加了 dubbo-spring-boot-starter 3.1.1启动时没有这种问题的 只有3.1.2才会有
补充参数 dubbo: application: logger: slf4j metadataType: remote register-mode: instance service-discovery: migration: FORCE_APPLICATION protocol: name: dubbo port: -1 registry: address: nacos://${spring.cloud.nacos.server-addr} group: DUBBO_GROUP consumer: timeout: 3000 check: false
所以最好还是能提供重现的demo，这样就可以减少沟通中的信息误差
我没有明确指定 我说的意思是 启动之后自动的两个端口都是22222
也不会因为无意忽略掉的细微差别导致不能重现。
所以最好还是能提供重现的demo，这样就可以减少沟通中的信息误差
我没有明确指定 我说的意思是 启动之后自动的两个端口都是22222
也不会因为无意忽略掉的细微差别导致不能重现。
https://gitee.com/JavaLionLi/RuoYi-Cloud-Plus 这个项目的dev分支 dubbo版本改成 3.1.2 启动就会报错
这个
可以提供个 demo 吗，我这边测试是可以的
就是启动两个生产者 就报端口冲突了 用的都是22222端口
这个是一个提示信息，不影响进程正常工作。如果在同一台机器上启动两个进程，并且想正常使用 qos 的话，第二个进程需要指定不同的端口。
如果对qos没什么需要，可以先忽略。
这个
可以提供个 demo 吗，我这边测试是可以的
就是启动两个生产者 就报端口冲突了 用的都是22222端口
这个是一个提示信息，不影响进程正常工作。如果在同一台机器上启动两个进程，并且想正常使用 qos 的话，第二个进程需要指定不同的端口。
如果对qos没什么需要，可以先忽略。
启动两个不一样的生产者 这不是很常见的嘛
很常见。但如上所述，这个提示不影响功能，qos功能要想正常使用需要指定额外端口，否则可以忽略
要么就是：
3.1.2发现此问题 3.1.1 3.1.0 未发现此问题
不同版本间是个通用行为，还不清楚为何各个版本间有表现不一致的情况
3.1.2发现此问题 3.1.1 3.1.0 未发现此问题
不同版本间是个通用行为，还不清楚为何各个版本间有表现不一致的情况
3.1.1没有声明qos 调用的url上显示为false 3.1.2则在启动时报错
默认开启 qos 的逻辑已经存在好久了
默认开启 qos 的逻辑已经存在好久了
我不清楚你们的源码 但是现象如此 3.1.1 什么都没有配置 启动无异常 3.1.2启动报端口冲突 我只是反馈一下现象 如果设计如此 那这个帖子可以关闭了 我手动设置成false就行了