This will provide quite a major performance boost by avoiding
synchronizing on EVERY chunk lookup.
Synchronize, even without contention, incurs processor cache flushes.
Considering this is the 2nd hottest method in the code base, lets
avoid doing that...
Additionally, chunk conversion operations were occuring while
under synchronization which lead to deadlocks.
Now the conversion will occur outside of the lock, and fix
that issue, resolving #1586
Note, that the chunk map is still thread safe for get operations!
The chunk map was never intended to be modified async with our
changes, as we post to main to modify the map, however
we do still synchronize for write operations (put, remove)
We also synchronize for async get operations, ensuring that
async gets are safe.
We do not need to synchronize main thread gets as the processor
cache will be insync since the map is only updated on the main thread.
However, if someone does try to delete or put concurrently, we
will force their operation back to the main thread.
While Velocity supports BungeeCord-style IP forwarding, it is not secure. Users
have a lot of problems setting up firewalls or setting up plugins like IPWhitelist.
Further, the BungeeCord IP forwarding protocol still retains essentially its original
form, when there is brand new support for custom login plugin messages in 1.13.
Velocity's modern IP forwarding uses an HMAC-SHA256 code to ensure authenticity
of messages, is packed into a binary format that is smaller than BungeeCord's
forwarding, and is integrated into the Minecraft login process by using the 1.13
login plugin message packet.
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
If a chunk load comes in on a chunk load or gen thread,
execute it synchronously on that thread instead of enqueueing it.
It doesn't make sense to enqueue it as that thread is then
going to future.join() it and block until it's ready anyways.
This opens risk to a deadlock if every load or gen thread is
waiting on a recursive chunk but it will never finish because
all of the threads are waiting.
If we identify an invalid offset (negative, or the header sectors),
then back up the region file and erase that specific chunks offset
data.
This will avoid crashing the server with AIOBB errors and also avoids
server owners having to consider the entire region file 'lost'.
I'm not sure what leads to this state, I can only assume write cut
off mid bits.
In this scenario, there is absolutely no way to know where the chunk
actually is in the data file without loading every
single chunk in the file. And even to do that, would be quite extreme
due to the fact the file isn't in some orderly fashion.
Since the file is backed up, the user can use a region fixer tool
externally to try to restore that single chunk. We could even
add a command to restore a chunk from a backup file in a different
commit later on. But this at least prevents the server from crashing.
The server will just generate a new chunk and move on,
after printing an error to the console about it.
Also fixed the case reported in this issue about the server
hanging when a corrupt chunk is encountered, so this issue
is now fully closed.
Resolves#1541
Chunk Generation was occuring while inside of the progressCache lock
this caused the progressCache to stay blocked for a long period of time
which then blocked main when main needed to clean the expiring map.
We now maintain a separate map for pending scheduler entries, that
we can join on if a 2nd request comes in while one is starting.
This strategy keeps the lock only for a fraction of time but
maintains thread safety.
So now the chunk is generated without holding a lock and wont
block the main thread on the expiring map as we will insert it
once ready.
1) Removed "Regen" mode of Dupe UUID resolver, forced safe.
Some servers who updated before we had safe mode added still had this value.
There's really no reason to keep this mode, as we've seen that vanilla
triggers this often and 99.9999999% of cases will be an actual duplicate
that needs to be deleted.
2) Made Vanilla Debug messages about dupe UUIDs and dupe uuid resolve messages
only show up if the debug.entities flag is on. This will stop server owners
from panicing from seeing these logs, and stop opening bug reports on this,
only for us to tell you "don't worry about it".
3) Avoid adding entities to world that are already added to world.
This can be triggered by anything that causes an entity to be added
to the world during the chunk load process, such as chunk conversions.
Issue #1544 was a case of this.
4) Removed debug warning about ExpiringMap.
Nothing more I know to do about this anyways. We recover from it,
stop warning to reduce noise of issues to us.
This will improve queue times by canceling chunks when a player
leaves the radius of an async loading/generating chunk.
This matches behavior we had pre 1.13 for loading too.
improved the water code so that immunity wont trigger if the entity
has the water pathfinder system active, so this improves support
for all entities that know how to behave in water.
Merged 2 EAR patches together, and removed an MCUtil method that
doesnt have a purpose anymore
2018-10-04 23:18:46 -04:00
Renamed from Spigot-Server-Patches/0377-Async-Chunk-Loading-and-Generation.patch (Browse further)
