sandynz opened a new issue, #2535:
URL: https://github.com/apache/shardingsphere-elasticjob/issues/2535
## Bug Report
### Expected behavior
After a cached etcd key is updated or deleted, `EtcdRegistryCenter.get()`
should eventually return the current
value or `null`.
### Actual behavior
`addCacheData()` copies the current prefix into a local map, but later
writes, deletes, and watch callbacks do
not update that map. A cached key can therefore remain stale indefinitely.
Observed on `0694c8f6b376b166324992be5431f6d4be131c66`:
```text
AFTER_UPDATE cached=value-0 direct=value-1
AFTER_REMOVE cached=value-0 direct=null existed=false
RESULT updateCacheStale=true removeCacheGhost=true
```
### Reproduction
```java
center.persist("/job/config", "value-0");
center.addCacheData("/job");
center.update("/job/config", "value-1");
assertEquals("value-0", center.get("/job/config"));
assertEquals("value-1", center.getDirectly("/job/config"));
center.remove("/job/config");
assertEquals("value-0", center.get("/job/config"));
assertNull(center.getDirectly("/job/config"));
assertFalse(center.isExisted("/job/config"));
```
### Environment
- ElasticJob: `3.0.6-SNAPSHOT`
- Commit: `0694c8f6b376b166324992be5431f6d4be131c66`
- etcd server: `3.5.21`
- JDK: `21.0.10`
### Root cause
`EtcdRegistryCenter.addCacheData()` populates `Map<String, ByteSequence>
cache`. `get()` returns a map entry
without contacting etcd. However, `persist()`, `update()`, `remove()`, and
`EtcdWatchListener` never mutate the
map. It is only cleared by `evictCacheData()` or `close()`.
Unlike a normal asynchronous propagation delay, the stale entry has no
convergence path.
### Proposed change
Define and implement a coherent etcd cache lifecycle for put, update,
delete, watch, evict, and reconnect.
Add provider-level tests proving that cached reads converge after updates
and stop returning deleted keys.
Please also verify transaction operations because they delegate to the same
write and delete methods.
### Scope boundary
This issue concerns the etcd provider cache itself. Lifecycle APIs may
independently choose authoritative reads,
but caller-side direct reads should not be the only workaround for a
provider cache that never converges.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
[email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
