apache/dubbo

[Bug] Registry check does not work in the case of multiple registrations and subscriptions at the application level, and provider export error causes Dubbo to fail to start

Open

#15 003 ouverte le 16 déc. 2024

Voir sur GitHub
 (11 commentaires) (0 réactions) (0 assignés)Java (26 453 forks)batch import
help wantedtype/enhancement

Métriques du dépôt

Stars
 (41 524 stars)
Métriques de merge PR
 (Merge moyen 7j 14h) (20 PRs mergées en 30 j)

Description

Pre-check

  • I am sure that all the content I provide is in English.

Search before asking

  • I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

dubbo3.2.16; jdk openjdk21

Steps to reproduce this issue

Dubbo3.2.16 uses two Nacos clusters as registration centers to implement application level multi subscription and multi subscription, and configure regirty.check=false. When one of the Nacos clusters is unavailable, dubbo serviceConfig. export reports an error causing startup failure, with the error message 'this.registry is null'

What you expected to happen

When a Nacos cluster is unavailable, it should be possible to export services normally on another Nacos cluster and ignore the other Nacos cluster

Anything else

No response

Are you willing to submit a pull request to fix on your own?

  • Yes I am willing to submit a pull request on my own!

Code of Conduct

Guide contributeur

Direction de recherche
Examinez la méthode ServiceConfig.export() dans le code source d'Apache Dubbo, en particulier la logique qui gère plusieurs registres et le drapeau de vérification du registre. Étudiez la classe RegistryProtocol pour comprendre comment les registres sont initialisés et pourquoi 'this.registry' pourrait être null lorsqu'un cluster Nacos est indisponible. Consultez les commentaires de l'issue pour toute indication de code spécifique ou suggestion des mainteneurs.
Stack technique
java
Domaine
backend
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
JavaGit
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
75