I really hope there is no reload command. All it does is spam errors and cause issues and memory leaks. Just restart it.
1 Like
I personally don’t care too much if the reload command is added, but if it was i would certainly not (and forbid my admins to) use it because of the severe safety issues it can cause.
This would still have the dependency problem. Let’s say WorldEdit has that “reloadable=true”-tag, and a portal plugin has WE as a dependency (for creating the portal areas) but has “reloadable=false”.
If a server owner would reload the plugins, WE would get reloaded, but the portal plugin would not, resulting in the very same dependency problem that was talked about all the time.
1 Like
And that would be where dynamic class loading would come in. Imagine the scenario below
@Dependency("WorldEdit")
static SpongePlugin worldEdit;
When this is loaded into the class loader and registered as a plugin with whatever form of a system bus they’re using they would associate that field with the plugin dependency. When the named plugin “WorldEdit” is reloaded the field would automatically be assigned the new value of the created instance of WorldEdit’s main class and marking the old instance for deletion by the GC.
From that point forward it’s expected that anyone who is going to have their project depend on another plugin should have proper code etiquette and properly manage there resources. If you wanted to make it even easier for people who aren’t properly managing their resources to avoid issues add an event to the event bus for PluginReloaded, in your plugin if the reloaded plugin is one of your dependencies then reform your instances. You can also have an event for prior to plugins being unloaded so extending plugins can save anything they need to before acquiring the new instance.
Its not hard to implement a system where it’s easy to avoid conflicts due to reloading a series of classes, and where you take care of memory leaks. Memory leaks only happen if you don’t properly manage the resources so unless the development team were to take shortcuts or be lazy if implementing this feature it would be nearly trivial. As a server developer myself I can tell you it’s annoying not only to the development team, but to the people playing on your server when you have a problem with a plugin, and you need to update that plugin to fix a small bug, or to reload an asset which couldn’t be opened (due to fore-say an IOException). Kicking everyone off the server multiple times (because who knows how many attempts it may take to fix the issue) is simply unacceptable when you have anything larger than 50 people online at any given time.
Bukkit did not implement the reload system well, so their version of the system was a fail and had major flaws. But hundreds of games use dynamic loading for mods and have no issues, because the devs know what they’re doing when implementing that ability. Just because Bukkit failed to make a reliable system, doesn’t mean one doesn’t exist or is impossible.
And so you’re imposing that plugins have the ability to delete themselves from the classpath and reload themselves again, if people are talking about issues with memory leaks and dependency issues that’s sure not going to fix anything.
1 Like
Totally not, I am imposing that if plugins have reload code, they should implement the commands by them self. If a server owner wants a plugin to be unloaded/loaded he will need to restart the server for that.
1 Like
What I’m stating about your comment thomas is you’re saying that if a plugin wants to allow reloading they implement it themselves.
This means that the developers of Sponge would need to allow the master class loader to be public to any plugins in-case that plugin wants to be able to access it to have their plugin be unloaded and loaded again into the classpath, which would be a major security flaw compared to adding support for it internally. I am talking about the form of reload and unload that physically removes and updates references to the actual class files as loaded by the JVM. I am not talking about simply reloading a config file or a basic asset, I’m talking in terms of being able to dynamically add and remove modules or plugins to the Sponge environment, including the idea of being able to update a plugin.
If I’m developing a plugin for a server that has 1,000 players on it, I do bug-testing before placing it on the main server. However with so many people there are guaranteed to be bugs you can’t find out in simple controlled testing and thus the server is bugged and the plugins need an update. A single plugin may need to be edited and fixed multiple times depending on it’s size. And your community of 1,000 would get furious with you having to constantly restart the entire server network every hour to fix a problem with a single plugin. Compared to having the server on adding the ability to unload and load that plugin.
The only excuse to not implement the system is exclusively that it’s either impossible or causes memory leaks, which are both false. It is very possible, and very easy, and the only time memory leaks will exist in the setup is if the devs are completely lazy and take stupid shortcuts to reduce the already minimal workload.
I have worked with Java for 12 years and I’ve been a developer for a server for about 2.5 years. One of my plugins I wrote was a plugin that allowed for Java add-ons to said plugin (RPG plugin, each class was written as its own plugin to the RPG plugin). The RPG plugin loaded jar files into the classpath, and unloaded and reloaded files into the classpath. The entire process took place in one Java file with only 483 lines of code and over the course of 4 months the only signs of a memory leak are some small memory leaks from Java or the server itself that exist with or without the RPG plugin. So what I’m saying are the excuses are just that, excuses. Just because Bukkit completely failed at making a reliable system doesn’t mean that it’s impossible to make one or that the system is bad when implemented correctly.
I understand what your saying, but the main problem is that sponge doesn’t own the class loader. The class loader is managed by forge. Every plugin that gets loaded also shows up like an effective mod. In order to make sponge have plug in reloading/enabling/disabling. Is see these options:
- Making their own class loader. This will probably change a lot of the current work that has been done.
- Making a Pull Request to forge to allow unloading mods. I am pretty sure that never will get in to forge.
- Sponge manipulates the FML class loader. So it can unload/reload his plug-ins. I say hack
- Making the class that loads sponge plugins and act like a piece holder. For example sponge has detected 18 plugins. It loads the 18 plugins in their piece holders. It also loads 5 extra piece-holders for other plugins. But set their state to disabled. When sponge reloads. It disables and removes all the plugin objects from the piece-holders and resets them. But this will probably cause memory leaks as well.
Maybe having 2 servers on the network. For example you work on server_2 and fix problems from server_1. When server_2 has it bugfixes complete. You simply set server_2 as active server and server_1 as non-active using a costum bungeecoord plugins (shouldn’t be that hard to make). When players re-spawn (from for example a mini-game server) bungeecoord makes them re-spawn on the new fixed server. When everyone is away from server_1, You simpley use a version control system to pull over the plugins/configs from server_2. And BAM server_1 acts now as your new fixed server.
I used this system with the tekkit lite modpack. Only when switching we had to switch the map folder as well. Because this server wasn’t a minigame server xD. Only I dit the bungeecoord shit manually than … . When server_1 went down it tried server_2 and than the lobby.
If you have the required experience by all means make a pull request and prove people wrong.
I’m sure people would love a properly implemented version of this if you are up to the task.
We can throw all sorts of fancy code snippets out but the absolute reality is that it just. Will. Not. Work. Case Closed. As we’ve already seen dependencies make this hard and in the case of plugins without a proper implementation (ie one by a new Dev) to handle a disable that would save configs, etc. would just drive me insane, if Sponge will be anything like Bukkit the forums will be full of inexperienced devs (like @Exstar) asking “OMG how I do this sponge is broken DDDDD:”.
BTW, I was joking about @Exstar.
2 Likes
@ButterDev wajow…
This topic was automatically closed after 2 days. New replies are no longer allowed.