Issue 1:
[√] I have searched the issues of this repository and believe that this is not a duplicate.

[√] I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.7.4.1

Operating System version: docker alpine in k8s

Java version: 1.8

register: nacos 1.1.3

Steps to reproduce this issue

Start module A and module B， A depends on B, the register is nacos. Now A invoke B's dubbo interface correct.

Restart module B, because in k8s and module B’s IP address is changed.

Now A invoke B correct, but A begin reconnect to the old provider B and can not stop. The logs as below:

Pls. provide [GitHub address] to reproduce this issue.

What do you expected from the above steps？

stop reconnect to the old provider

What actually happens?

Actual Result is cannot stop reconnect to the old provider

If there is an exception, please attach the exception trace:

[ERROR] 2020-03-31 22:16:19.303 [] [] [dubbo-client-idleCheck-thread-1] ReconnectTimerTask.doTask[51]: [DUBBO] Fail to connect to HeaderExchangeClient [channel=org.apache.dubbo.remoting.transport.netty4.NettyClient [10.42.1.119:0 -> /10.42.1.115:20881]], dubbo version: 2.7.4.1, current host: 10.42.1.119
org.apache.dubbo.remoting.RemotingException: client(url: dubbo://10.42.1.115:20881/com.alibaba.cloud.dubbo.service.DubboMetadataService?anyhost=true&application=mall-open&bind.ip=10.42.1.115&bind.port=20881&check=false&codec=dubbo&deprecated=false&dubbo=2.0.2&dynamic=true&generic=true&group=mall-goods&heartbeat=60000&interface=com.alibaba.cloud.dubbo.service.DubboMetadataService&lazy=false&methods=getAllServiceKeys,getServiceRestMetadata,getExportedURLs,getAllExportedURLs&pid=6&qos.enable=false&register.ip=10.42.1.119&release=2.7.4.1&remote.application=mall-goods&revision=2.2.0.RELEASE&side=consumer&sticky=false&timeout=30000&timestamp=1585642448627&version=1.0.0) failed to connect to server /10.42.1.115:20881 client-side timeout 3000ms (elapsed: 3000ms) from netty client 10.42.1.119 using dubbo version 2.7.4.1
at org.apache.dubbo.remoting.transport.netty4.NettyClient.doConnect(NettyClient.java:166)
at org.apache.dubbo.remoting.transport.AbstractClient.connect(AbstractClient.java:190)
at org.apache.dubbo.remoting.transport.AbstractClient.reconnect(AbstractClient.java:246)
at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeClient.reconnect(HeaderExchangeClient.java:155)
at org.apache.dubbo.remoting.exchange.support.header.ReconnectTimerTask.doTask(ReconnectTimerTask.java:49)
at org.apache.dubbo.remoting.exchange.support.header.AbstractTimerTask.run(AbstractTimerTask.java:87)
at org.apache.dubbo.common.timer.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:648)
at org.apache.dubbo.common.timer.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:727)
at org.apache.dubbo.common.timer.HashedWheelTimer$Worker.run(HashedWheelTimer.java:449)
at java.lang.Thread.run(Thread.java:748)
[ERROR] 2020-03-31 22:17:23.303 [] [] [dubbo-client-idleCheck-thread-1] ReconnectTimerTask.doTask[51]: [DUBBO] Fail to connect to HeaderExchangeClient [channel=org.apache.dubbo.remoting.transport.netty4.NettyClient [10.42.1.119:0 -> /10.42.1.115:20881]], dubbo version: 2.7.4.1, current host: 10.42.1.119
org.apache.dubbo.remoting.RemotingException: client(url: dubbo://10.42.1.115:20881/com.alibaba.cloud.dubbo.service.DubboMetadataService?anyhost=true&application=mall-open&bind.ip=10.42.1.115&bind.port=20881&check=false&codec=dubbo&deprecated=false&dubbo=2.0.2&dynamic=true&generic=true&group=mall-goods&heartbeat=60000&interface=com.alibaba.cloud.dubbo.service.DubboMetadataService&lazy=false&methods=getAllServiceKeys,getServiceRestMetadata,getExportedURLs,getAllExportedURLs&pid=6&qos.enable=false&register.ip=10.42.1.119&release=2.7.4.1&remote.application=mall-goods&revision=2.2.0.RELEASE&side=consumer&sticky=false&timeout=30000&timestamp=1585642448627&version=1.0.0) failed to connect to server /10.42.1.115:20881 client-side timeout 3000ms (elapsed: 3000ms) from netty client 10.42.1.119 using dubbo version 2.7.4.1
at org.apache.dubbo.remoting.transport.netty4.NettyClient.doConnect(NettyClient.java:166)
at org.apache.dubbo.remoting.transport.AbstractClient.connect(AbstractClient.java:190)
at org.apache.dubbo.remoting.transport.AbstractClient.reconnect(AbstractClient.java:246)
at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeClient.reconnect(HeaderExchangeClient.java:155)
at org.apache.dubbo.remoting.exchange.support.header.ReconnectTimerTask.doTask(ReconnectTimerTask.java:49)
at org.apache.dubbo.remoting.exchange.support.header.AbstractTimerTask.run(AbstractTimerTask.java:87)
at org.apache.dubbo.common.timer.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:648)
at org.apache.dubbo.common.timer.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:727)
at org.apache.dubbo.common.timer.HashedWheelTimer$Worker.run(HashedWheelTimer.java:449)
at java.lang.Thread.run(Thread.java:748)
[ERROR] 2020-03-31 22:18:27.303 [] [] [dubbo-client-idleCheck-thread-1] ReconnectTimerTask.doTask[51]: [DUBBO] Fail to connect to HeaderExchangeClient [channel=org.apache.dubbo.remoting.transport.netty4.NettyClient [10.42.1.119:0 -> /10.42.1.115:20881]], dubbo version: 2.7.4.1, current host: 10.42.1.119
org.apache.dubbo.remoting.RemotingException: client(url: dubbo://10.42.1.115:20881/com.alibaba.cloud.dubbo.service.DubboMetadataService?anyhost=true&application=mall-open&bind.ip=10.42.1.115&bind.port=20881&check=false&codec=dubbo&deprecated=false&dubbo=2.0.2&dynamic=true&generic=true&group=mall-goods&heartbeat=60000&interface=com.alibaba.cloud.dubbo.service.DubboMetadataService&lazy=false&methods=getAllServiceKeys,getServiceRestMetadata,getExportedURLs,getAllExportedURLs&pid=6&qos.enable=false&register.ip=10.42.1.119&release=2.7.4.1&remote.application=mall-goods&revision=2.2.0.RELEASE&side=consumer&sticky=false&timeout=30000&timestamp=1585642448627&version=1.0.0) failed to connect to server /10.42.1.115:20881 client-side timeout 3000ms (elapsed: 3000ms) from netty client 10.42.1.119 using dubbo version 2.7.4.1
at org.apache.dubbo.remoting.transport.netty4.NettyClient.doConnect(NettyClient.java:166)
at org.apache.dubbo.remoting.transport.AbstractClient.connect(AbstractClient.java:190)
at org.apache.dubbo.remoting.transport.AbstractClient.reconnect(AbstractClient.java:246)
at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeClient.reconnect(HeaderExchangeClient.java:155)
at org.apache.dubbo.remoting.exchange.support.header.ReconnectTimerTask.doTask(ReconnectTimerTask.java:49)
at org.apache.dubbo.remoting.exchange.support.header.AbstractTimerTask.run(AbstractTimerTask.java:87)
at org.apache.dubbo.common.timer.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:648)
at org.apache.dubbo.common.timer.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:727)
at org.apache.dubbo.common.timer.HashedWheelTimer$Worker.run(HashedWheelTimer.java:449)
at java.lang.Thread.run(Thread.java:748)

