-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ThreadError: can't move to the enclosed thread group #576
Comments
Hi, thanks for the report. Can you reproduce that reliably? I have an idea for the fix but it would be really nice to confirm it to be 100% sure. |
Alright, that happens as part of my test suite when running on Jenkins. It fails there 100% of the time, so I’m happy to test out some code you have to see if that works. Unfortunately the error is embedded a few files deep, so let me see if I can extract the key components into a smaller script that also fails reliably. |
Spent some time trying to extract a smaller test script, but wasn't able to. The issue is still happening 100% of the time, so I'll be able to test any code you have against my codebase. |
Thanks a lot! It's really helpful that you can repro that in 100% of cases. I will publish my guess as a PR and we will test it against your app. |
Fixes #576 (ThreadError: can't move to the enclosed thread group) When we `Airbrake.notify` inside a `fork` block, `ThreadPool` tries to respawn workers (which were killed by the `fork`) to the same `ThreadGroup`, which was created in the parent thread. The problem is that that `ThreadGroup` is already finalised in that parent thread and no new threads can be added anymore. The fix is to create a new `ThreadGroup` on `fork`. This way every process will have its own `ThreadGroup`.
Fixes #576 (ThreadError: can't move to the enclosed thread group) When we `Airbrake.notify` inside a `fork` block, `ThreadPool` tries to respawn workers (which were killed by the `fork`) to the same `ThreadGroup`, which was created in the parent thread. The problem is that that `ThreadGroup` is already finalised in that parent thread and no new threads can be added anymore. The fix is to create a new `ThreadGroup` on `fork`. This way every process will have its own `ThreadGroup`.
Fixes #576 (ThreadError: can't move to the enclosed thread group) When we `Airbrake.notify` inside a `fork` block, `ThreadPool` tries to respawn workers (which were killed by the `fork`) to the same `ThreadGroup`, which was created in the parent process. The problem is that that `ThreadGroup` is already finalised in that parent process and no new threads can be added anymore to the group. The fix is to create a new `ThreadGroup` on `fork`. This way every process will have its own `ThreadGroup`.
Fixes #576 (ThreadError: can't move to the enclosed thread group) When we `Airbrake.notify` inside a `fork` block, `ThreadPool` tries to respawn workers (which were killed by the `fork`) to the same `ThreadGroup`, which was created in the parent process. The problem is that that `ThreadGroup` is already finalised in that parent process and no new threads can be added anymore to the group. The fix is to create a new `ThreadGroup` on `fork`. This way every process will have its own `ThreadGroup`.
I managed to find a repro case and came up with #577 Can you please give it a try? |
Just ran my test using the new branch three times (to be sure). No ThreadError errors! That's a big thumbs up from me! |
Awesome, thanks a lot! |
I released this fix in v4.14.1. |
Hello. I've got an error when calling
Airbrake.notify
within a fork.I notice a similar discussion in #312, but the
@mutex.synchronize
block indef has_workers?
doesn't seem to be working for me.Any ideas on how to fix this?
The text was updated successfully, but these errors were encountered: