[Improvement] Avoid potential OOM in SessionPoolExample by replacing unbounded thread pool
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 54/100
Línea de trabajo
Abre example/session/src/main/java/org/apache/iotdb/SessionPoolExample.java e inspecciona la inicialización de ExecutorService alrededor de la línea 74. Confirma cómo funcionan las colas del grupo fijo de hilos actual y verifica que el ejemplo utiliza una capacidad acotada y proporciona backpressure sin depender de una cola ilimitada.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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!
- Lenguaje dominante
- Java
- Estrellas
- 6.4k
- Forks
- 1.2k
- Merge medio
- 1 d 17 h
- PR fusionados (30 d)
- 152
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/iotdb
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/iotdb#18655 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
IoTDB Edge: stop-edge.sh does not stop its own process when IOTDB_HOME is set, and reports successAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
[Bug] 执行start-all.sh后无法启动集群问题Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
[Bug] findColumn throws NullPointerException instead of SQLException for an unknown column nameAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
Todos los issues de apache/iotdb
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
-
Black theme and viewing mode.Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
oracle/javavscode#652 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
OpenAPITools/openapi-generator#25014 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
AloisSeckar/demos-java#380 ·