Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#17,016 3 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
54/100
Tipo de issue
Refatoração
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
java
Domínio
backend

Direção de pesquisa

Abra example/session/src/main/java/org/apache/iotdb/SessionPoolExample.java e inspecione a inicialização de ExecutorService por volta da linha 74. Confirme como funcionam as filas do pool fixo de threads atual e verifique se o exemplo usa capacidade limitada e fornece backpressure sem depender de uma fila ilimitada.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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!
Linguagem predominante
Java
Estrelas
6.4k
Forks
1.2k
Merge médio
1d 17h
PRs com merge (30d)
152

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apache/iotdb

Todas as issues de apache/iotdb

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.