-
Notifications
You must be signed in to change notification settings - Fork 54
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
Question on RuntimeError #42
Comments
Hi gdebure, Pebble's pool relies on 3 threads to maintain its internal logic. Every time you interact with the Pool APIs the health of the 3 threads is checked and if one or more are not running, you get the If one of the internal threads crashes, it will print out the stack trace with the actual reason for the crash. I'd suggest you to search within your app logs, you should be able to see the actual reason for the crash. My blind guesses are two: either you run low on memory and one of the threads could not allocate any further memory, or the Pipe used to communicate with the worker processes was closed for some reason. Once you find the traceback of the actual crash, please paste it here so I can provide further hints. |
Closing this ticket due to inactivity, please re-open if you still have issues. |
Hello, I've just faced same issue I don't have any other traceback. Does pebble surpress errors from executing code? |
Hi there,
I've been using pebble for a while, mainly for its timeout capabilities compared to plain concurrent.futures.
Lately I've run into situations where the following runtime error is raised:
I could not find a consistent scenario to trigger it. Sometimes it happens after 1700 jobs have already been scheduled (all of the same type), sometimes everything goes fine even with more than 32000 jobs scheduled.
I'm a bit blind on what could go wrong, I'd appreciate some pointers as to where I should look for... What are the situations that are likely to trigger this ?
Thanks :)
The text was updated successfully, but these errors were encountered: