PaperMC/patches/server/0853-Configurable-chat-thread-limit.patch
Jake Potrebic 90fe0d58a5
Updated Upstream (Bukkit/CraftBukkit/Spigot) (#9825)
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:
897a0a23 SPIGOT-5753: Back PotionType by a minecraft registry
255b2aa1 SPIGOT-7080: Add World#locateNearestBiome
ff984826 Remove javadoc.io doc links

CraftBukkit Changes:
71b0135cc SPIGOT-5753: Back PotionType by a minecraft registry
a6bcb8489 SPIGOT-7080: Add World#locateNearestBiome
ad0e57434 SPIGOT-7502: CraftMetaItem - cannot deserialize BlockStateTag
b3efca57a SPIGOT-6400: Use Mockito instead of InvocationHandler
38c599f9d PR-1272: Only allow one entity in CraftItem instead of two
f065271ac SPIGOT-7498: ChunkSnapshot.getBlockEmittedLight() gets 64 blocks upper in Overworld

Spigot Changes:
e0e223fe Remove javadoc.io doc links
2023-10-22 20:12:00 +01:00

47 lines
3 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 276961a11fc2bd747d2dacdc581cecec498d7593..a6f58b3457b7477015c5c6d969e7d83017dd3fa1 100644
--- a/src/main/java/io/papermc/paper/configuration/GlobalConfiguration.java
+++ b/src/main/java/io/papermc/paper/configuration/GlobalConfiguration.java
@@ -307,7 +307,18 @@ public class GlobalConfiguration extends ConfigurationPart {
@PostProcess
private void postProcess() {
- // TODO: fill in separate patch
+ //noinspection ConstantConditions
+ if (net.minecraft.server.MinecraftServer.getServer() == null) return; // In testing env, this will be null here
+ int _chatExecutorMaxSize = (this.chatExecutorMaxSize <= 0) ? Integer.MAX_VALUE : this.chatExecutorMaxSize; // This is somewhat dumb, but, this is the default, do we cap this?;
+ int _chatExecutorCoreSize = Math.max(this.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;