Describe the bug
A clear and concise description of what the bug is.
nacos server版本: 2.1.0, 3节点部署 + derby
client: go-sdk
如图所示
这里dump配置的时候, 如果有其他请求正在读配置(readLock), 是不是会导致dump失败? dump失败的话就只能等对账任务了, 在此之前, server的md5 cache都是错误的.
Expected behavior
A clear and concise description of what you expected to happen.
获取写锁失败, 等待或者重试
Actually behavior
A clear and concise description of what you actually to happen.
某个nacos server节点获取写锁失败后, md5缓存一直是旧的, 直到几个小时后的全量对账任务触发, 配置才刷新.
正常节点:
01:00:30, 配置更新, 该配置缓存md5刷新为: 8d1943c68eecedc84e431c912fbca0e5
config-pull-check.log.2024-08-20.0
异常节点:
01:00:30 获取写锁失败, md5缓存一直未能刷新, 还是旧的: b7ce55d429195cf56609bd68787ebedf
config-dump.log.2024-08-20.0, 01:00:00
config-pull-check.log.2024-08-20.0, 01:00:00
直到几个小时后(06:19)的全量对账任务启动, md5才刷新
config-dump.log.2024-08-20.0, 06:00:00
config-pull-check.log.2024-08-20.0, 06:00:00
How to Reproduce
Steps to reproduce the behavior:
未能稳定复现
Desktop (please complete the following information):
Additional context
Add any other context about the problem here.
我们的客户端是go-sdk, 与java客户端不同的是, long-pulling和getInnerConfig可能会请求不同的nacos server
2条答案
按热度按时间uplii1fm1#
能否试一下新版本，我看最新版本的逻辑应该有修改过。
drnojrws2#
能否试一下新版本，我看最新版本的逻辑应该有修改过。
不知道我理解的对不对, 新版本的代码似乎还是没有解决这个问题, 更新配置时没有关心dump动作是否成功, 也没有重试机制
写配置:
ConfigDumpEvent事件处理, 忽略了dump动作的返回值, 没有做失败重试
而dump动作中, 还是会出现"只要被上了读锁, dump就会失败"的情况
不同的是新版本增加了一个定时任务DumpChangeConfigWorker, 每30s让dump动作失败有一个兜底, 让不一致的情况会在较短时间内自动修复.
求帮忙看看, 是我理解的有问题, 还是确实存在上述情况, 需要修复?