mirror of
https://github.com/PaperMC/Paper.git
synced 2024-12-11 09:23:42 +01:00
275173e538
Upstream has released updates that appear to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 0c5d8709 SPIGOT-7400: Downgrade maven-resolver due to issues resolving certain depends 255c4fdb SPIGOT-7380: Add PlayerInteractEvent#getClickedPosition and ChiseledBookshelf#getSlot CraftBukkit Changes: b6b514b7e SPIGOT-7400: Downgrade maven-resolver due to issues resolving certain depends fcff84de9 SPIGOT-7399: Revert null check in CraftMetaItem#safelyAdd 44a4b5649 SPIGOT-7380: Add PlayerInteractEvent#getClickedPosition and ChiseledBookshelf#getSlot 676969d01 SPIGOT-7389: Handle setting null items in ChiseledBookshelf Inventory
55 lines
3.2 KiB
Diff
55 lines
3.2 KiB
Diff
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
|
|
From: Shane Freeder <theboyetronic@gmail.com>
|
|
Date: Sun, 18 Sep 2022 06:33:17 +0100
|
|
Subject: [PATCH] Configurable chat thread limit
|
|
|
|
By default, spigot shifts chat over to an unbounded thread pool,
|
|
on a normal server, this really offers no gains, the creation of a thread
|
|
on submitting to the pool on these servers eats more time vs just running it in
|
|
the netty pipeline, however, on servers using plugins which do work in here, there
|
|
could be some overall benefits to moving this stuff outside of the pipeline.
|
|
|
|
In general, this patch does two things:
|
|
1) Exposes the core size for the pool, this allows for ensuring that a number of threads
|
|
sit around in the pool, mitigating the need for creating new threads; This IS however
|
|
caveated, the ThreadPoolExecutor will ONLY create core threads as they're needed, it
|
|
just won't allow for us to dip back under the # of core threads, this can potentially
|
|
be mitigated by calling prestartCoreThread, however, I'm not sure if there is much justification
|
|
for this
|
|
2) Exposes a max size for the pool, as stated, by default this is unbounded, for most
|
|
servers limiting the size of the pool is going to have 0 effects given how fast chat
|
|
is actually processed, this is honestly really just exposed for the misnomers or people
|
|
who just wanna ensure that this won't grow over a specific size if chat gets stupidly active
|
|
|
|
diff --git a/src/main/java/io/papermc/paper/configuration/GlobalConfiguration.java b/src/main/java/io/papermc/paper/configuration/GlobalConfiguration.java
|
|
index eb12227b009b1fb766a5f9e338e5d2394d498376..ffbab76e55807f04ebb25242eadbea114004b1b3 100644
|
|
--- a/src/main/java/io/papermc/paper/configuration/GlobalConfiguration.java
|
|
+++ b/src/main/java/io/papermc/paper/configuration/GlobalConfiguration.java
|
|
@@ -238,13 +238,26 @@ public class GlobalConfiguration extends ConfigurationPart {
|
|
public Misc misc;
|
|
|
|
public class Misc extends ConfigurationPart {
|
|
+
|
|
+ public ChatThreads chatThreads;
|
|
public class ChatThreads extends ConfigurationPart.Post {
|
|
private int chatExecutorCoreSize = -1;
|
|
private int chatExecutorMaxSize = -1;
|
|
|
|
@Override
|
|
public void postProcess() {
|
|
- // TODO: FILL
|
|
+ //noinspection ConstantConditions
|
|
+ if (net.minecraft.server.MinecraftServer.getServer() == null) return; // In testing env, this will be null here
|
|
+ int _chatExecutorMaxSize = (chatExecutorMaxSize <= 0) ? Integer.MAX_VALUE : chatExecutorMaxSize; // This is somewhat dumb, but, this is the default, do we cap this?;
|
|
+ int _chatExecutorCoreSize = Math.max(chatExecutorCoreSize, 0);
|
|
+
|
|
+ if (_chatExecutorMaxSize < _chatExecutorCoreSize) {
|
|
+ _chatExecutorMaxSize = _chatExecutorCoreSize;
|
|
+ }
|
|
+
|
|
+ java.util.concurrent.ThreadPoolExecutor executor = (java.util.concurrent.ThreadPoolExecutor) net.minecraft.server.MinecraftServer.getServer().chatExecutor;
|
|
+ executor.setCorePoolSize(_chatExecutorCoreSize);
|
|
+ executor.setMaximumPoolSize(_chatExecutorMaxSize);
|
|
}
|
|
}
|
|
public int maxJoinsPerTick = 5;
|