Why is using /reload a bad thing?

Discussion in 'Spigot Discussion' started by DeleteMetaInf, Jan 24, 2020.

  1. I’ve read a lot about the reload command being a bad idea, so I never use it, but I’ve never found an explanation as to what can actually go wrong using it. Can you lose player or world data, or perhaps your worlds be corrupted?

    I’ve also read how PlugMan, which can reload individual plugins instead of the entire server at once and can even enable newly added plugins or update plugins without restarting the server, should be used again. However, I’ve also read how PlugMan shouldn’t be used and how it has the same problems as /reload.

    So, which is it? Should PlugMan be used, or should servers always be fully restarted to reload things that can’t be reloaded normally? And what’s wrong with reloading in the first place?
    • Winner Winner x 1
  2. The reason why /reload is prohibited is because most of the developers doesn't adapt their code considering that the ops are gonna use the /reload command. Basically, some things aren't permanent (players' display name for example) so when you reload your server, the player that display name was set by a plugin lose that display name so he'll need to relog in. Hashmaps are also not persistent and most plugins use them. If the guy that made your plugins considered the /reload command, everything should be working fine. On another note, if you use /reload and something goes wrong because of a plugin, Spigot is safe from any complaint since they literally tell you not to use it, so that's on you :p
    #2 Maxx_Qc, Jan 24, 2020
    Last edited: Jan 24, 2020
    • Informative Informative x 2
    • Winner Winner x 1
  3. Adding onto this, certain plugins such as MCMMO will output a bunch of errors because it's not designed to be /reload in that format. Even using something like Plugman or another plugin manager ingame can break the plugin. The best way to reload plugins is to manually restart the server. But, there some plugins can be reloaded via Plugman or /reload. The command in itself won't break the plugin entirely, however if a plugin does manage to break and output those errors, a quick restart usually fixes it.
    • Informative Informative x 2
  4. Essentially, iirc the server attempts to unload and reload the objects within plugins and code. However, there is not actually a method in java which lets you 'unregister' objects. Therefore, spigot tries to get around this and it tries to destroy the objects to prevent major memory leaks but it doesn't always successfully do so as it's not actually a supported java method. At least that's what I heard one time

    Therefore, when the server is reloaded pieces of data stored may still be floating around and if a plugin accidentally accesses this it can cause corruption / general code not functioning properly. This doesn't always come up as errors but they're there. It also can cause things to load "out of sync" with others. So if a plugin needs to load x, y and z before world generation - it can't do this because the world is already generated due to your reload and not restart.

    On the other hand, developers can take this into account and try to combat this but it's not always respected
    #4 Harry0198, Jan 24, 2020
    Last edited: Jan 25, 2020
    • Informative Informative x 2
  5. For example something in plugin is done when player joins server. When you reload it every variable in plugin resets and everything set when player joined is being removed. That's why reload shouldn't be used. It may cause a lot of bugs.
    • Like Like x 1
    • Useful Useful x 1
  6. You should always do a full restart on a production server. As mentioned above, reloading plugins can cause memory leaks. As for adding new plugins, some plugins have features that must be enabled at certain points when the server is just starting. On a test server, there shouldn't be much harm. Just remember to do full restarts there every now and then as well.
    • Informative Informative x 2
  7. There's more to it than non-persistent data - it's nothing a developer can "adapt" their code to rectify (i.e. by using onDisable), the fault is with the user for running /reload, not with the developer. A plugin that uses any kind of lower level methods (esp. reflection), such as injecting into the command map or injecting new enchantments, is likely to completely break and start spewing weird stacktraces. This isn't anything to do with lazy or sloppy coding, it's just how it is.

    Also, you'll get memory leaks when you use /reload, as explained by @Harry0198
  8. Tell that to developers who think that onEnable can not be called with players online. I saw a lot of plugins where they load player data on player join and because of that it completely misses players who can be online during plugin reload.
  9. If you have a plugin that relies on intercepting the handshake packet during player login to store the player's protocol version, then /reload will break it and players will need to rejoin. There are hacky workarounds to this, but I discourage such methods.
  10. You load some data on some point, you can reload it at any time. You use reflection, you should be able to undo any changes you made via reflection. Judging by code of most of plugins, nobody really cares about it so yea, /reload is bad because you can't force plugin devs to respect it.
  11. What are you talking about? No, all data in memory owned by your plugin is cleared. I don't even get how reflection solves this problem.
  12. And tbh the whole thing with player's protocol version is dumb. You get plugin disable event, if you want to persist some data between reloads you have to SAVE it (surprising?) somewhere else and reload it after. Surely it is better than completely break your plugin in case of reload.
  13. You can do it, but I find that a hacky solution. Someone can join while the server is under a reload and they'll never get processed by the plugin.
    • Informative Informative x 1
  14. Yes, this is a valid example of something that you can not handle.
    Although imo there is nothing hacky about using disk or other ways to persist some data. Like, what else can you do? Anyway, most people ignore this thing altogether so I doubt there is a way to "fix" reload command because you can't fix all plugins and Spigot itself probably wasn't written to support reload properly.
  15. SteelPhoenix


    You are completely missing the point made... Your comment showed you had no idea what you were talking about, and when someone asks you to explain instead of admitting your mistake you tell them they go off-topic and report them too? What are you trying to accomplish with this?

    Also, Spigot supports /reload properly and plugins not supporting it is out of Spigot's control. There's a lot more to it than just loading/saving data, and even though some issues can be fixed by devs, there's a lot of shenanigans going on that can break reloading like mentioned before (non-persistent data, packet intercepting, reflection and nms use etc.).
    • Agree Agree x 2
  16. How exactly reflection and usage of internal classes prevent using reload? Would be useful to know to me and others I guess.
    Till know I though that if you use reflection you can 1) use it again in case you lost something 2) undo your changes in case you modified something via it so new info would be great :)
  17. Swear I posted this before but it's gone missing:
    My post was specifically about lower level interactions with spigot that are broken by /reload, hence why I said "There's more to it than non-persistent data"

    Quick example off the top of my head - there are some internal maps (either enchantments map or command map can't remember which) which cannot be modified after the server has booted up or else either stuff breaks or the enchants / commands just don't work, iirc. It's been a while. I'm sure someone could make a huge list of stuff that breaks.

    IOPS take a long time (in comparison to in-memory operations) and will also cause disk thrashing if you're writing every single change to disk
  18. md_5

    Administrator Developer

    The vast majority of plugins using NMS do not unhook their changes onDisable. This causes bugs and memory leaks.

    That’s the point of this thread. Reload is not inherently broken due to some Spigot bug or oversight, its just handled so badly by most plugins that you should not use it. Plugman has the same results (and worse).
    • Agree Agree x 3
  19. Most of you guys talk like it's technically impossible to your plugin to survive during reload in case you do something using reflection, internal classes, etc. I only saw one point when you can't handle reload — in case you need to listen to incoming packets and you lose them during reload period.

    So you use reflection? What is exactly preventing you from handling reloads correctly? In case you modify some internal data structures you should always know what you do and how to revert it. It's not like you do one-way changes. If you don't know how to revert it then it doesn't mean there is no way to revert it.
    md_5 told about nms above. You should be able to cleanup and do everything again.
    Not to mention that nms is not supported by Spigot and reflection is exactly what you call «hacky» (as the opposite to disk io like somebody said there).

    So far nobody (except one guy) was able to tell what exactly is impossible to do to survive during reload.
    You talk about reflection, nms, non-persistent data (???) but it all looks like a lame excuse to avoid dealing with it.

    It's not like somebody tries to scold you because of ignoring /reload, there are thousands of plugins written without reload in mind and you can do nothing about it. My point was that devs ignore it because it's just easier to ignore it instead of implementing proper cleanup and load during runtime. It would be great to see specific examples to investigate and learn from.

    This is complete nonsense for so many reasons in context of this topic, you save something in case of reload and load it after, it's not like you need to sync your memory with your disk non-stop to avoid losing some data during reload.
    • Optimistic Optimistic x 4
    • Funny Funny x 1
  20. @SteelPhoenix @aex32 Now that I have looked over the thread, I believe that there has been a misunderstanding. aex32 was in the middle of a conversation with DotRar and I saw their post without any context, so I was confused and I replied to it. I was further confused and began to become irritated when they replied with "I wasn't talking to you" and "read the topic."

    Turns out that aex32 wasn't claiming that data-persistence can be fully achieved with reflection. I apologize for the misunderstanding.