Logs failing to flush in `Logdna::Client` due to concurrency issue in rails
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
调研方向
从 Logdna::Client#schedule_flush 开始，检查 Rails 启动期间 @scheduled_flush 和 @work_thread_pool 如何使用 Concurrent 的计划任务。使用所述的 Rails 6.1.7.5、Ruby 3.2.2 设置进行复现，包括从 config/application.rb 发起一次日志调用；当配置日志出现时，启动后日志仍继续刷新即表示完成。
由索引模型根据 Issue 内容生成。
描述
Found that any uses of Logdna::Client within the boot sequence of rails results in subsequent logs never flushing.
For background, using logdna 1.5.0 w/ rails 6.1.7.5 on ruby 3.2.2. Configuring Logdna::Ruby following the instructions in TAMING RUBY ON RAILS LOGGING WITH LOGRAGE AND MEZMO in config/application.rb. As long as Rails.logger isn't used within the subsequent application setup steps, then logging works as expected. But if any other subsequent step of the application setup process attempts to log, then all subsequent logs fail to be emitted.
Tracked this down to Logdna::Client#schedule_flush. By adding logging, I found that the associated Concurrent::ScheduledTask in @scheduled_flush remains in the pending state indefinitely. Further logging shows that the ScheduledTask is associated with a Concurrent::CachedThreadPool that contains a single thread and that thread has is marked as dead.
Guessing that as part of the rails boot up process, the default executor is terminated and therefore the @scheduled_flush never completes. Not that using the @work_thread_pool thread pool doesn't fix the issue; the same behavior is observed. By not logging anything during rails configurations/boot, a ScheduledTask isn't created while the application is still booting, and therefore this issue doesn't occur.
I think this issue could be addressed by tracking the time at which @scheduled_flush is created and then in subsequent invocations of schedule_flush checking if it has been pending far longer than expected. If it is sufficiently stale, then the outstanding ScheduledTask would be cancelled and a new one created. There may be more robust/elegant ways to address this because I'm not particularly familiar with ruby/rails thread management.
- 主要语言
- Ruby
- 星标
- 19
- 派生
- 18
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
logdna/ruby 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 52/100
-
难度 2/5 1-3 小时 新手友好度 45/100
-
难度 3/5 1-2 天 新手友好度 35/100
-
难度 3/5 1-2 天 新手友好度 45/100
-
难度 3/5 1-2 天 新手友好度 30/100
相似的 Issue
-
ds-drift
难度 1/5 1 小时以内 新手友好度 76/100
we-promise/sure#4120 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 4 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
scanaislop/aislop#476 ·
维护者通常 1 天内回复
-
Dependencies view: `getParent` loops forever on untitled documents, extension host runs out of memory可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭bug
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
area/web interface
难度 2/5 1-3 小时 新手友好度 62/100
mastodon/mastodon#41000 · 1 个 reaction ·
维护者通常 1 天内回复