对于FailedNotifiedTask类doRetry方法的疑问
- Dominant language
- Java
- Stars
- 41.6k
- Forks
- 26.4k
- Avg merge
- 15h 13m
- Merged PRs (30d)
- 4
Description
- [x] I have searched the [issues](https://github.com/apache/dubbo/issues) of this repository and believe that this is not a duplicate.
- [x] I have checked the [FAQ](https://github.com/apache/dubbo/blob/master/FAQ.md) of this repository and believe that this is not a duplicate.
### Environment
* Dubbo version: 2.7.6
* Operating System version: win10
* Java version: 1.8
### Steps to reproduce this issue
对于FailedNotifiedTask类doRetry方法的疑问
1. 为什么要无差别reput这个任务,使他执行3次(默认重试次数)
2. 为什么调用listener.notify(urls)来进行重试。正常逻辑是调用FailbackRegistry.notify,再调用listener.notify。FailbackRegistry.notify和listener.notify中间相差很多逻辑,为什么在重试任务中直接使用listener.notify而忽略了相差的逻辑
Pls. provide [GitHub address] to reproduce this issue.
### Expected Result
@Override
protected void doRetry(URL url, FailbackRegistry registry, Timeout timeout) {
if (CollectionUtils.isNotEmpty(urls)) {
registry.doNotify(urls);
urls.clear();
}
//reput(timeout, retryPeriod);
}
### Actual Result
@Override
protected void doRetry(URL url, FailbackRegistry registry, Timeout timeout) {
if (CollectionUtils.isNotEmpty(urls)) {
listener.notify(urls);
urls.clear();
}
reput(timeout, retryPeriod);
}
理解不深,烦请解答。
Contributor guide
Research direction
Start by reading FailedNotifiedTask.doRetry and tracing the relationship between listener.notify(urls), FailbackRegistry.notify, and registry.doNotify. Compare the shown expected and actual paths, then establish from the surrounding retry behavior whether repeated reput calls and bypassing the registry are intentional; the issue names no file or test, so completion requires a documented, agreed resolution.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100