Pre-check

  • [x] I am sure that all the content I provide is in English.

Search before asking

  • [x] I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Dubbo version: 3.2.5 Java version: 17 springboot：3.4.0 zookeeper：3.8.4

Steps to reproduce this issue

ServiceA is the provider, and ServiceB is the consumer. When ServiceA is redeployed, the IP address changes. The specific steps are: after the new instance starts successfully, it registers with Zookeeper, and the old instance is destroyed. During the deployment period, Service B (the consumer) reports an error indicating that it cannot connect to the provider (the new instance). The exception information is as follows:

2025-04-19 10:00:00,108(NettyClientWorker-5-2] ERROR NettyConnectionHandler:- [DUBBO1 Fail to connect to null dubbo version: 3.2.5, current host xx.xx.xx.xx, error code: 6-16. This may be caused by,go to https://dubbo.apache.org/faq/6/16 to find instructions. org.apache.dubbo.remoting.RemotingException:client(url:DefaultServiceInstance(serviceName='service-provider’ host='xx.xx.xx.xx, port=54xxx enabled=true, healthy=true, metadata={dubbo.endpoints=[{"port":54xxx,"protocol":"tri"}], dubbo.metadata-service.url-params={"preferserializati on":"hessian2","timeout":"10000","version":"1.0.0","dubbo":"2.0.2*,"release":"3.2.5","side:"provider","port":"63xxx",protocol: meta”), dubbo.metadata.revision=xxxxxxcc8cede644a069bb5875xxxxxx, dubbo.metadata.storage-type=local, timestamp=1742637xxxxxx)}) failed to connect to server /xx.xx.xx.xx:54xxx, error message is:拒绝连接:/xx.xx.xx.xx:54xxx at org.apache.dubbo.remoting.transport.netty4.NettyConnectionClient.doConnect(NettyConnectionClient.java:179) ~[dubbo-3.2.5.jarl/:3.2.5] at org.apache.dubbo.remoting.transport.netty4.NettyConnectionHandlerlambda$reconnect$O(NettyConnectionHandlerjava:86) ~[dubbo-3.2.5.jar!/:3.2.5] at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)~[netty-common-4.1.118.Finaljar!/:4.1.118.Final] at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTaskjava:156)~[netty-common-4.1.118.Final.jar1/:4.1.118.Final] atio.netty.util.concurrent.AbstractEventExecutorrunTask(AbstractEventExecutorjava:173)~[netty-common-4.1.118.Final.jar1/:4.1.118.Final] atio.netty.util.concurrent.AbstractEventExecutorsafeExecute(AbstractEventExecutorjava:166)~[netty-common-4.1.118.Final.jar!/:4.1.118.Final] atio.netty.util.concurrent.SingleThreadEventExecutorrunAllTasks(SingleThreadEventExecutorjava:472)~[netty-common-4.1.118.Final.jarl/:4.1.118.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)~[netty-transport-4.1.118.Finaljarl/:4.1.118.Final] atio.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutorjava:998)~[netty-common-4.1.118.Final.jar!/:4.1.118.Final] atio.netty.utilinternal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)~[netty-common-4.1.118.Finaljar!/:4.1.118.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)~[netty-common-4.1.118.Final.jarl/:4.1.118.Final] at java.base/java.lang.Thread.run(Thread.java:840) [?:?] Caused by:io.netty.channel.AbstractChannel$AnnotatedConnectException: 拒绝连接: /xx.xx.xx.xx:54xxx Caused by:java.net.ConnectException: 拒绝连接 at java.base/sun.nio.ch.Net.pollConnect(Native Method) ~[?:2] atjava.base/sun.nio.ch.Net.pollConnectNow(Net.java:672) ~[?:?] at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:946) ~[2:2?] at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:336) ~[netty-transport-4.1.118.Finaljar!/:4.1.118.Final] atio.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:339) ~[netty-transport-4.1.118.Final.jarl/:4.1.118.Final] atio.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:784)~[netty-transport-4.1.118.Final.jarl/:4.1.118.Final] atio.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732) ~[netty-transport-4.1.118.Final.jarl/:4.1.118.Final] atio.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)~[netty-transport-4.1.118.Final.jar!/:4.1.118.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.118.Finaljarl/:4.1.118.Final] ...4 more

What you expected to happen

The consumer connects to the provider normally.

Anything else

No response

Are you willing to submit a pull request to fix on your own?

  • [ ] Yes I am willing to submit a pull request on my own!

Code of Conduct

Comment From: heliang666s

Hello @engenou,

This is not a Dubbo bug. The connection refusal you encountered is a normal behavior in distributed systems due to eventual consistency in service registries like Zookeeper.

During provider (ServiceA) redeployment, the consumer (ServiceB) might still hold outdated addresses for a short time, causing temporary connection failures. This is expected in systems that prioritize availability over strong consistency (CAP theorem).

Suggested Solutions: Provider side: use delayed registration

Provider side: enable graceful shutdown

Consumer side: disable strict check and add retries

Comment From: engenou

Hello @engenou,

This is not a Dubbo bug. The connection refusal you encountered is a normal behavior in distributed systems due to eventual consistency in service registries like Zookeeper.

During provider (ServiceA) redeployment, the consumer (ServiceB) might still hold outdated addresses for a short time, causing temporary connection failures. This is expected in systems that prioritize availability over strong consistency (CAP theorem).

Suggested Solutions: Provider side: use delayed registration

Provider side: enable graceful shutdown

Consumer side: disable strict check and add retries

If the consumer cannot connect to the old instance (outdated addresses), that might be as you say. But what puzzles me is that the consumer cannot connect to the new instance either, and the new instance has just started.