[BUG] Questions about Dubbo Adaptive Load Balance

[bigprincipalkk]

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 feature requirement.

Apache Dubbo Component

Java SDK (apache/dubbo)

Descriptions

Subject: Very Confused About org.apache.dubbo.rpc.AdaptiveMetrics#getLoad, Delay Penalty, and Decay Design
主题：非常疑惑org.apache.dubbo.rpc.AdaptiveMetrics#getLoad，延迟惩罚和衰减的设计

Question:

1. As long as the server responds normally, the currentProviderTime and currentTime will be updated to serviceTime. Then there will be a call to trigger getLoad. As long as there is no clock back, the branch if (metrics. currentProviderTime==metrics. currentTime) will be reached. Then it will be satisfied. The lastLatency will be set to timeout * 2L. Is this branch a maximum probability? So the actual RT will be overwritten, so is the design here reasonable?
2. As long as getLoad is called once, metrics. CurrentProvider Time==metrics. CurrentTime will not be satisfied, so what is the design purpose of this branch?
3. metrics. lastLatency = metrics. lastLatency >> multiple; Does the decay rate occur too quickly?

中文：
1.只要服务端正常响应时，那么currentProviderTime和currentTime就被更新成serviceTime，那么紧接着有一次调用，触发getLoad，只要不发生时钟倒退一定会走到if (metrics.currentProviderTime == metrics.currentTime) 这个分支，那么也一定会满足，就会将lastLatency 置为 timeout * 2L，这个分支是极大概率的吧？那么实际的rt就会被覆盖掉，所以这里设计的是合理吗？
2. 只要调用一次getLoad，那么metrics.currentProviderTime == metrics.currentTime就不会满足，所以这个分支的设计目的是什么？
3.metrics.lastLatency = metrics.lastLatency >> multiple衰减程度是否过快

I hope the experts can help clarify my doubts. clasped fist salute

Related issues

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

[nithin-cherry]

Hello ,
i am a new contributor practicing for GSoC 2026.
I'd like to work on this.

any suggestions or requirements ?

[bigprincipalkk]

@nithin-cherry
Thank you for your response. Let me first summarize my current understanding of the code.

The real latency is only updated once—when the client receives the server’s response—by refreshing the EWMA latency. Later, when an actual call is made, the current delay is predicted by either deferring or applying a penalty, and then smoothed via EWMA. This strikes me as incomplete for two reasons:

1 After every successful metric update, a penalty logic is triggered that predicts the current latency as 2 × timeout. When timeout is either too small or too large, it dilutes the influence of the true latency. Could we adjust this so that if the elapsed time since the last update is less than timeout we simply use the EWMA latency, otherwise we let the predicted latency grow linearly up to 2 × timeout (with that value as the hard cap)?
2 The present EWMA strategy uses a count-based decay with a fixed β = 0.5. A time-based decay—i.e., w_pre = exp(–timeDelta / τ)—would work well for both high-QPS and low-QPS scenarios. Under the current approach, when QPS is very low the EWMA latency still reflects delays measured long ago, which is usually undesirable.

These are my questions; I may simply lack deeper insight and would appreciate your guidance.

[SURYAS1306]

Hi, I’m also interested in working on this issue.
I’m currently going through the AdaptiveMetrics and AdaptiveLoadBalance code and trying to reproduce and understand the behavior.
I’ll share my findings and, if possible, a proposal or PR soon.
Please let me know if anyone is already actively implementing a fix.

[SURYAS1306]

Hi all, I’ve submitted a PR that addresses this issue and adds a unit test to cover the decay scenario:
#16048