akka/akka-core

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

Aperta

#29.948 aperta il 13 gen 2021

Vedi su GitHubGuida contributor
 (2 commenti) (0 reazioni) (0 assegnatari)Scala (3547 fork)batch import
1 - triagedhelp wantedt:distributed-data

Metriche repository

Star
 (13.277 stelle)
Metriche merge PR
 (Merge medio 8g 19h) (10 PR mergiate in 30 g)

Descrizione

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.

Guida contributor

Direzione di ricerca
La richiesta del problema è di aggiungere opzioni di configurazione per controllare quali chiavi durevoli devono essere caricate completamente durante l'avvio. Il comportamento esistente carica tutte le chiavi dallo storage durevole e si arresta in caso di errore di deserializzazione. La correzione probabilmente comporta la modifica della logica di avvio del replicatore per accettare un elenco di chiavi durevoli richieste dalla configurazione. I file rilevanti potrebbero includere le implementazioni del replicatore nel modulo akka distributed data. La discussione (2 commenti) potrebbe fornire ulteriore contesto. Possibili percorsi di implementazione: aggiungere una nuova proprietà di configurazione come 'durable keys must load', gestire il caricamento parziale nel processo di recupero del replicatore e assicurarsi che gli errori per le chiavi non richieste vengano registrati ma non siano fatali.
Tech stack
java
Dominio
backenddatabase
Tipo issue
Funzionalità
DifficoltàQuanto dovrebbe essere impegnativa per un nuovo contributor.
3
Tempo stimatoTempo stimato per completare e verificare uno scope piccolo.
3-5 giorni
Stato attivitàQuanto è probabile che la issue sia ancora attiva e reviewable.
Attiva
ChiarezzaQuanto chiaramente la issue descrive problema, scope e risultato atteso.
Chiara
Prerequisiti
Git
Adatta ai principiantiQuanto la issue è adatta a contributor alla prima esperienza.
60