Skip to content
New issue

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

dubbo-2.7.1 providers 重复注册 #3785

Closed
nevin9939 opened this issue Apr 1, 2019 · 11 comments
Closed

dubbo-2.7.1 providers 重复注册 #3785

nevin9939 opened this issue Apr 1, 2019 · 11 comments
Milestone

Comments

@nevin9939
Copy link

nevin9939 commented Apr 1, 2019

服务第一次正常启动后,可以在zookeeper中的对应接口的providers下看到正常注册的服务,但是当Tomcat停止后,改providers下的服务仍然存在,Tomcat重新启动后,providers下相同的服务又注册了一遍,结果providers下存在了两个服务,一个是本次Tomcat启动后注册进去的,一个是上次Tomcat启动注册进去的,没有销毁,两个服务的区别主要是pid和timestamp不一样,因服务端的配置使用-1随机端口,偶尔两个服务的port也不一样;结果providers下的两个服务一个可以被客户端调用,一个不能,造成客户端偶发调不通服务的现象。
不知道为什么在Tomcat停止后,zookeeper中接口providers下,失效的服务为什么没有销毁
tttttttttttt

@nevin9939
Copy link
Author

原因找到了
org.apache.dubbo.config.AbstractServiceConfig#dynamic
原来的默认值是null
现在调整成默认false了,不知道这样调整的好处是什么,至少在我的这个场景产生了BUG

@carryxyh
Copy link
Member

carryxyh commented Apr 1, 2019

Hi, thanks for your issue.
I'd like take a look.

@kingcode100
Copy link

我也出现了相同的BUG ,于是我尝试配置dynamic=true,用下面3种方式各试了一遍。发现不会生效,只能注册静态服务了
dubbo.service.dynamic=true
dubbo.registry.dynamic=true
dubbo.protocol.dynamic=true

@kingcode100
Copy link

服务第一次正常启动后,可以在zookeeper中的对应接口的providers下看到正常注册的服务,但是当Tomcat停止后,改providers下的服务仍然存在,Tomcat重新启动后,providers下相同的服务又注册了一遍,结果providers下存在了两个服务,一个是本次Tomcat启动后注册进去的,一个是上次Tomcat启动注册进去的,没有销毁,两个服务的区别主要是pid和timestamp不一样,因服务端的配置使用-1随机端口,偶尔两个服务的port也不一样;结果providers下的两个服务一个可以被客户端调用,一个不能,造成客户端偶发调不通服务的现象。
不知道为什么在Tomcat停止后,zookeeper中接口providers下,失效的服务为什么没有销毁
tttttttttttt

请教一下,目前是怎么解决这个问题的。

@nevin9939
Copy link
Author

@kingcode100 我把源代码修改了,然后重新打包本地用

@cvictory
Copy link
Contributor

cvictory commented Apr 3, 2019

@carryxyh @nevin9939 Do you fix this issue? Or can you commit a pr?

@carryxyh
Copy link
Member

carryxyh commented Apr 3, 2019

Hi, @cvictory
Seems like we should make dynamic default true to make the info delete from zk when provider/consumer shutdown.

But I am not sure about why the default value changed to false at beiwei's pr...

@carryxyh
Copy link
Member

carryxyh commented Apr 3, 2019

Sent an email and wait for beiwei's reply.

@cvictory
Copy link
Contributor

cvictory commented Apr 3, 2019

I think the default value of dynamic should be null in AbstractServiceConfig

@beiwei30
Copy link
Member

beiwei30 commented Apr 3, 2019

The original change made for fixing issue #195: @reference check=false不生效 (#3530). For some particular boolean flags, it should have the default value in order to align with the default value from the annotation.

In this case, the original value is null and the annotation default value is false. I double checked how this value is used, and figured out its default value should be 'true', or roll back to null.

@carryxyh would you mind to give it a try to change it to

protected Boolean dynamic = true;

pls. keep in mind you also need to change the default value from the annotation:

boolean dynamic() default true;

@beiwei30 beiwei30 added this to the 2.7.2 milestone Apr 3, 2019
@carryxyh
Copy link
Member

carryxyh commented Apr 3, 2019

@beiwei30 Thx for your reply.

@cvictory Seems like true will be better for default value ? Since we should keep Config class same with Annotation. But Annotation can't make default value null.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants