Logging messages can block
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- ruby
- Domain
- observability-sre
Research direction
Start by locating the TCPSocket write path and reading how the single connection is shared across threads. Reproduce or test behavior when the kernel buffer fills, then verify that the selected handling prevents logger calls from blocking while preserving expected message behavior. The issue names no file or test, so repository-wide search is needed.
Written by the indexing model from the issue text.
Description
This gem can block execution, effectively allowing a website to be DOS'd, if too many messages are sent at the same time. The TCPSocket is set to be synchronous, so the only buffering of messages is done in the kernel. But writes to the socket use write instead of write_nonblock, so if the kernel buffer fills up the write will block and the ruby thread being executed will just need to wait until data is cleared from the kernel buffer.
Compounding the issue, there is only one TCPSocket connection for all threads of a process. If a web app uses puma or some other kind of threaded model, then as soon as the kernel buffer fills up all threads will need to wait until buffer room is freed up.
To partially solve this issue, I think the write needs to be turned into a write_nonblock. The gem could then detect overflows and discard messages when that happens. It could also buffer some messages if they overflow, but that would just be a nicety.
To solve the issue further, there probably should be a separate connection per thread. That would allow for better scalability of socket buffering when comparing a single threaded process and a process with lots of threads trying to write messages. But this is also just a nicety on top.
- Dominant language
- Ruby
- Stars
- 256
- Forks
- 77
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from fluent/fluent-logger-ruby
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
fluent/fluent-logger-ruby#111 · 1 comment ·
-
UDP SupportOpen
Difficulty 4/5 3-5 days Newbie friendliness 25/100
fluent/fluent-logger-ruby#88 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
fluent/fluent-logger-ruby#86 · 2 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
fluent/fluent-logger-ruby#66 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
fluent/fluent-logger-ruby#46 · 1 comment · 2 reactions ·
All issues in fluent/fluent-logger-ruby
Similar issues
-
security
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CircuitVerse/CircuitVerse#7967 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
simp/pupmod-simp-stunnel#173 ·
-
Polish QDrantOpen
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
o19s/quepid#1825 · 1 comment ·
Maintainers usually reply within 1 day