Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

CuratorCache initialization overhead with many empty ZNodes

Aperta
  • Qualcosa non va?
#1,289 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@2748109647 ci sta già lavorando.

Dal 20/10/2026.

  • #1313 di @2748109647 — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
java
Ambito
databases, distributed-systems

Direzione di ricerca

Inizia ricostruendo il flusso di inizializzazione di CuratorCache descritto nell’issue, concentrandoti sui punti in cui vengono usate le chiamate a Stat e getChildren. Confronta la scorciatoia proposta per le directory vuote con il comportamento persistente del watcher ricorsivo e con la semantica prevista di completezza dell’inizializzazione; il lavoro è completato quando esiste una direzione di implementazione concordata o un motivo documentato per mantenere il comportamento attuale.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Hi Curator team,

We are using:

  • Curator version: 5.6.0
  • ZooKeeper version: 3.8.4

In one of our environment we do observe roughly ~50k znodes, where about ~45k of them are empty directories. And this numbers are huge in higher envs.

During CuratorCache initialization we observe that getChildren calls are issued across the tree, including for these empty directories. Since getChildren is relatively latency-heavy, this significantly increases cache initialization time at this scale.

In our use case, strict initial enumeration completeness is not required, because we rely on persistent recursive watchers and eventually receive create events for newly added nodes. Our internal cache can converge to the correct state through those events.

While reviewing the initialization flow, we noticed that Stat is already retrieved for nodes. Since Stat contains numChildren, we were wondering whether it would be reasonable to optimize the initialization logic as follows:

if (stat.getNumChildren() == 0) skip getChildren()

This would avoid issuing getChildren() calls for nodes that are already known to have no children, which could significantly reduce initialization overhead in environments with a large number of empty directories.

Our assumption is that correctness would still be preserved because:

  • persistent recursive watchers would capture future child creation events
  • the cache would eventually converge to the correct state

Conceptually the idea is to reduce initialization overhead for environments with a large number of empty directories, while still allowing the cache to converge to the correct state through watcher events.

Would this optimization be compatible with the intended semantics of CuratorCache initialization, or is there a reason getChildren() must always be executed even when stat.getNumChildren() == 0?
Or is there a recommended way to optimize initialization behavior for this type of large namespace with many empty nodes?

Thanks in advance for any guidance.

Best regards,
Viswanathan

Lingua principale
Java
Stelle
3.2k
Fork
1.2k
Merge medio
14h 48m
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/curator

Tutte le issue di apache/curator

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.