A chunk load on the main thread will be added to the high priority queue, however, due to existing work on this queue, there was no guarantee that the load would occur within a reasonable amount of time, potentially causing a server to crash while waiting for a chunk in the queue
In order to counteract this, a new urgent priority has been added, allowing us to prioritize these tasks over standard chunk gen/loading
(#1625#1615#1575#1558 (and probably more))
Changes upstream moved this to a profile a while back, however,
when updating (for some unknown reason) I kept it enabled by default,
however, leaving this enabled breaks building the server in newer
versions of java, which while this wasn't a concern before, is now
an issue for users.
fixes an issue in which thread requests are only processed
for the current provider which can cause a deadlock should
multiple requests exist across providers
Upstream has released updates that appears 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:
867794b2 Make setPersistent also control player saving
CraftBukkit Changes:
02518f92 Make setPersistent also control player saving
FileIOThread was using two volatile counters in order to track if
any pending work was in the queue, this causes potential concurrency
issues when this counter is updated from multiple threads, potentially
causing these counters to desync due to the unsafe volatile update
Upstream has released updates that appears 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:
c71bb9ca Add PlayerRecipeDiscoverEvent and methods to (un/)discover recipes
CraftBukkit Changes:
7a2f4867 Implement PlayerRecipeDiscoverEvent and methods to (un/)discover recipes
During testing, I could not find any case of TabCompleteEvent firing,
however, upon reinspection of the code, and additional testing, this
appears to work fine without any changes on our part.
Spigots implementation around the header/footer strips newlines from the
header/footer, this patch allows the tab list header/footer to retain newlines.
Due to the changes in 1.13, clients will send a tab completion request
for all bukkit commands in order to factor in the lack of support for
brigadier and provide backwards support in the API.
Craftbukkit, however; has moved the chat spam limiter to also interact
with the tab completion request, which while good for avoiding abuse,
causes 1.13 clients to easilly be kicked from a server in bukkit due
to this. Removing the spam limit could cause issues for servers, however,
there is no way for servers to manipulate this without blindly cancelling
kick events, which only causes additional complications. This also causes
issues in that the tab spam limit and chat share the same field but different
limits, meaning that a player having typed a long command may be kicked from
the server.
Splitting the field up and making it configurable allows for server owners
to take the burden of this into their own hand without having to rely on
plugins doing unsafe things.
This patch has been applied to 1.12.2 in order to allow people using
plugins which allow clients of newer versions to connect, this is
not a common practice, however is being done as a level of nicety
given the current status of 1.13
While upstream has now made this event cancellable, their changes
result in the vechicle being removed before the event is called,
thus leading cancellation to not behave as expected.
Our changes for the spawn radius have the potential to throw an ArithmeticException
should the server be stopped before we've loaded worlds, we check if the server is
running earlier to check if we should even consider attempting to load chunks, which
would cause us to, 1) not load chunks anyways, as we're disabled; 2) throw an
ArithmeticException due to us expecting that we're going to be loading more than 0 chunks.
This change by spigot ensures that many interactins with chunks,
e.g. getting a list of TEs will cause the chunk to be marked for not
unloading and will block their unload. This is especially true for
servers using Timings (it needs to access the TE list of chunks), or
any plugins which need to access entity/TE lists periodically.
In some enviroments, the channel limit set by spigot can cause issues,
e.g. servers which allow and support the usage of mod packs.
provide an optional flag to disable this check, at your own risk.
add a system property to allow people to tweak how long the server
will wait for a reply. There is a compromise here between lower and higher
values, lower values will mean that dead connections can be closed sooner,
whereas higher values will make this less sensitive to issues such as spikes
from networking or during connections flood of chunk packets on slower clients,
at the cost of dead connections being kept open for longer.
Spigot, by default, disables several mechanisms around how chunks are
lit, if ever, which has forced them to always send chunks before vanilla
would consider them ready to send, causing for lots of issues around
lighting glitches.
Shamefully, the amount of work to relight chunks can be detremental
to some servers, meaning that forcibily disabling light updates can
cause major performance issues.
as such, we make a compromise; if this "feature" is disabled, we will
only send chunks which are actually ready to be sent, otherwise, we
will always send chunks.
In 1.12, Spigot improved their blockstate implementation to take a full
copy of the TE, this allows for a much better snapshot in that it will
actually retain all of the TE's state, it is a much more expensive
implementation. This is also implicated with their backwards compat
for inventories meaning that accessing of a snapshots inventory of a
placed block will actually access the inventory of the live TE, making
creation of a snapshot redundant if the only intent is to interact with
the TEs inventory.
Hoppers are a horrible hit, every attempt to transfer an ItemStack will
result in two TileEntity snapshots, with two hoppers and a double chest
ontop, I managed to log 380 cases per second where a snapshot would have been
taken in cases where the snapshot is redundant.
Shane Freeder