If there are specific types of Mythimobs during uninstallation in the world, it will cause server threads to freeze
This is a question that has been bothering me for several months, and its specific triggering method is:
Firstly, use the MythicMobs plugin to create a mob (which must have variables assigned by MythicMobs), and then generate it in any world (in my server, I generate it through the functionality in MythicBungeons). Finally, while ensuring that the mob has variables, leave the world directly and trigger the uninstallation of the world. At this point, there is a high probability that the server will freeze.
The error report is as follows:
[10:46:12] [RegionFile I/O Thread #0/ERROR]: [ca.spottedleaf.moonrise.patches.chunk_system.io.RegionFileIOThread$ChunkDataTask] Failed to read chunk data for task: Task for world: 'week8_1' at (10,-1) type: CHUNK_DATA, hash: 1183117692 java.nio.channels.ClosedChannelException: null at java.base/sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:160) ~[?:?] at java.base/sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:957) ~[?:?] at net.minecraft.world.level.chunk.storage.RegionFile.getChunkDataInputStream(RegionFile.java:575) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at net.minecraft.world.level.chunk.storage.RegionFileStorage.read(RegionFileStorage.java:223) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at net.minecraft.world.level.chunk.storage.ChunkStorage.read(ChunkStorage.java:186) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at net.minecraft.server.level.ChunkMap.read(ChunkMap.java:592) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at ca.spottedleaf.moonrise.patches.chunk_system.io.datacontroller.ChunkDataController.readData(ChunkDataController.java:48) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at ca.spottedleaf.moonrise.patches.chunk_system.io.RegionFileIOThread$ChunkDataTask.run(RegionFileIOThread.java:1166) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at ca.spottedleaf.concurrentutil.executor.standard.PrioritisedThreadedTaskQueue$PrioritisedTask.executeInternal(PrioritisedThreadedTaskQueue.java:351) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at ca.spottedleaf.concurrentutil.executor.standard.PrioritisedThreadedTaskQueue.executeTask(PrioritisedThreadedTaskQueue.java:118) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at ca.spottedleaf.concurrentutil.executor.standard.PrioritisedQueueExecutorThread.pollTasks(PrioritisedQueueExecutorThread.java:114) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94] at ca.spottedleaf.concurrentutil.executor.standard.PrioritisedQueueExecutorThread.run(PrioritisedQueueExecutorThread.java:50) ~[purpur-1.21.1.jar:1.21.1-2298-a61db94]
Yes, it looks like there's a problem with a certain block in the world. But after my repeated testing, I have determined that this issue is caused by mobs with variables.
The specific testing method is:
- Create a world using mobs without variables and repeat the problematic process without crashing the server
- Use mobs with variables to create worlds and kill or remove them before leaving the world, so that the server does not crash
The above testing methods have undergone nearly a hundred experiments and therefore have reference value.
In summary, the necessary conditions to trigger this issue are:
When playing the dungeon, a mob with variables was generated
When the player leaves the dungeon, the mob still exists and has not been killed or removed
(If this mob has more variables, the probability of server crash will be higher, but I'm not sure if it must be like this.)
My server environment and related plugin versions are: - Server core: purpurpur-1.21.1-2298
- Mythicdungeons version: MythicDungeons-1.4.1-220
- Mythimobs version: Mythimobs-5.8.0-SNAPSHOT
Sorry, Mythicdungeons' version is a bit outdated because it had a problem of multiple dungeons of the same type running breaking each other in the past. So I haven't updated to the latest version yet. After I test and fix the latest version of the problem, I will make the necessary corrections and provide you with the most accurate feedback
Error message at approximately 48600 lines 2024-11-30-3.log