Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#17,016 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@QiuYucheng2003 y travaille déjà.

Depuis le 13/1/2026.

  • #17019 par @QiuYucheng2003 — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
54/100
Type d'issue
Refactorisation
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
java
Domaine
backend

Piste de recherche

Ouvrez example/session/src/main/java/org/apache/iotdb/SessionPoolExample.java et examinez l’initialisation de ExecutorService autour de la ligne 74. Confirmez le fonctionnement des files d’attente du pool de threads fixe actuel, puis vérifiez que l’exemple utilise une capacité bornée et fournit une rétropression sans s’appuyer sur une file d’attente non bornée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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!
Langage dominant
Java
Étoiles
6.4k
Forks
1.2k
Merge moyen
1 j 18 h
PR mergées (30 j)
145

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/iotdb

Toutes les issues de apache/iotdb

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.