[Bug] RoundRobinLoadBalance sends disproportionate traffic to newly scaled-up pods during rapid scaling in Dubbo 3.3

[GLGGAG]

Pre-check

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

Search before asking

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

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Dubbo java 3.3.0
OpenJdk 1.8

Steps to reproduce this issue

We encountered an issue with the RoundRobinLoadBalance algorithm in Dubbo 3.3.x.

Every day at around 06:00, our service scales out quickly from ~50 pods to ~200 pods (Kubernetes HPA). During this period, we observed that some newly started pods receive significantly more traffic than the original pods, instead of being gradually warmed up and balanced evenly.

The traffic spike pattern looks like this (per-instance QPS monitoring):
(Monitoring screenshot: newly added pods show much higher QPS than older ones)

What you expected to happen

Expected behavior:

New providers should receive traffic smoothly and proportional to weight/warm‑up rules

The load should not skew heavily to newly added pods immediately after scaling

Actual behavior:

Newly started pods receive higher QPS compared to existing pods for roughly 1–5 minutes after scaling

This causes CPU / thread pool spikes and temporary service instability on those pods

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

• I agree to follow this project's Code of Conduct

[RainYuY]

Can you provide more details about this issue? Maybe weight is a reason.

[GLGGAG]

Our service interface has a warm-up time of 5 minutes, and the weight of all pod nodes is set to the default value of 100.

[RainYuY]

I tried to reproduce this situation, but I can't replicate your issue. Please check these points:

1. Dubbo uses consumer-side load balancing. Have you checked your consumer's subscription status?
2. Could something have changed the URL weight or timestamp parameter?

[GLGGAG]

1.consumer subscription status is normal
2. the URL weight or timestamp parameters haven’t changed after the provider registration. This rules out the two common issues mentioned earlier.

[RainYuY]

1.consumer subscription status is normal 2. the URL weight or timestamp parameters haven’t changed after the provider registration. This rules out the two common issues mentioned earlier.

Sorry, I tried but I can't reproduce this problem. Could you please provide a demo or any other help?

[GLGGAG]

I suspect the issue lies here: every time the weight changes, current is reset to 0. During the 5-minute warm-up period, the provider's weight keeps changing, causing each calculation to be set to 0.

Here is our reasoning process.

[RainYuY]

Thanks for your reply.After I will change my reproduce case. I will think about it and if you have any advice. You can tell me.