Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Allow custom executor/thread pool for async HTTP calls in CompletionServiceAsyncImpl

オープン
#754 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
65/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
kotlin
領域
api, backend

調査の方向性

まず openai-java-core/src/main/kotlin/com/openai/services/async/CompletionServiceAsyncImpl.kt の参照されている executor の使用箇所から始め、次に OpenAIClient.builder() をたどって、クライアント設定がどこで組み立てられているかを確認します。設定済みの executor が非同期サービスにどのように渡されるべきかを判断し、非同期 HTTP 呼び出しが ForkJoinPool.commonPool() ではなくそれを使用していることを検証します。

索引モデルが issue の本文から書いたものです。

説明

Description

CompletionServiceAsyncImpl currently uses the JVM ForkJoinPool.commonPool() to invoke async HTTP calls:

https://github.com/openai/openai-java/blob/main/openai-java-core/src/main/kotlin/com/openai/services/async/CompletionServiceAsyncImpl.kt#L143

In enterprise environments, relying on the global common pool can break tracing, observability, and context propagation flows. Many applications use custom executors/thread pools to preserve tracing context, MDC/logging context, OpenTelemetry context, or other request-scoped metadata across async boundaries.

Because the common pool is not customizable, users cannot currently integrate the OpenAI Java client cleanly with their existing execution and observability infrastructure.

Problem

There is currently no supported way to override the thread pool used by CompletionServiceAsyncImpl.

The only workaround is to copy the generated/service implementation class and modify the executor usage manually, which is fragile and difficult to maintain across library upgrades.

Proposed Solution

Provide an option to configure the executor/thread pool when building the client.

For example:

val client = OpenAIClient.builder()
.apiKey(apiKey)
.executor(customExecutor)
.build()

or, if scoped specifically to async execution:

val client = OpenAIClient.builder()
.apiKey(apiKey)
.asyncExecutor(customExecutor)
.build()

The async service implementation could then use the configured executor instead of ForkJoinPool.commonPool().

Expected Behavior

Users should be able to supply a custom executor so async HTTP calls run on infrastructure-controlled threads, allowing tracing, observability, and context propagation to work correctly.

Current Workaround

The current workaround is to copy CompletionServiceAsyncImpl and modify the implementation to use a custom executor, but this is not ideal because it forks library internals and creates maintenance risk.

Additional Context

This is especially important in enterprise scenarios where applications require strict control over execution context, thread naming, tracing propagation, and monitoring behavior.

主要言語
Kotlin
スター
1.5k
フォーク
266
平均マージ
9時間 50分
マージ済み PR(30日)
146

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

openai/openai-java のほかの issue

openai/openai-java の issue をすべて見る

似ている issue

Kotlin の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。