when invoker refer check fail, service will be added in cache invokers fail

[jack15083]

What happened: 接到zk新服务上线通知缓存invoker的时候会进行服务的refer检查，如果当时服务有问题，或者还没完全启动，缓存就加不进去 ，就会导致这个provider服务一直发现不了。

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

[wssjdi]

遇到同样问题，请教一下在目前的版本中有什么办法可以解决？

[jack15083]

我这个临时修复测了下应该是有效的你可以尝试下看 https://github.com/apache/dubbo-go/pull/1184

[wenxuwan]

这个issue说的服务没启好，按照我理解，dubbo的服务端应该有机制确保服务已经ready了吧，再看一下dubbo那边的实现，不然注册中心注册上来，服务没启动好，调用的时候肯定会出问题。

[jack15083]

go这边的逻辑我看了，是先启动的端口再向zk注册服务的，java服务照理说应该也是这样的，不过偶尔还是会出现这样的错误猜测可能跟容器化部署有关

[zouyx]

go这边的逻辑我看了，是先启动的端口再向zk注册服务的，java服务照理说应该也是这样的，不过偶尔还是会出现这样的错误猜测可能跟容器化部署有关

我看了下，这个 provider 用的是 dubbo，consumer 是 dubbo-go。

是 dubbo 启动的时候，dubbo-go 的cache 加不进去是吗？

[jack15083]

go这边的逻辑我看了，是先启动的端口再向zk注册服务的，java服务照理说应该也是这样的，不过偶尔还是会出现这样的错误猜测可能跟容器化部署有关

我看了下，这个 provider 用的是 dubbo，consumer 是 dubbo-go。

是 dubbo 启动的时候，dubbo-go 的cache 加不进去是吗？

是的，我这边也是provider dubbo java, consumer dubbo-go

[zouyx]

go这边的逻辑我看了，是先启动的端口再向zk注册服务的，java服务照理说应该也是这样的，不过偶尔还是会出现这样的错误猜测可能跟容器化部署有关

我看了下，这个 provider 用的是 dubbo，consumer 是 dubbo-go。 是 dubbo 启动的时候，dubbo-go 的cache 加不进去是吗？

是的，我这边也是provider dubbo java, consumer dubbo-go

用的是应用级模型还是服务级模型

[jack15083]

go这边的逻辑我看了，是先启动的端口再向zk注册服务的，java服务照理说应该也是这样的，不过偶尔还是会出现这样的错误猜测可能跟容器化部署有关

我看了下，这个 provider 用的是 dubbo，consumer 是 dubbo-go。 是 dubbo 启动的时候，dubbo-go 的cache 加不进去是吗？

是的，我这边也是provider dubbo java, consumer dubbo-go

用的是应用级模型还是服务级模型

应该是服务级的模型吧，注册的服务类似这种 dubbo://10.0.0.118:31232/cn.estudy.course.service.facade.LiveClassBackFacade?anyhost=true&application=estudy&default.delay=-1&default.dubbo.router.group=dev06&default.retries=0&default.service.filter=providerFilter&default.timeout=10000&delay=-1&dispatcher=message&dubbo=2.8.7&generic=false&interface=cn.estudy.course.service.facade.LiveClassBackFacade&methods=initMemberTutorsByCourseIdList,bindClassIdList,lockStock,classTaskSynchronize,checkStockWithCourseId,checkAfterSaleStatus,removeCourseTutors,selectMemberByCourseId,classTaskAssign,specifyTutorsWithMemberIdList,createClassTask,updateClassWechatRemark,addCourseTutors,checkStock,classTaskSelect,updateTutorStatus,updateTutorStock,checkLiveClassTask,lockClassMemberPendingByAfterSale,closeClassTask,specifyTutors,checkTaskStatus,enterPendingClass,unLockStock,unbindClassIdList,synchronizeTutors,unLockClassMemberPendingByAfterSale,batchUpdateTutorStock&pid=1&revision=1.0.0.20210510-box-SNAPSHOT&serialization=hessian2&side=provider&threadpool=fixed&threads=800×tamp=1621589728806 dubbo://10.0.0.119:32504/cn.estudy.course.service.facade.LiveClassBackFacade?

[jack15083]

go这边的逻辑我看了，是先启动的端口再向zk注册服务的，java服务照理说应该也是这样的，不过偶尔还是会出现这样的错误猜测可能跟容器化部署有关

我看了下，这个 provider 用的是 dubbo，consumer 是 dubbo-go。 是 dubbo 启动的时候，dubbo-go 的cache 加不进去是吗？

是的，我这边也是provider dubbo java, consumer dubbo-go

用的是应用级模型还是服务级模型

应该是服务级的模型吧，注册的服务类似这种 dubbo://10.0.0.118:31232/cn.estudy.course.service.facade.LiveClassBackFacade?anyhost=true&application=estudy&default.delay=-1&default.dubbo.router.group=dev06&default.retries=0&default.service.filter=providerFilter&default.timeout=10000&delay=-1&dispatcher=message&dubbo=2.8.7&generic=false&interface=cn.estudy.course.service.facade.LiveClassBackFacade&methods=initMemberTutorsByCourseIdList,bindClassIdList,lockStock,classTaskSynchronize,checkStockWithCourseId,checkAfterSaleStatus,removeCourseTutors,selectMemberByCourseId,classTaskAssign,specifyTutorsWithMemberIdList,createClassTask,updateClassWechatRemark,addCourseTutors,checkStock,classTaskSelect,updateTutorStatus,updateTutorStock,checkLiveClassTask,lockClassMemberPendingByAfterSale,closeClassTask,specifyTutors,checkTaskStatus,enterPendingClass,unLockStock,unbindClassIdList,synchronizeTutors,unLockClassMemberPendingByAfterSale,batchUpdateTutorStock&pid=1&revision=1.0.0.20210510-box-SNAPSHOT&serialization=hessian2&side=provider&threadpool=fixed&threads=800×tamp=1621589728806 dubbo://10.0.0.119:32504/cn.estudy.course.service.facade.LiveClassBackFacade?

[AlexStocks]

there are two changes to do to fix this problem. firstly, treat all zk path child node as add event to listener in ZkEventListener.handleZkNodeEvent and do not filter out them. secondly, the initial ticker interval should be 30s and then we enlarge it if the ticker interval is greater than 15m.