Reloading Server -- A Bad Practice?

Discussion in 'Bukkit Discussion' started by JHalt, Jul 30, 2013.


Is using /reload a bad practice?

  1. No

    0 vote(s)
  2. Yes

    16 vote(s)
Thread Status:
Not open for further replies.
  1. Offline


    Is reloading a server using /reload a bad practice? What are the technical reasons for this, if this is true?
  2. Offline

    Jade Retired Staff

    Moved to the right section. (Bukkit Discussion, as this is discussing Bukkit's /reload command, and not the development of a plugin.)

    It is in fact a bad practice. I don't know much personally on the technical side of things, but when you do the /reload (or /rl) command, it creates a new instance of the plugin altogether.
    JHalt likes this.
  3. Offline


    I'd guess that it makes things less stable, just like if you're running your computer for too long. But, just like Jade, I don't know the technicality of it.
  4. Offline


    I wrote my first plugin recently and found out the hard way that /reload is a VERY bad idea. Crashed my server twice running out of heap space and I spent hours trying to find a nonexistent memory leak in my plugin.

    Avoid it. It should be removed altogether.
  5. Offline


    I'll use /reload if I need to make some quick changes on the fly, usually if I know I'll need to do it a few times in a row. But once I have the configuration set up, I'll then restart the server.

    So I guess the answer is that /reload should be avoided, but it does have its uses.
  6. Offline

    TnT Retired Staff

    /reload in and of itself is alright. However, a plugin may not handle a /reload command very gracefully (or may outright fail).

    Be very wary about using /reload. Avoid it whenever possible.
  7. Offline


    As stated by TnT, plugins may have problems with reload. Implementing for a clean server start is much more simple, especially if a plugin has more complex data to handle and/or plugin dependencies to care for. Usually a server owner does not review all code of a plugin... effects could be inconsistencies, data loss, instability, memory leaking.

    There are potential problems that probably can't be 100% resolved, at least not without changes on documentation and/or implementation side of Bukkit/CraftBukkit: Some plugins need to re-check some permissions for players or have other more complex plugin-dependencies that might rely on such. Technically they should probably register a task to check delayed, but this would build on the trust/hope/code-review that CraftBukkit executes that task before anything player-related is processed Otherwise a plugin author can't be sure that "a/the permissions plugin" has already loaded for the case they check players during enabling, while they stay with a slight uncertainty (unspecified by API) with consistency-loss if they do the checks delayed in a task, adding a slight uncertainty of what player-action still gets processed or queued during/after plugin disabling.

    So if plugins are programmed without relying on code-review/guessing/hope, the authors could be demanded to take care of a couple of things that might not be too obvious to see, though likely improbable to actually cause trouble.

    One simpler example for potential trouble could be spam protection relating to a longer enabling time with reload.
Thread Status:
Not open for further replies.

Share This Page