Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Improvement] Avoid potential OOM in SessionPoolExample by replacing unbounded thread pool

Offen
  • Stimmt etwas nicht?
#17,016 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@QiuYucheng2003 arbeitet bereits daran.

Seit 13.1.2026.

  • #17019 von @QiuYucheng2003 — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
54/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
java
Bereich
backend

Rechercherichtung

Öffne example/session/src/main/java/org/apache/iotdb/SessionPoolExample.java und untersuche die Initialisierung von ExecutorService um Zeile 74. Bestätige, wie die Warteschlangen des aktuellen festen Thread-Pools funktionieren, und überprüfe anschließend, dass das Beispiel eine begrenzte Kapazität verwendet und Backpressure bereitstellt, ohne sich auf eine unbegrenzte Warteschlange zu stützen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Search before asking
  • I searched in the issues and found nothing similar.
Version

Master

Describe the bug and provide the minimal reproduce step

Description:
In example/session/src/main/java/org/apache/iotdb/SessionPoolExample.java, the ExecutorService is initialized using Executors.newFixedThreadPool(10) (Line 74).

Problem:
Executors.newFixedThreadPool uses an unbounded LinkedBlockingQueue (capacity: Integer.MAX_VALUE) by default. As this is an official example, users often copy-paste this code for production. In high-throughput write scenarios, if the production rate exceeds the consumption rate, tasks accumulate indefinitely in the queue, leading to OutOfMemoryError: Java heap space.

Code Location:
// org.apache.iotdb.SessionPoolExample.java
service = Executors.newFixedThreadPool(10); // Unbounded Queue risk

What did you expect to see?

Official examples should demonstrate best practices by using bounded queues to ensure system stability. The thread pool should provide backpressure (block or reject) when the queue is full, preventing memory exhaustion.

What did you see instead?

The example uses an unbounded queue pattern (UBSCQ), which creates a hidden memory leak risk for downstream users who adopt this code snippet.

Anything else?

Suggested Fix: Replace the factory method with a custom ThreadPoolExecutor using a bounded queue (e.g., ArrayBlockingQueue).

Proposed Code:
service = new ThreadPoolExecutor(
10, 10, 0L, TimeUnit.MILLISECONDS,
new ArrayBlockingQueue<>(1000) // Bounded capacity
);

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Vorherrschende Sprache
Java
Sterne
6.4k
Forks
1.2k
Ø Merge
1 T. 14 Std.
Gemergte PRs (30 T.)
155

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/iotdb

Alle Issues in apache/iotdb

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.