Stellar1999 commented on issue #15271: URL: https://github.com/apache/dubbo/issues/15271#issuecomment-2964936478
> > > in `AbstractRegistryFactory#getRegistry`, if `NacosConnectionManager#createNamingService` throw Exception `IllegalStateException` and set `registry.check = false`，the variable `registry` will return `null`. maybe it can throw an Exception such as `RegistryCreateFailException` instead of return `null`. > > > in `ServiceConfig#doExportUrl` we can catch the Exception `RegistryCreateFailException` and handler the exception by step: > > > > > > 1. unexport the return `exporter`， > > > 2. record the fail registry > > > > > > in `ServiceConfig#doExportUrls` calculate the failure rate, if the rate out of bounds the service may export fail. we can add config `service.checkThreshold` defaine the failure rate. > > > in `MultipleRegistry` the registry url from qs `reference-registry` and `service-registry`, the register and subscribe use the different connection. in `MultipleServiceDiscovery` the registry url from qs `child.*`. register and subscribe to share these connections. > > > should we define Multiple failure behavior here, such as the failure rate of multiple connections. > > > > > > Good design. However, for this issue, I don’t think we need a counter or similar mechanism to track the failure rate in order to determine success or failure. > > In a multi-registry scenario where check=false, the user has already indicated that the application is intended to support multiple registries. The core of this issue is more about ensuring that when multi-registry is enabled, the application can still operate correctly even if one of the registries becomes unavailable. > > Therefore, rather than introducing failure rate tracking logic, we should focus on improving the application's resilience to partial registry failures, ensuring that service export or reference can still proceed as long as at least one registry is functional. > > That makes sense, when `check = true`, it means the developers don't care about registration status. and the failure rate maybe observed through metrics. > > i have reviewed the ZookeeperRegistry, it's connect、register and subscribe is async. Perhaps i just need to modify the default value of `nacos.check` to `false`. > > but the option combination of `registry.check = false` and `nacos.check = true` still return `null`. should we return a `Registry` like `DEFAULT_NOP_REGISTRY` or asynchronously retry the connection. > > looking forward to your guidance. Yes, the core issue is that returning null here prevents the ServiceDiscoveryRegistry from continuing with subsequent logic. While retrying can help with recovery, the priority here should be ensuring the process can proceed. -- 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: notifications-unsubscr...@dubbo.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For additional commands, e-mail: notifications-h...@dubbo.apache.org
