Replies: 6 comments
-
I've considered storing the thread pools per plugin in the past, but generally have been iffy about it as it creates some concerns over the performance vs just one pool given how infrequently stuff runs; I think an argument could be made for having at least a system property to control that, but, setting a limit on it is a huge "piss in the wind" type thing towards tryna determine a suitable number which I'm not sure we wanna deal with |
Beta Was this translation helpful? Give feedback.
-
I had to increase the pid_limit in the ptero panel to stop this error, it was crashing my server. |
Beta Was this translation helpful? Give feedback.
-
A proper approach might be allowing the user to choose the maximum amount of threads of that pool, and keeping it in a default value as well, so users with more knowledge would know what that means and change if necessary. SrMonsterYT, alongside this being an uncontrollable situation atm, your issue isn't the paper software, you should look into the software you're putting in your server because for this to have happened, the plugin you're using is clearly abusing the async scheduler EDIT: It is also stupid to allow the user to do that, since the proper solution would be for devs to not spam the scheduler for it to just get thrown in an out of resources. |
Beta Was this translation helpful? Give feedback.
-
As someone who's had to deal with that error quite a lot, it'd even just be nice if it said the plugin that is triggering the limit, or had some kind of debug to show what plugins are causing what |
Beta Was this translation helpful? Give feedback.
-
Only debug which would make much sense here in terms of providing something actually useful would probably to have per plugin counters for what's currently executing in the pool, otherwise especially as with most cases of this, it's plugins which slowly tilt over the top, and false attribution here would just create its own set of headaches |
Beta Was this translation helpful? Give feedback.
-
I came across this error when I scheduled a boatload of tasks using runTaskAsynchronously: one to back up each region file. The best solution to just give plugin developers the freedom to do this is to use coroutines/fibers/a partial implementation of the same concept, for these tasks, instead of using a different Thread for each somewhat blocking task. But that feels like simply too much human effort for this particular aspect right now. Per-plugin thread pool and environment variable would be great now. |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem?
The BukkitScheduler's async thread pool doesn't have a maximum thread limit which can easily lead to
java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
if a plugin/multiple plugins run(s)runTaskAsynchronously
for hundreds/thousands (depending on os thread limit) of tasks without considering/knowing about there being no limit on threads being used concurrently.Describe the solution you'd like.
Limit the maximum amount of concurrent threads created by the BukkitScheduler. The limit also should not be too low since there might be tasks that are long lived.
Additionally it might be worth considering if the amount of concurrent tasks should be limited per plugin to avoid a single plugin holding up the tasks of all plugins.
Describe alternatives you've considered.
Plugins may make their own thread pool with a maximum thread limit, but plugin developers might not know that using the Scheduler to run thousands of tasks might cause the above error to occur.
A log message would help plugin developers and server administrators find and fix the issue, right now you need to get a thread dump to figure out what plugin(s) is/are using a lot of threads or test removing plugins to find which one is causing the issue (if it can be consistently reproduced).
Other
No response
Beta Was this translation helpful? Give feedback.
All reactions