akka/akka-core

give users options to control the starting up behavior of the distributed data local replicator

Ouverte

#29 948 ouverte le 13 janv. 2021

Voir sur GitHubGuide contributeur
 (2 commentaires) (0 réaction) (0 personne assignée)Scala (3 547 forks)batch import
1 - triagedhelp wantedt:distributed-data

Métriques du dépôt

Stars
 (13 277 étoiles)
Métriques de merge PR
 (Merge moyen 8j 19h) (10 PRs mergées en 30 j)

Description

Currently, the distributed data local replicator behaves like the following.

  1. the replicator first tries to load everything stored in the local durable storage.
  2. if there is any deserialization failure, the replicator crashes, or keep retrying. the concequence is that the replicator does not participate in the ddata cluster and does not handle any commands.

It would be great if users can specify in the config file which durable keys must be fully loaded during (re)starting. For other keys that are not among these, the replicator should just log an error and ignore the deserialization failure.

one example that can benefit from this is to use ddata as a schema registry. at starting time, only the schema files stored with a schema durable key need to be 100% loaded, the other serializers will rely on the loaded schemas to deserialize data in other durable keys.

Guide contributeur

Direction de recherche
La demande du problème est d'ajouter des options de configuration pour contrôler quelles clés durables doivent être entièrement chargées lors du démarrage. Le comportement existant charge toutes les clés depuis le stockage durable et plante en cas d'échec de désérialisation. La correction implique probablement de modifier la logique de démarrage du réplicateur pour accepter une liste de clés durables requises à partir de la configuration. Les fichiers pertinents peuvent inclure les implémentations du réplicateur dans le module akka distributed data. La discussion (2 commentaires) peut fournir un contexte supplémentaire. Voies d'implémentation potentielles : ajouter une nouvelle propriété de configuration comme 'durable keys must load', gérer le chargement partiel dans le processus de récupération du réplicateur et s'assurer que les erreurs pour les clés non requises sont journalisées mais non fatales.
Stack technique
java
Domaine
backenddatabase
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
3-5 jours
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
Git
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60