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 3.2.10, OpenJDK 8, CentOS 7

Steps to reproduce this issue

Start both the provider and consumer, and the consumer reconnects every 3 minutes, showing the log below:

2025-01-09 09:43:36.006  INFO 25751 --- [lientWorker-4-8] o.a.d.r.t.netty4.NettyClientHandler      :  [DUBBO] The connection of /172.17.0.1:38728 -> /172.17.0.1:20882 is established., dubbo version: 3.2.10, current host: 172.17.0.1
2025-01-09 09:43:36.006  INFO 25751 --- [onnect-thread-1] o.a.d.r.transport.netty4.NettyClient     :  [DUBBO] Close old netty channel [id: 0xa60411cd, L:/172.17.0.1:37798 ! R:/172.17.0.1:20882] on create new netty channel [id: 0x7518bc1f, L:/172.17.0.1:38728 - R:/172.17.0.1:20882], dubbo version: 3.2.10, current host: 172.17.0.1
2025-01-09 09:43:36.006  INFO 25751 --- [onnect-thread-1] o.a.d.remoting.transport.AbstractClient  :  [DUBBO] Successfully connect to server /172.17.0.1:20882 from NettyClient 172.17.0.1 using dubbo version 3.2.10, channel is NettyChannel [channel=[id: 0x7518bc1f, L:/172.17.0.1:38728 - R:/172.17.0.1:20882]], dubbo version: 3.2.10, current host: 172.17.0.1
2025-01-09 09:46:36.082  INFO 25751 --- [lientWorker-4-8] o.a.d.r.t.netty4.NettyClientHandler      :  [DUBBO] The connection of /172.17.0.1:38728 -> /172.17.0.1:20882 is disconnected., dubbo version: 3.2.10, current host: 172.17.0.1

Besides, method calls to provider might fail when the connection is disconnected but not yet established due to 'No provider'.

What you expected to happen

The connection stays connected.

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: AlbumenJ

This may caused by heartbeat failure. Please check your network configuration.

Comment From: KeroZhai

This may caused by heartbeat failure. Please check your network configuration.

Yes, it is the heartbeat check failure, and not about the network but serialization. I have a serialization extension for the provider, which mainly provides a custom JavaDeserializer for Spring's Order. The api calls work fine, but it seems not for the heartbeat check.

Comment From: AlbumenJ

Can you please provide a demo?