Replies: 2 comments 2 replies
-
A quick suggestion: start the console subscriber on a dedicated tokio runtime. This will ensure that it keeps working even when you are blocking a worker. Although this is what spawn does, so maybe that's another issue? |
Beta Was this translation helpful? Give feedback.
1 reply
-
Regarding the original request, tasks aren't bound to a single worker (hence not to a single thread). So any thread id world be more of a "last seen on thread" value. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background:
We are using tokio multithreaded runtime and are presently chasing down a weird issue where our entire app hangs when two identical tasks begin operating concurrently. This has been happening on a VPS with only 2 cores, though it also happens when we bumped it to 4 cores. Other devices are unaffected so far.
So we fired up tokio-console and replicated the hang condition. We were hoping to see both thread_id and task_id, so that we could easily identify which tasks are sharing the same thread. Instead we see only the task IDs.
Proposal:
It is unclear to me if this would be a simple addition, or is complicated to implement due to tracing spans, etc.
Afterword:
It turns out that tokio-console does not update at all after our app hangs. We guess because the tokio-console serving task is running on the same (blocked) thread as the stalled task. So a next test will be to run the app with 100 tokio worker threads to hopefully eliminate that situation.
Beta Was this translation helpful? Give feedback.
All reactions