Issue 2:
I have searched the issues of this repository and believe that this is not a duplicate.

I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.7.0

Operating System version: any

Java version: 1.8

Steps to reproduce this issue

Our company's registry is able to support request route (same as TagRouter), but we are able to combine one invoker to two different route rule.

eg:

TagRoute1:

-> Group1 (weight: 1)

-> Invoker1

-> Gropu2 (weight: 9)

-> Invoker2

TagRoute2:

-> Group1 (weight: 5)

-> Invoker1

-> Gropu2 (weight: 5)

-> Invoker2

In the consumer side, the call to Invoker1 and Invoker2 will have 1:9 weight in TagRoute1. The 5:5 weight for them in TagRoute2.

The issue is that the dubbo get weight from invoker url, not in route level.

I have some ideas for that which one do you prefer? If solutions have been fixed, then i can send a PR to fix it.

Add setUrl method for Invoker, then we are able to set weight in invoker URL.

Extend the invoker with weight property, then we are able to set weight for each invoker in the Router level.

Extend the AbstractLoadBalance, we are able to extend the getWeight.

When

xxx

xxx

xxx

Pls. provide [GitHub address] to reproduce this issue.

Expected Result

What do you expected from the above steps？

Actual Result

What actually happens?

If there is an exception, please attach the exception trace:

Just put your stack trace here!