[Bug]Service reference fails when using providedBy after listener destruction
- Dominant language
- Java
- Stars
- 41.6k
- Forks
- 26.4k
- Avg merge
- 15h 13m
- Merged PRs (30d)
- 4
Description
### Apache Dubbo Component
Java SDK (apache/dubbo)
### Dubbo Version
3.1.11
### Steps to reproduce this issue
1. Define a service reference with a specific provider:
```java
@DubboReference(providedBy = "app1")
private APIService apiService;
```
2. Zookeeper has data:
`get /dubbo/mapping/com.example.APIService value:app1,app2`
3. The app1 listener gets destroyed.
4. Try to use another service from app1:
```java
@DubboReference(providedBy = "app1")
private API2Service api2Service;
```
Result: No provider found.
### What you expected to happen
The service reference should succeed.
### Anything else
1. Why is the mapping being looked up when the provider is already specified?
2. In the code that handles service instance changes:
```java
if (!oldListener.hasListeners()) {
oldListener.destroy(); // 🪵
removeAppSubscriptionLock(appKey);
}
```
Is it necessary to remove the oldListener from the serviceListeners Map after it has called destroy?
3. Would it be correct to add a line to remove old listeners from serviceListeners, like this:
```java
if (!oldListener.hasListeners()) {
oldListener.destroy();
// Remove old listeners from serviceListeners
serviceListeners.remove(appKey);
removeAppSubscriptionLock(appKey);
}
```
### Are you willing to submit a pull request to fix on your own?
No
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct
---
This consolidated version includes all the key points from your original issue, including the code snippets and your questions about the listener removal process.
Contributor guide
Research direction
Start at the service-instance change handler containing oldListener.destroy(), serviceListeners, and removeAppSubscriptionLock; trace how providedBy references resolve mappings after an app listener is destroyed. Reproduce the two @DubboReference cases and verify that the reference succeeds after listener destruction while listener cleanup remains correct.
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
- Mostly clear
- Newbie friendliness
- 35/100