Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

CuratorCache initialization overhead with many empty ZNodes

Abierto
  • ¿Algo no está bien?
#1,289 2 comentarios 0 reacciones 0 asignados Ver en GitHub

@2748109647 ya está trabajando en esto.

Desde el 20/10/2026.

  • #1313 de @2748109647 — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
java
Área
databases, distributed-systems

Línea de trabajo

Empieza trazando el flujo de inicialización de CuratorCache descrito en el issue, centrándote en dónde se usan las llamadas a Stat y getChildren. Compara el atajo propuesto para directorios vacíos con el comportamiento persistente del watcher recursivo y la semántica prevista de completitud de la inicialización; se considera terminado cuando exista una dirección de implementación acordada o un motivo documentado para mantener el comportamiento actual.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Java
Estrellas
3.2k
Forks
1.2k
Merge medio
14 h 48 min
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/curator

Todos los issues de apache/curator

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.