Reloading Server -- A Bad Practice?

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

 

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.

 

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.

 

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.

 

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.

 

/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.

 

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.