Recent Netty versions have improved the adaptive allocator, and we shouldn't be seeing the OOM issues others were noticing before. Let's re-enable it.
As for the buffer resizing issue, the upstream issue netty/netty#14912 is long fixed. I think we *should* pre-allocate the buffers beforehand much more aggressively, but that has to be future work.
No need to bounce around changing the writer index, we can just set the value directly.
Also pull out the handshake checks into a separate function, to improve inlining.
This technically can break backwards compatibility, but this seems to be very unlikely to be the practice in reality. (The Velocity implementation probably wasn't correct, anyway.)
This required a not-insubstantial number of bug fixes, since the sync support had bit-rotted somewhat. This PR also corrects a number of bugs.
Finally. the per-plugin executor services are now used to execute all async event tasks.
This was unused and did little more than add unnecessary memory usage. The only time we need the dimension registry is during server switching - once that is done, we no longer need the registry.
This is an optimization that has been in BungeeCord for some time, but it's an idea that makes a lot of sense: avoid a memory copy when we don't need to do one. The OS will hopefully be smart enough to use `writev()` or similar for this.
This time around, instead of the very ad hoc approach I have historically taken, this time we actually have a convenient script that takes care of basically all the hard work necessary, including cross-compilation.
We compile natives for Ubuntu 20.04 LTS (OpenSSL 1.1.x native and libdeflate) and Ubuntu 22.04 LTS (OpenSSL 3.x.x native), for both x86_64 and aarch64.
The macOS natives have also been recompiled on macOS Sonoma.
In this case, we don't even need a concurrency-friendly MPSC queue, since this code only ever gets run in the event loop associated to the channel, so a simple `ArrayDeque` is enough for our needs.
Fixes#1047. We can't go any higher since that's an API-breaking change. In any event, this will likely disappear in 5.0.0 anyway, because Configurate 4.x now shades SnakeYAML internally.
We don't need to track this information since Velocity uses the JoinGame packet, which is about as good of a server rejoin mechanism we're likely to get in vanilla Minecraft.
This is part of preparatory work for Velocity 5.0.0's revamped event system, but this change is safe to bring into the 3.x.x series. This affects the scheduler for now, but command execution will also be moved into the per-plugin thread pool, along with invocations of `EventTask.async()`.
This is a more realistic (generalized) solution for #943. Fundamentally, a plugin should not be spawning an unbounded number of asynchronous task execution units on demand from the user - an invariant Velocity itself enforces. However, since this practice is so commonplace, it makes sense that we would need to have some upper cap to at least make the practice safer than it currently is.
Spiritually indebted to #518 and @alexstaeding.
There's a minor break - we're going up to 3.2.0-SNAPSHOT as the API now compiles against Java 11. But this is more academic in practice.
* Implement the ServerData packet by firing ProxyPingEvent
Mojang introduced the enable-status server property with Minecraft 1.19, which if enabled causes servers to close the connection when a client tries to ping them. Mojang wants to show the MOTD and favicon on the server select screen for those who manage to log in, so we need to implement this packet as well.
The good news is that we can send this packet as many times as needed on the same connection
This matches the behavior of pinging the server. This is a minor, but completely backwards-compatible, API breakage: Player inherits from InboundConnection so we do not have to change ProxyPingEvent, however plugins not expecting a Player might get confused.
* typo
Andrew Steinborn