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

[Improvement]: Implement heap-based flush mechanism for SortedPosDeleteWriter to prevent OOM

Abierto
  • ¿Algo no está bien?
#4,166 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@slfan1989 ya está trabajando en esto.

Desde el 19/7/2026.

  • #4167 de @slfan1989 — cerrado sin fusionar
  • #4276 de @slfan1989 — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
data-engineering, databases

Línea de trabajo

Comienza en SortedPosDeleteWriter y en el TODO relacionado con su condición de flush basada en el número de registros; sigue sus constructores y el manejo de las propiedades de la tabla. Define HeapUsageProvider y una política basada en el heap junto con el umbral de registros existente, y luego verifica mediante pruebas que estén cubiertas las comprobaciones del número mínimo de registros y de una proporción no válida, la compatibilidad de los constructores y la monitorización sin GC forzado.

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

Descripción

stale type:improvement
Search before asking
  • I have searched in the issues and found no similar issues.
What would you like to be improved?

Currently, SortedPosDeleteWriter only flushes buffered position deletes based on a record count threshold. There is a TODO comment in the code indicating the need for a heap memory-based flush policy:

// TODO Flush buffer based on the policy that checking whether whole heap memory size exceed the
// threshold.
if (records >= recordsNumThreshold) {
  flushDeletes();
}

Problem: When processing large-scale position deletes, the in-memory buffer in SortedPosDeleteWriter can grow unbounded (if record threshold is set very high or to Long.MAX_VALUE), potentially causing OutOfMemoryError (OOM) issues, especially in memory-constrained environments.

Current behavior:

  • Only flushes when record count reaches recordsNumThreshold
  • No protection against heap memory pressure
  • Can lead to OOM when processing large delete operations
How should we improve?

Implement a heap memory-based flush mechanism with the following features:

1. New table properties:
  • pos-delete.flush.heap.ratio (default: 0.8) - Heap usage ratio threshold to trigger flush
  • pos-delete.flush.records (default: Long.MAX_VALUE) - Record count threshold
  • pos-delete.flush.heap.min-records (default: 1000) - Minimum records before heap-based flush kicks in
2. Implementation details:
  • Add HeapUsageProvider interface to monitor JVM heap usage
  • Implement shouldFlushByHeap() method to check if heap usage exceeds threshold
  • Modify flush logic to: if (records >= recordsNumThreshold || shouldFlushByHeap())
  • Ensure backward compatibility through constructor overloads
3. Safety guards:
  • Prevent frequent small flushes with minimum record count
  • Allow disabling heap-based flush by setting invalid ratio (≤0 or ≥1)
  • Non-intrusive monitoring (no forced GC)
Are you willing to submit PR?
  • Yes I am willing to submit a PR!
Subtasks

No response

Code of Conduct
Lenguaje dominante
Java
Estrellas
1.2k
Forks
398
Merge medio
1 d 14 h
PR fusionados (30 d)
19

Preparar el entorno

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/amoro

Todos los issues de apache/amoro

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.