OkHttp gRPC sender retries are rejected by a bounded executor
维护者通常 2 天内回复
评估
调研方向
Start with OkHttpGrpcSender.sendAttempt() and the retry path described in the issue; compare how OkHttpHttpSender and JdkHttpSender handle retries. Reproduce with the bounded executor and a closed localhost port. Done when an enabled retry reaches the network after backoff and the export reports the expected ConnectException.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
Since #8854, OkHttpGrpcSender starts each retry by calling Call.enqueue() from inside the OkHttp callback of the failed attempt. That dispatcher thread is still busy, so with a bounded executor every retry is rejected and the export fails with InterruptedIOException: executor rejected instead of being retried.
Steps to reproduce
- Build an OTLP gRPC exporter with retry enabled (the default) and
setExecutorService(new ThreadPoolExecutor(1, 1, 0, TimeUnit.SECONDS, new SynchronousQueue<>())). - Point it at a closed localhost port.
- Export once.
What did you expect to see?
A retry after backoff, then the ConnectException. Before #8854, RetryInterceptor retried on the same thread, as OkHttpHttpSender and JdkHttpSender still do.
What did you see instead?
The retry fails with java.io.InterruptedIOException: executor rejected in OkHttpGrpcSender.sendAttempt() → enqueue() and never reaches the network.
What version and what artifacts are you using?
Artifacts: opentelemetry-exporter-otlp, opentelemetry-exporter-sender-okhttp
Version: 1.67.0 / main @ b32298a83
How did you reference these artifacts? Gradle
Environment
Compiler: Temurin 21
OS: N/A
Additional context
I have a small fix that runs retries synchronously on the current thread. Happy to adjust if maintainers prefer a different execution model (e.g. a JdkHttpSender-style loop).
- 主要语言
- Java
- 星标
- 2.5k
- 派生
- 1k
- 平均合并
- 3 天 15 小时
- 30 天内合并 PR
- 65
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
open-telemetry/opentelemetry-java 的其他 Issue
-
OkHttpGrpcSender no longer logs retry attempts可能已有人在做 @thswlsqls 于 4 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
open-telemetry/opentelemetry-java#8966 · 1 个 reaction ·
维护者通常 2 天内回复
-
JdkHttpSender passes CompletionException instead of the original exception to onError可能已有人在做 @thswlsqls 于 5 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
open-telemetry/opentelemetry-java#8961 · 1 个 reaction ·
维护者通常 2 天内回复
-
Fix `otel.sdk.log.created` counting semantics可能已有人在做 @anuraaga 于 78 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
open-telemetry/opentelemetry-java#8688 ·
维护者通常 2 天内回复
-
Feature Request
难度 5/5 一周以上 新手友好度 44/100
open-telemetry/opentelemetry-java#8976 · 2 条评论 ·
维护者通常 2 天内回复
-
Workflow failed: Build (daily) (#323)可能已有人在做 @breedx-splk 于 1 天前认领。 未关闭
难度 1/5 1 小时以内 新手友好度 25/100
open-telemetry/opentelemetry-java#8972 · 3 条评论 ·
维护者通常 2 天内回复
查看 open-telemetry/opentelemetry-java 的全部 Issue
相似的 Issue
-
[Bug] DefaultSerializationExceptionWrapper does not implement Cleanable, so cleanup() is never invoked by codecs可能已有人在做 @binbin0325 今天认领。 未关闭component/need-triage type/need-triage
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
2026 Error Report
难度 2/5 1-3 小时 新手友好度 68/100
triplea-game/triplea#15096 ·
维护者通常 1 天内回复
-
[Bug][API] Switching workflow versions leaves schedules online可能已有人在做 @zhuangchong 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
apache/dolphinscheduler#18731 ·
维护者通常 1 天内回复
-
Implement JDBC Domain Enums (`SqlCategory`, `SqlExecutionStatus`, `SqlExecutionType`) in Core Module未关闭core-module enhancement good first issue
难度 1/5 1-3 小时 新手友好度 87/100
sdlc-pro/spring-lens#531 ·
维护者通常 1 天内回复