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

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

Aperta
  • Qualcosa non va?
#4,166 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@slfan1989 ci sta già lavorando.

Dal 19/7/2026.

  • #4167 di @slfan1989 — chiusa senza merge
  • #4276 di @slfan1989 — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
data-engineering, databases

Direzione di ricerca

Parti da SortedPosDeleteWriter e dal TODO relativo alla sua condizione di flush basata sul numero di record; segui i suoi costruttori e la gestione delle proprietà della tabella. Definisci HeapUsageProvider e una policy basata sull’heap insieme alla soglia di record esistente, quindi verifica con i test che siano coperti i controlli sul numero minimo di record e su un rapporto non valido, la compatibilità dei costruttori e il monitoraggio senza GC forzato.

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

Descrizione

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
Lingua principale
Java
Stelle
1.2k
Fork
398
Merge medio
1g 14h
PR unite (30g)
19

Preparare l'ambiente

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

Tutte le issue di apache/amoro

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.